Bull AIX 5.3 Manuel utilisateur

Bull
Guide de gestion système AIX 5L
Communications et réseaux
AIX
REFERENCE
86 F2 47EM 01
Bull
Guide de gestion système AIX 5L
Communications et réseaux
AIX
Logiciel
Mars 2005
BULL CEDOC
357 AVENUE PATTON
B.P.20845
49008 ANGERS CEDEX 01
FRANCE
REFERENCE
86 F2 47EM 01
L’avis juridique de copyright ci–après place le présent document sous la protection des lois de Copyright
des États–Unis d’Amérique et des autres pays qui prohibent, sans s’y limiter, des actions comme la copie,
la distribution, la modification et la création de produits dérivés à partir du présent document.
Copyright
Bull S.A. 1992, 2005
Imprimé en France
Vos suggestions sur la forme et le fond de ce manuel seront les bienvenues.
Une feuille destinée à recevoir vos remarques se trouve à la fin de ce document.
Pour commander d’autres exemplaires de ce manuel ou d’autres publications
techniques Bull, veuillez utiliser le bon de commande également fourni en fin de
manuel.
Marques déposées
Toutes les marques déposées sont la propriété de leurs titulaires respectifs.
AIXR est une marque déposée d’IBM Corp. et est utilisée sous licence.
UNIX est une marque déposée aux Etats–Unis et dans d’autres pays, licenciée exclusivement par Open Group.
Linux est une marque déposée de Linus Torvalds.
Les informations contenues dans le présent document peuvent être modifiées sans préavis. Bull ne pourra
être tenu pour responsable des erreurs qu’il peut contenir ni des dommages accessoires ou indirects que son
utilisation peut causer.
Préface
Le Guide de gestion du système :Communications et réseaux fournit aux administrateurs
système des informations détaillées sur la configuration des paramètres TCP/IP,
l’amélioration de la sécurité du réseau et le contrôle du système. Il comporte également des
sections sur la configuration et la résolution d’incidents liées à Mail, NFS (Network File
System), HA–NFS (High Availability–NFS), BNU (Basic Networking Utilities), aux
communications sérielles et les unités TTY, ainsi qu’au protocole SNMP (Simple Network
Management Protocol). Cette publication est également disponible sur le “Hypertext Library
for AIX 5.3” CD-ROM fourni avec le système d’exploitation.
Conventions typographiques
Les conventions typographiques suivantes sont utilisées dans ce manuel :
Gras
Commandes, mots-clés, fichiers, répertoires et autres éléments
dont le nom est prédéfini par le système.
Italique
Paramètres dont le nom ou la valeur est fourni par l’utilisateur.
Espacement
fixe
Exemples (valeurs spécifiques, texte affiché, code programme),
messages système ou données entrées par l’utilisateur.
Distinction majuscules/minuscules dans AIX
La distinction majuscules/minuscules s’applique à toutes les données entrées dans le
système d’exploitation AIX. Vous pouvez, par exemple, utiliser la commande ls pour afficher
la liste des fichiers. Si vous entrez LS, le système affiche un message d’erreur indiquant
que la commande entrée est introuvable. De la même manière, FICHEA, FiChea et fichea
sont trois noms de fichiers distincts, même s’ils se trouvent dans le même répertoire.
Pour éviter toute action indésirable, vérifiez systématiquement que vous utilisez la casse
appropriée.
Préface
iii
ISO 9000
Ce produit a été développé et fabriqué conformément aux procédures de qualité ISO 9000.
Bibliographie
Les manuels suivants complètent la documentation sur les communications.
• AIX 5L Version 5.3 System Management Guide: Operating System and Devices
• AIX 5L Version 5.3 System Management Concepts: Operating System and Devices
• AIX 5L Version 5.3 System User’s Guide: Communications and Networks
• AIX 5L Version 5.3 General Programming Concepts: Writing and Debugging Programs
• AIX 5L Version 5.3 Network Information Service (NIS and NIS+) Guide
• AIX 5L Version 5.3 Commands Reference
• AIX 5L Version 5.3 Références et guide d’installation
• AIX 5L Version 5.3 Security Guide
iv
Guide de gestion du système – Communications et réseaux
Table des matières
Préface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conventions typographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Distinction majuscules/minuscules dans AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISO 9000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
iii
iii
iv
iv
Table des matières . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
v
Chapitre 1. Procédures des tâches d’administration réseau . . . . . . . . . . . . . . . .
Mise à niveau vers IPv6 à partir d’une configuration IPv4 . . . . . . . . . . . . . . . . . . . . . .
Etape 1. Configuration des hôtes pour IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 2. Configuration du routeur pour IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 3. Définition d’IPv6 pour une configuration sur les hôtes au démarrage .
Etape 4 : Définition d’IPv6 pour une configuration sur le routeur au démarrage
Mise à niveau vers IPv6 sans configuration d’IPv4 dans AIX 5.2
et versions ultérieures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 1 : Configuration des hôtes pour IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 2 : Configuration du routeur pour IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 3. Définition d’IPv6 pour une configuration sur les hôtes au démarrage .
Etape 4 : Définition d’IPv6 pour une configuration sur le routeur au démarrage
Configuration de la tunnelisation dans IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mise en oeuvre d’un tunnel automatique dans IPv6 . . . . . . . . . . . . . . . . . . . . . . . .
Mise en oeuvre des tunnels configurés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Migration de SNMPv1 vers SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 1. Migration des informations de communauté . . . . . . . . . . . . . . . . . . . . . . .
Etape 2. Migration des informations d’affichage . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 3. Migration des informations d’interruption . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 4. Migration des informations smux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 5. Arrêt et démarrage du démon snmpd . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Création d’utilisateurs dans SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 1. Création de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 2. Configuration du groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 3. Configuration des permissions d’accès et d’affichage . . . . . . . . . . . . . .
Etape 4. Configuration des entrées d’interruption pour l’utilisateur . . . . . . . . . . . .
Etape 5. Arrêt et démarrage du démon snmpd . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 6. Test de votre configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mise à jour dynamique des clés d’authentification et de confidentialité
dans SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Création d’un alias local pour la messagerie électronique . . . . . . . . . . . . . . . . . . . . .
Configuration des serveurs de nom de domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 1. Configuration du serveur de noms maître . . . . . . . . . . . . . . . . . . . . . . . . .
Etape 2. Configuration du serveur de noms esclave . . . . . . . . . . . . . . . . . . . . . . . .
Etape 3. Configuration du serveur de noms d’indices . . . . . . . . . . . . . . . . . . . . . . .
1-1
1-2
1-2
1-3
1-3
1-4
Préface
1-5
1-5
1-6
1-6
1-7
1-8
1-8
1-9
1-10
1-10
1-11
1-12
1-13
1-13
1-14
1-14
1-15
1-16
1-17
1-18
1-18
1-19
1-22
1-23
1-24
1-27
1-29
v
vi
Chapitre 2. Communications et réseaux : généralités . . . . . . . . . . . . . . . . . . . . . .
Fonctions de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Présentation des réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Réseaux physiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Systèmes réseau et protocoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocoles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Domaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Passerelles et ponts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Noeud local et noeud distant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client et serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communication avec d’autres systèmes d’exploitation . . . . . . . . . . . . . . . . . . . . . . . .
2-1
2-2
2-3
2-5
2-6
2-6
2-6
2-6
2-7
2-7
2-7
2-7
2-8
Chapitre 3. Messagerie électronique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion du courrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du fichier /etc/rc.tcpip pour lancer le démon sendmail . . . . . . . . . .
Gestion des alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier /etc/mail/aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Création d’alias de système local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Création d’une base de données d’alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion des fichiers et répertoires de file d’attente courrier . . . . . . . . . . . . . . . . . . . .
Impression de la file d’attente courrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers de file d’attente courrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier de contrôle q . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spécification des délais au démon sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exécution forcée de la file d’attente courrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Intervalle de traitement de la file d’attente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transfert de file d’attente courrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancement du démon sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arrêt du démon sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion de la journalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion du journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Journalisation du trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Journalisation des données statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affichage des informations des programmes facteurs . . . . . . . . . . . . . . . . . . . . . .
Mise au point de sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocoles IMAP (Internet Message Access Protocol) et POP
(Post Office Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration des serveurs IMAP et POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tests de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Informations de référence du courrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des commandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des fichiers et répertoires courrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commande sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des commandes IMAP et POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-1
3-3
3-3
3-4
3-4
3-5
3-5
3-6
3-6
3-6
3-7
3-8
3-9
3-9
3-9
3-10
3-10
3-11
3-12
3-12
3-13
3-14
3-15
Guide de gestion du système – Communications et réseaux
3-16
3-16
3-16
3-16
3-17
3-18
3-19
3-19
3-19
3-19
3-20
3-20
Chapitre 4. Protocole TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Préparation du réseau TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation et configuration pour TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration des systèmes hôte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration des hôtes en tant que serveurs . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration des passerelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes de gestion système TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’une liste de contrôle du réseau TCP/IP . . . . . . . . . . . . . . . . . . . . .
Prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocoles TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IP version 6 - Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routage et adressage étendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simplification de routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simplification du format d’en-tête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amélioration du contrôle trafic/qualité du service . . . . . . . . . . . . . . . . . . . . . . . .
Tunnellisation IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sécurité IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Support IPv6 des adresses locales du site et des liens Multihomed . . . . . . . .
Suivi de paquet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
En-têtes de paquet au niveau interface de réseau . . . . . . . . . . . . . . . . . . . . . . . . .
En-têtes de trame pour carte Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
En-tête de trame pour réseau en anneau à jeton . . . . . . . . . . . . . . . . . . . . . . . .
En-têtes de trame 802.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocoles Internet de niveau réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole de résolution d’adresse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types de messages ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocoles Internet de niveau transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Définitions de zones d’en-tête TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocoles Internet de niveau application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole DOMAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole EGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Systèmes autonomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types de messages EGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole FINGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole d’exécution de commande à distance . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole d’ouverture de session à distance . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole SHELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole Wake On LAN (WOL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
protocole TIMED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nombres réservés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes de réseau local (LAN) TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation d’une carte réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration et gestion des cartes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration et utilisation des réseaux locaux virtuels (VLAN) . . . . . . . . . . . . . .
Préface
4-1
4-2
4-3
4-3
4-3
4-3
4-4
4-4
4-4
4-4
4-5
4-6
4-9
4-10
4-11
4-12
4-14
4-15
4-16
4-16
4-17
4-18
4-19
4-19
4-21
4-22
4-22
4-23
4-24
4-24
4-27
4-27
4-28
4-30
4-31
4-32
4-32
4-32
4-33
4-34
4-34
4-35
4-35
4-36
4-36
4-36
4-36
4-36
4-36
4-37
4-37
4-38
4-38
4-39
4-40
vii
Identification des incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilisation de cartes ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Technologie ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Connexions ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP/IP sur ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’une carte ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statistiques sur la carte ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statistiques ATM Micro Channel complémentaires . . . . . . . . . . . . . . . . . . . . . . .
Statistiques propres à la carte ATM PCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaces de réseau TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration automatique des interfaces de réseau . . . . . . . . . . . . . . . . . . . . . . .
Configuration Ethernet par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration 802.3 par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Valeurs de configuration par défaut de l’anneau à jeton . . . . . . . . . . . . . . . . . .
Configuration SLIP par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration optique série par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration ATM par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Réseaux avec plusieurs interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion d’interfaces de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Options du réseau spécifiques à l’interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adressage TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adresses Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adresses de classe A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adresse de classe B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adresse de classe C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adresses Internet avec zéros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adresses de sous-réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Masques de sous-réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparaison d’adresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adresses de diffusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adresses de bouclage local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résolution de noms sous TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Système d’appellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Autorité d’appellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conventions d’appellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appellation des hôtes de votre réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Serveurs de noms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résolution de noms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole RARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résolution locale des noms (/etc/hosts) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Préparation à la résolution DNS (DOMAIN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Serveur de noms : généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration des serveurs de noms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’un serveur de courrier de domaine . . . . . . . . . . . . . . . . . . . . . .
Configuration d’un serveur expéditeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de serveur exclusivement expéditeur . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’un hôte avec serveur de noms . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de zones dynamiques sur le serveur de noms DNS . . . . . . . . . . . .
Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BIND 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transaction Signatures (TSIG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signature (SIG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
Guide de gestion du système – Communications et réseaux
4-41
4-41
4-42
4-42
4-43
4-44
4-47
4-47
4-49
4-51
4-52
4-53
4-53
4-54
4-54
4-55
4-55
4-55
4-56
4-56
4-57
4-59
4-60
4-60
4-60
4-61
4-61
4-62
4-62
4-63
4-64
4-65
4-65
4-66
4-66
4-66
4-68
4-68
4-69
4-72
4-74
4-74
4-75
4-76
4-77
4-78
4-80
4-81
4-83
4-85
4-87
4-88
4-88
4-90
Planification et configuration pour la résolution de noms LDAP
(Schéma de répertoire SecureWay) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planification et configuration pour la résolution de noms NIS_LDAP
(Schéma RFC 2307) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affectation des adresses et paramètres TCP/IP - Protocole DHCP . . . . . . . . . . . . .
Le serveur DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La base de données DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le moteur de protocole DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Opérations DHCP enchaînées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Préparation de DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le fichier de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Personnalisation d’un fichier de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP et DDNS (Dynamic Domain Name System –
Système de noms de domaine dynamique) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibilité DHCP avec les versions antérieures . . . . . . . . . . . . . . . . . . . . . . . . .
Options connues du fichier de serveur DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sous–option de conteneur fournisseur de l’environnement PXE
(Preboot Execution Environment) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de fichier de configuration prenant en charge les clients PXE . . . . .
Syntaxe du fichier de serveur DHCP
pour le fonctionnement général du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remarques sur la syntaxe du fichier de serveur DHCP
pour la base de données db_file : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP et gestion NIM (Network Installation Management) . . . . . . . . . . . . . . . . . .
Dynamic Host Configuration Protocol version 6 (DHCPv6) . . . . . . . . . . . . . . . . . . . .
Le serveur DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La base de données DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Opérations DHCP enchaînées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du serveur DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le fichier de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier /etc/dhcpv6/dhcpsdv6.cnf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration client DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mots–clés de journalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mot–clé DUID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mot–clé informatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Renouvellement du bail et mot–clé de ce renouvellement . . . . . . . . . . . . . . . .
Demande du mot–clé de retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mots–clés d’option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
mots–clés d’interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent relais DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démon DHCP avec structure PXED
(Preboot Execution Environment Proxy) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le serveur DHCP proxy PXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La base de données PXED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le moteur de protocole PXED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Opérations PXED enchaînées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du serveur PXED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le fichier de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sous–options du conteneur fournisseur PXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Syntaxe du fichier de serveur PXED pour le fonctionnement
général du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remarques sur la syntaxe du fichier de serveur PXED
pour la base de données db_file : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démon BINLD (Boot Image Negotiation Layer Daemon) . . . . . . . . . . . . . . . . . . . . . .
Le serveur BINLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La base de données BINLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Préface
4-92
4-93
4-96
4-97
4-97
4-99
4-99
4-100
4-100
4-101
4-105
4-107
4-109
4-109
4-114
4-115
4-116
4-121
4-142
4-143
4-144
4-144
4-147
4-148
4-148
4-151
4-160
4-160
4-161
4-161
4-161
4-162
4-162
4-166
4-166
4-169
4-169
4-169
4-169
4-169
4-170
4-171
4-175
4-177
4-178
4-186
4-186
4-186
ix
Le moteur de protocole BINLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Opérations BINLD enchaînées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de BINLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le fichier de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Syntaxe du fichier de serveur BINLD pour le fonctionnement général
du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Syntaxe du fichier de serveur BINLD pour le fonctionnement général
du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démons TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sous-systèmes et sous-serveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fonction SRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes SRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du démon inetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services réseau client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services réseau serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routage TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routage statique ou dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Passerelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Passerelles intérieures et extérieures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocoles de passerelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planification des passerelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nombre de passerelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Type de routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’une passerelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sécurité des routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Détection des passerelles non opérationnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clonage de route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Suppression manuelle de routes dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du démon routed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du démon gated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du démon gated pour l’exécution de IPv6 . . . . . . . . . . . . . . . . . .
Obtention d’un numéro de système autonome . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compréhension de la sécurité du mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancement de Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arrêt de Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des incidents Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adresse IP virtuelle (VIPA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de VIPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion de VIPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ajout d’une carte à un VIPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Retrait d’une carte d’un VIPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple d’environnement VIPA dans AIX 5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
Autres informations techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
EtherChannel et IEEE 802.3ad Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes prises en charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
EtherChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’EtherChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remarques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’un EtherChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de Network Interface Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Options d’équilibrage de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Circulaire (round–robin) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standard ou 8023ad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
x
Guide de gestion du système – Communications et réseaux
4-186
4-186
4-187
4-188
4-191
4-194
4-201
4-201
4-202
4-202
4-204
4-205
4-206
4-208
4-209
4-209
4-210
4-210
4-211
4-211
4-212
4-212
4-214
4-214
4-215
4-215
4-215
4-216
4-218
4-219
4-220
4-221
4-222
4-222
4-223
4-223
4-224
4-224
4-224
4-224
4-225
4-225
4-226
4-227
4-227
4-228
4-229
4-229
4-230
4-232
4-235
4-236
4-237
Gestion d’EtherChannel et de IEEE 802.3ad Link Aggregation . . . . . . . . . . . . . .
Affichage de la liste des EtherChannels ou des Link Aggregations . . . . . . . . .
Modification de l’adresse de remplacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dynamic Adapter Membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ajout, suppression ou changement de cartes dans un EtherChannel
ou Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Suppression d’un EtherChannel ou d’un Link Aggregation . . . . . . . . . . . . . . . .
Configuration ou suppression d’une carte de secours
sur un EtherChannel ou un Link Aggregation existant . . . . . . . . . . . . . . . . . . . .
Identification des incidents d’EtherChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Suivi d’EtherChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affichage des statistiques d’ EtherChannel . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amélioration de la prise de relais lente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les cartes ne prennent pas le relais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilisation de trames jumbo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vidage à distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IEEE 802.3ad Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remarques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de IEEE 802.3ad Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . .
Gestion de IEEE 802.3ad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification et résolution des incidents IEEE 802.3ad . . . . . . . . . . . . . . . . . . .
Scénarios d’interopérabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole Internet (IP) par Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration IP par Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Activer le pilote d’unité du Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affectez les propriétés réseau à l’interface Fibre Channel. . . . . . . . . . . . . . . . .
Initiateur logiciel iSCSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de l’initiateur logiciel iSCSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remarques supplémentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remarques sur la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remarques sur les performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole de transmission du contrôle de flot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancement et interruption de l’association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
API de socket SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recherche de MTU d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Normes QoS (Qualité du service) TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modèles QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services intégrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services différenciés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Normes prises en charge et ébauches de normes . . . . . . . . . . . . . . . . . . . . . . . . .
Installation de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arrêt et démarrage du sous–système QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de l’agent RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de l’agent de politique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des problèmes au niveau du QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spécification de politiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ReadFromDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ServiceCategories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ServicePolicyRules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instructions relatives aux environnements DiffServ . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier de configuration policyd exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier de configuration policyd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chargement de politiques dans le serveur
de répertoires SecureWay Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Préface
4-238
4-238
4-238
4-238
4-239
4-241
4-241
4-241
4-241
4-241
4-242
4-242
4-242
4-243
4-243
4-244
4-244
4-246
4-246
4-246
4-248
4-248
4-248
4-249
4-250
4-250
4-251
4-252
4-253
4-254
4-255
4-256
4-258
4-260
4-261
4-261
4-261
4-262
4-263
4-263
4-263
4-263
4-264
4-266
4-266
4-267
4-267
4-268
4-268
4-269
4-269
4-270
xi
xii
Schéma LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Politiques superposées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilisation de sockets UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conflits de politiques avec des réservations RSVP . . . . . . . . . . . . . . . . . . . . . .
Spécification de la profondeur du compartiment à jeton . . . . . . . . . . . . . . . . . .
Modification de politiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conformité aux normes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modèle IntServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modèle DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prise en charge de IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrôle du démon de politique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Référence QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des incidents TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents de résolution de noms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hôte client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hôte serveur de noms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents de routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Autres possibilités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents SRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents liés à telnet ou rlogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Distorsion de l’écran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mise au point par telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mise au point du démon telnetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Programmes utilisant la bibliothèque curses étendue . . . . . . . . . . . . . . . . . . . .
Incidents de configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents courants sur les interfaces de réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents sur une interface de réseau SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents sur l’interface de réseau Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents liés à une interface de réseau en anneau à jeton . . . . . . . . . . . . . . .
Incidents avec un pont anneau à jeton/Ethernet . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents sur un pont reliant deux réseaux en anneau à jeton . . . . . . . . . . . . .
Incidents de livraison de paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communication avec un hôte distant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Réponses snmpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents au niveau du protocole DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Informations de référence TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des commandes TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des démons TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des méthodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des fichiers TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4-271
4-272
4-272
4-272
4-272
4-272
4-272
4-272
4-272
4-272
4-273
4-273
4-273
4-273
4-273
4-274
4-274
4-274
4-275
4-275
4-276
4-277
4-277
4-278
4-278
4-278
4-279
4-280
4-280
4-280
4-281
4-282
4-282
4-282
4-283
4-284
4-284
4-284
4-284
4-285
4-285
4-286
4-286
4-286
4-287
Chapitre 5. Administration du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Administration de réseau avec SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Présentation de SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architecture SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sous–agents DPI2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Homologues smux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestionnaire SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-1
5-2
5-3
5-4
5-5
5-5
5-5
5-6
5-6
Guide de gestion du système – Communications et réseaux
Variables MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clés utilisateur SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clés d’authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clés de confidentialité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Génération de clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mise à jour des clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Emission de requêtes SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des incidents SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Politiques d’accès SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démon SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du démon SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
fichier /etc/snmpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fonctionnement du démon SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Traitement d’un message et authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Traitement d’une requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Traitement d’une réponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Traitement d’une interruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Support du démon SNMP pour la famille EGP de variables MIB . . . . . . . . . . . . .
Exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification et résolution des incidents liés au démon SNMP . . . . . . . . . . . . . . .
Interruption prématurée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Défaillance du démon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accès impossible aux variables MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accès impossible aux variables MIB dans une entrée de communauté . . . . .
Absence de réponse de l’agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Message noSuchName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-6
5-7
5-7
5-7
5-8
5-9
5-10
5-11
5-13
5-14
5-15
5-16
5-16
5-17
5-17
5-18
5-18
5-20
5-22
5-32
5-35
5-35
5-36
5-36
5-37
5-37
5-38
Chapitre 6. Système de fichiers NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Système de fichiers NFS : généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Listes de contrôle d’accès (ACL) sous NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NFS4 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AIX ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Système de fichiers cache (CacheFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mappage de fichiers sous NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types de montage NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exportation et montage NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exportation de répertoires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Montage de répertoires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Processus de montage NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier /etc/exports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier /etc/xtab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier /etc/nfs/hostkey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier /etc/nfs/local_domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier /etc/nfs/realm.map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier /etc/nfs/princmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier /etc/nfs/security_default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implémentation de NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole RPC (Remote Procedure Call) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole XDR (eXternal Data Representation) . . . . . . . . . . . . . . . . . . . . . . . . .
Démon portmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrôle de NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modification du nombre de démons biod et nfsd . . . . . . . . . . . . . . . . . . . . . . . . .
6-1
6-2
6-2
6-3
6-4
6-4
6-5
6-7
6-7
6-8
6-8
6-9
6-10
6-10
6-10
6-11
6-11
6-11
6-11
6-12
6-12
6-12
6-12
6-12
6-13
6-13
6-14
Préface
xiii
Modification des arguments des démons contrôlés par SRC . . . . . . . . . . . . . .
Lancement des démons NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arrêt des démons NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etat des démons NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prise en charge de NFS version 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation et configuration de NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etapes de configuration de NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancement des démons NFS au démarrage du système . . . . . . . . . . . . . . . . . . .
Configuration d’un serveur NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’un client NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mappage d’identité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exportation d’un système de fichiers NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’un réseau pour RPCSEC–GSS . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annulation de l’exportation d’un système de fichiers NFS . . . . . . . . . . . . . . . . . . .
Modification d’un système de fichiers exporté . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Activation de l’accès racine à un système de fichiers exporté . . . . . . . . . . . . . . . .
Montage explicite d’un système de fichiers NFS . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sous–système Automount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mappes directes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mappes indirectes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mappes d’hôtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Montage automatique d’un système de fichiers à l’aide de AutoFS . . . . . . . .
Etablissement de montages NFS prédéfinis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démontage d’un système de fichiers monté explicitement
ou automatiquement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Suppression de montages NFS prédéfinis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PC–NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service d’authentification PC–NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Service d’impression en différé PC–NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du démon rpc.pcnfsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancement du démon rpc.pcnfsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vérification de la disponibilité du démon rpc.pcnfsd . . . . . . . . . . . . . . . . . . . . . . . .
Gestion des mappes LDAP Automount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WebNFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestionnaire NLM (Network Lock Manager) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architecture du gestionnaire NLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verrouillage des fichiers du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Processus de reprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lancement du gestionnaire NLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dépannage du gestionnaire NLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Limitation des plages de port NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sécurité NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des incidents NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inaccessibilité des fichiers en montage fixe ou logiciel . . . . . . . . . . . . . . . . . . . . . .
Liste de contrôle pour l’identification des incidents NFS . . . . . . . . . . . . . . . . . . . . .
Erreurs d’écriture asynchrone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messages d’erreur NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Message d’erreur nfs_server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messages d’erreur mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Problèmes de temps d’accès à NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vérification des connexions réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Taille UTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tailles de files d’attente de transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Intervention sur programmes bloqués . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Droits d’accès et authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xiv
Guide de gestion du système – Communications et réseaux
6-14
6-14
6-14
6-15
6-15
6-16
6-16
6-16
6-16
6-17
6-18
6-18
6-19
6-22
6-23
6-24
6-24
6-25
6-25
6-25
6-25
6-26
6-27
6-31
6-31
6-32
6-32
6-32
6-33
6-33
6-34
6-35
6-36
6-37
6-37
6-37
6-38
6-38
6-39
6-40
6-41
6-42
6-42
6-42
6-44
6-44
6-44
6-44
6-46
6-46
6-46
6-46
6-47
6-47
Résolution des noms d’hôte sur un serveur NFS . . . . . . . . . . . . . . . . . . . . . . . .
Limitation du nombre de groupes dans la structure NFS . . . . . . . . . . . . . . . . . .
Montage à partir de serveurs équipés d’une version NFS antérieure . . . . . . .
Identification des incidents RPCSEC–GSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des incidents EIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conséquences d’une extension de noyau NFS non chargée . . . . . . . . . . . . . .
Conséquences lorsque le support kerberos n’est pas installé . . . . . . . . . . . . .
Point à vérifier si le démon registry n’est pas en cours d’exécution . . . . . . . . .
Informations de référence NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des fichiers NFS (Network File System) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des commandes NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste des démons NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verrouillage des démons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilitaires et démons de service réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilitaires et démons de sécurité du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Support des clients sans disque Sun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sous–routines NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6-48
6-48
6-48
6-49
6-50
6-51
6-51
6-51
6-52
6-52
6-52
6-53
6-53
6-53
6-54
6-54
6-54
Chapitre 7. Server Message Block File System . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation de SMBFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Montage du système de fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des incidents SMBFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7-1
7-1
7-1
7-3
Chapitre 8. Communications asynchrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planification des communications asynchrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vitesses de ligne non–POSIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes asynchrones : généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Evaluation des options de communication asynchrones . . . . . . . . . . . . . . . . . . . .
Ports asynchrones connectés à la carte principale système . . . . . . . . . . . . . . .
Port asynchrone connecté à une carte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port asynchrone connecté à un noeud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remarques sur la sélection des produits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Critères de sélection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vocation des cartes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Topologie : observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communication série . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synchronisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synchrone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Asynchrone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Paramètres de communication série . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bits par caractère . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bits par seconde (bps) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Débit en bauds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bits de départ, d’arrêt et indicateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La norme EIA 232D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Méthodes de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrôle de flux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RTS/CTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DTR/DSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XON/XOFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’un port pour l’établissement
d’une liaison matérielle RTS/CTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Généralités TTY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-1
8-2
8-3
8-4
8-5
8-5
8-6
8-6
8-7
8-7
8-8
8-9
8-10
8-11
8-12
8-12
8-13
8-14
8-14
8-14
8-14
8-14
8-15
8-16
8-16
8-16
8-17
8-17
8-17
Préface
8-17
8-18
xv
Variable TERM pour différents écrans et terminaux . . . . . . . . . . . . . . . . . . . . . . . .
Définition des caractéristiques de terminal TTY . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Définition des attributs de l’unité TTY raccordée . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion des unités TTY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identification des incidents TTY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Régénération trop rapide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Informations journalisées et identificateurs de journal TTY . . . . . . . . . . . . . . . .
Déblocage d’un port tty bloqué . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modems – généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Normes de télécommunications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transmissions en duplex intégral et semi-duplex . . . . . . . . . . . . . . . . . . . . . . . .
Normes de communications UIT-TSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole MNP (Microcom Networking Protocol) . . . . . . . . . . . . . . . . . . . . . . . .
Remarques sur les modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modems pris en charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signal DCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vitesses des ETTD/ETCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signaux de contrôle des modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Câblage de modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration des modems génériques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’une unité TTY sur le système d’exploitation . . . . . . . . . . . . . .
Raccordez le modem avec les câbles appropriés . . . . . . . . . . . . . . . . . . . . . . . .
Ajout d’un TTY pour le modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configurez le modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modems Hayes et compatibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résolution des problèmes de modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Récapitulatif des commandes AT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aide supplémentaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entrées du fichier d’exemple /usr/lib/uucp/Dialers . . . . . . . . . . . . . . . . . . . . . . .
Définition des options de terminal avec stty–cxma . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole asynchrone point à point (PPP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Processus utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du protocole asynchrone PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocoles PPP et SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Activation de PPP SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Applications de communications asynchrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocole SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Etapes de la configuration du protocole SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remarques sur les modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration manuelle des modems via cu . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration automatique des modems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de SLIP pour modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de SLIP pour câble de modem nul . . . . . . . . . . . . . . . . . . . . . . . .
Désactivation d’une connexion SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Activation d’une connexion SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Suppression d’une interface SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Débogage des incidents SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Incidents courants et messages d’erreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Questionnaire SLIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Emulation de terminal asynchrone (ATE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’ATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Personnalisation d’ATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier répertoire des numéros d’appel ATE . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appels sortants via ATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xvi
Guide de gestion du système – Communications et réseaux
8-18
8-18
8-19
8-20
8-21
8-22
8-24
8-27
8-30
8-31
8-31
8-31
8-32
8-33
8-33
8-33
8-33
8-34
8-36
8-37
8-37
8-38
8-38
8-38
8-42
8-43
8-45
8-45
8-49
8-49
8-55
8-58
8-58
8-59
8-63
8-63
8-65
8-66
8-66
8-67
8-68
8-69
8-70
8-72
8-74
8-74
8-74
8-75
8-77
8-78
8-81
8-82
8-83
8-87
8-92
Transfert de fichiers via ATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Réception de fichiers via ATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résolution des problèmes ATE courants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Utilitaire dscreen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier de configuration de terminal dsinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affectation des touches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Touche de sélection (Select) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Touche de blocage (Block) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Touche de création d’écran (New) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Touches d’arrêt et de sortie (End et Quit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Touche d’écran précédent (Previous) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Touche de listage (List) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Affectation dynamique d’écran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Description du fichier dsinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Format des entrées pour dsinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types de chaîne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8-92
8-93
8-94
8-95
8-95
8-95
8-96
8-96
8-96
8-96
8-96
8-97
8-97
8-97
8-98
8-99
8-100
8-101
Chapitre 9. Protocole DLC (Data Link Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . .
Environnement GDLC – généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Critères GDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mise en oeuvre de l’interface GDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation de DLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Opérations ioctl sur l’interface GDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Point d’accès au service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Station de liaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mode Local-Busy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mode Short-Hold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test et suivi d’une liaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Statistiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Services spéciaux du noyau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gestion des pilotes d’unités DLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-1
9-2
9-4
9-5
9-6
9-7
9-8
9-8
9-8
9-8
9-9
9-9
9-10
9-12
Chapitre 10. Utilitaires réseau (BNU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Présentation de BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fonctionnement de BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Support NLS (National Language Support) pour les commandes BNU . . . . .
Structure des fichiers et répertoires BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Répertoires publics BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers de configuration BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Répertoires et fichiers administratifs BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers de verrouillage BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sécurité de BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ID de connexion uucp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ID de connexion BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sécurité et fichiers Systems et remote.unknown . . . . . . . . . . . . . . . . . . . . . . . . .
Sécurité et fichier Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démons BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démon uucico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démon uusched . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démon uuxqt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démon uucpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-1
10-2
10-3
10-3
10-3
10-3
10-3
10-5
10-6
10-6
10-6
10-7
10-7
10-8
10-8
10-8
10-9
10-9
10-10
Préface
xvii
Configuration de BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Collecte des informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du contrôle automatique de BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Préalables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Appel automatique BNU des systèmes distants . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichier /etc/uucp/Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Édition des fichiers Devices pour connexion câblée . . . . . . . . . . . . . . . . . . . . . . . .
Prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Création d’une entrée de nom de système . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Création d’une entrée directe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Édition du fichier Devices pour connexion automatique . . . . . . . . . . . . . . . . . . . . .
Prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Édition du fichier Devices pour TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maintenance de BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers journaux BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers journaux des répertoires .Log et .Old . . . . . . . . . . . . . . . . . . . . . . . . . . .
Autres fichiers journaux BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers journaux au niveau système utilisés par BNU . . . . . . . . . . . . . . . . . . .
Commandes de maintenance BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes de nettoyage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes de contrôle d’état . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procédures shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrôle d’une connexion distante BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrôle du transfert de fichier BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contrôle du transfert de fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résolution des incidents BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messages d’état de la phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messages d’état de la phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messages d’état de la phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messages d’état de la phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messages d’état de la phase 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Messages d’état de la phase 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résolution des incidents de connexion BNU via le démon uucico . . . . . . . . . . . .
Prérequis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Communication avec des systèmes UNIX via la commande tip . . . . . . . . . . . . . .
Variables de tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers de configuration de tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers de configuration BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de configuration BNU pour connexion TCP/IP . . . . . . . . . . . . . . . . . . . . .
Entrées dans les fichiers du système local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entrées dans les fichiers du système distant . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xviii
Guide de gestion du système – Communications et réseaux
10-11
10-11
10-11
10-12
10-15
10-15
10-15
10-16
10-16
10-16
10-16
10-17
10-17
10-17
10-17
10-18
10-18
10-18
10-18
10-18
10-18
10-19
10-19
10-19
10-20
10-20
10-21
10-21
10-21
10-22
10-22
10-22
10-22
10-23
10-23
10-24
10-24
10-25
10-25
10-26
10-26
10-28
10-28
10-28
10-28
10-28
10-30
10-30
10-31
10-32
10-33
10-33
10-34
Exemple de configuration BNU pour connexion téléphonique . . . . . . . . . . . . . . . .
Entrées sur le système local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entrées sur le système distant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de configuration BNU pour connexion directe . . . . . . . . . . . . . . . . . . . . .
Entrées dans les fichiers du système local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entrées dans les fichiers du système distant . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Référence des fichiers, commandes et répertoires BNU . . . . . . . . . . . . . . . . . . . . . . .
Répertoires BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fichiers BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Commandes BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Démons BNU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10-35
10-35
10-36
10-37
10-37
10-38
10-40
10-40
10-40
10-41
10-42
Annexe A. Cartes PCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes PCI WAN (Wide Area Network) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pilote d’unité multiprotocole HDLC 2 ports : généralités . . . . . . . . . . . . . . . . . . . . .
Configuration de la carte multiprotocole 2 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte ARTIC960Hx PCI : Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration du pilote d’émulation MPQP COMIO
sur la carte ARTIC960Hx PCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A-1
A-1
A-1
A-2
A-2
Annexe B. Cartes asynchrones standard, Micro Channel 8 et 16 ports . . . . . .
Micro Channel 8 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISA Bus 8 ports EIA 232 ou EIA 232/EIA 422 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Micro Channel 16 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte 128 ports (Micro Channel, ISA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avec SMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte ISA/PCI asynchrone 8 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation des cartes 8 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration de la carte ISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Définition des options de terminal Micro Channel et ISA avec stty–cxma . . .
Ports d’E/S standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’une unité terminal asynchrone EIA 232 . . . . . . . . . . . . . . . . . . . . .
Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration d’une imprimante ou d’un traceur asynchrone EIA 232 . . . . . . . . .
Procédure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes asynchrones Micro Channel 8 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte asynchrone 8 ports – description EIA 232 . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte asynchrone 8 ports : installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte asynchrone 8 ports : informations concernant le matériel . . . . . . . . . . . . . .
Priorité des voies de transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte asynchrone 8 ports : description de la logique des interruptions . . . . . . . .
Logique de génération des interruptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logique d’arbitrage des interruptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes asynchrones 8 ports MIL–STD 188 : signaux d’interface . . . . . . . . . . . . .
Niveaux de tension de signal MIL–STD 188 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Polarités Marque et Espace normales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Inversion des polarités Marque et Espace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conformité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes asynchrones 8 ports EIA 422A : signaux d’interface . . . . . . . . . . . . . . . . .
Niveaux de tension du signal EIA 422A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Circuit de protection contre la surtension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Circuit à sécurité intégrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conformité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes asynchrones 8 ports EIA 232 : signaux d’interface . . . . . . . . . . . . . . . . . . .
B-1
B-3
B-3
B-3
B-4
B-4
B-4
B-5
B-5
B-5
B-5
B-5
B-6
B-6
B-6
B-6
B-7
B-7
B-8
B-9
B-9
B-10
B-10
B-10
B-11
B-11
B-11
B-11
B-12
B-12
B-12
B-12
B-12
B-13
Préface
A-3
xix
xx
Niveaux de tension de signal EIA 232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conformité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes asynchrones 8 ports : logique de commande . . . . . . . . . . . . . . . . . . . . . . .
Cartes asynchrones 16 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte asynchrone 16 ports – description EIA 422A . . . . . . . . . . . . . . . . . . . . . . . . .
Caractéristiques : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte asynchrone 16 ports : installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte asynchrone 16 ports : informations concernant le matériel . . . . . . . . . . . . .
Carte asynchrone 16 ports : priorités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Priorité des voies de transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carte asynchrone 16 ports : description de la logique des interruptions . . . . . . .
Logique de génération des interruptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logique d’arbitrage des interruptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes asynchrones 16 ports EIA 232 : signaux d’interface . . . . . . . . . . . . . . . . . .
Niveaux de tension de signal EIA 232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conformité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cartes asynchrones 16 ports EIA 422A : signaux d’interface . . . . . . . . . . . . . . . .
Niveaux de tension du signal EIA 422A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Circuit de protection contre la surtension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Circuit à sécurité intégrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conformité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B-13
B-13
B-13
B-14
B-14
B-14
B-15
B-16
B-17
B-17
B-17
B-17
B-18
B-18
B-18
B-18
B-19
B-19
B-19
B-19
B-19
Annexe C. Remarques sur la migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C-1
Annexe D. Configuration de la sauvegarde de l’interface réseau
dans les versions précédentes d’AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D-1
Annexe E. Table de conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E-1
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
X-1
Guide de gestion du système – Communications et réseaux
Chapitre 1. Procédures des tâches
d’administration réseau
Le présent chapitre contient des instructions sur l’exécution des tâches d’administration
réseau courantes :
• Mise à niveau vers IPv6 à partir d’une configuration IPv4, page 1-2
• Mise à niveau vers IPv6 sans configuration d’IPv4 dans AIX 5.2 et versions ultérieures,
page 1-5
• Configuration de la tunnellisation dans IPv6, page 1-8
• Migration de SNMPv1 vers SNMPv3, page 1-10
• Création d’utilisateurs dans SNMPv3, page 1-14
• Mise à jour dynamique des clés d’authentification et de confidentialité dans SNMPv3,
page 1-19
• Création d’un alias local pour la messagerie électronique, page 1-22
• Configuration des serveurs de noms de domaine, page 1-23
Procédures des tâches d’administration réseau
1-1
Mise à niveau vers IPv6 à partir d’une configuration IPv4
Dans ce scénario, vous réalisez une mise à niveau manuelle d’une configuration IPv4 vers
IPv6. Le réseau utilisé dans cet exemple est constitué d’un routeur et de deux
sous–réseaux. Il y a deux hôtes sur chaque sous–réseau : le routeur et un autre hôte. Vous
allez mettre à niveau chaque machine sur ce réseau vers la configuration IPv6. A la fin du
scénario, le routeur annonce le préfixe 3ffe:0:0:aaaa::/64 sur l’interface réseau en0
et le préfixe 3ffe:0:0:bbbb::/64 sur l’interface réseau en1. Vous allez d’abord
configurer les machines pour qu’elles prennent en charge de façon temporaire IPv6 à des
fins de test. Vous les configurerez ensuite pour qu’elles soient prêtes en configuration IPv6
au moment du démarrage.
Si vous exécutez AIX 5.2 et n’avez pas configuré vos paramètres IPv4, reportez–vous à Mise
à niveau vers IPv6 sans configuration d’IPv4 dans AIX 5.2 et versions ultérieures page 1-5.
Eléments à prendre en considération
Les informations contenues dans ces instructions ont été testées avec AIX 5.2. Les
résultats peuvent être sensiblement différents si vous utilisez une autre version ou niveau
de AIX.
Etape 1. Configuration des hôtes pour IPv6
Sur les hôtes des deux sous–réseaux, effectuez les actions suivantes :
1. Vérifiez que IPv4 est configuré en tapant la commande suivante :
netstat –ni
La commande affiche un résultat semblable à ce qui suit :
Name
en0
en0
lo0
lo0
lo0
Mtu
1500
1500
16896
16896
16896
Network
link#2
9.3.230.64
link#1
127
::1
Address
0.6.29.4.55.ec
9.3.230.117
127.0.0.1
Ipkts Ierrs
279393
279393
913
913
913
0
0
0
0
0
Opkts Oerrs
2510
2510
919
919
919
Coll
0
0
0
0
0
0
0
0
0
0
2. Avec les droits d’accès root, configurez vos paramètres IPv6 en spécifiant la commande
suivante :
autoconf6
3. Exécutez à nouveau la commande suivante :
netstat –ni
La commande affiche un résultat semblable à ce qui suit :
Name
en0
en0
en0
sit0
sit0
lo0
lo0
lo0
Mtu
1500
1500
1500
1480
1480
16896
16896
16896
Network
Address
link#2
0.6.29.4.55.ec
9.3.230.64 9.3.230.117
fe80::206:29ff:fe04:55ec
link#3
9.3.230.117
::9.3.230.117
link#1
127
127.0.0.1
::1
Ipkts Ierrs
279679
279679
279679
0
0
2343
2343
2343
0
0
0
0
0
0
0
0
Opkts Oerrs
2658
2658
2658
0
0
2350
2350
2350
Coll
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
4. Lancez les démons ndpd–host en tapant la commande suivante :
startsrc –s ndpd–host
L’hôte est désormais prêt pour la configuration IPv6. Répétez cette procédure pour chaque
hôte du sous–réseau.
1-2
Guide de gestion du système – Communications et réseaux
Etape 2. Configuration du routeur pour IPv6
1. Vérifiez que les paramètres IPv4 sont configurés en entrant la commande suivante :
netstat –ni
2. Avec les droits d’accès root, entrez la commande suivante :
autoconf6
3. Configurez manuellement les adresses générales sur les interfaces du routeur
appartenant à chacun des deux sous–réseaux en entrant les commandes suivantes :
# ifconfig en0 inet6 3ffe:0:0:aaaa::/64 eui64 alias
# ifconfig en1 inet6 3ffe:0:0:bbbb::/64 eui64 alias
Vous devrez réitérer cette action pour chaque sous–réseau auquel votre routeur envoie
des paquets.
4. Pour activer le réacheminement IPv6, entrez la commande suivante :
no –o ip6forwarding=1
5. Pour démarrer le démon ndpd–router, saisissez :
startsrc –s ndpd–router
Le démon ndpd–router annonce des préfixes correspondant aux adresses générales
que vous avez configurées sur le routeur. Dans ce cas, le ndpd–router annonce le
préfixe 3ffe:0:0:aaaa::/64 sur en0 et le préfixe 3ffe:0:0:bbbb::/64 sur en1.
Etape 3. Définition d’IPv6 pour une configuration sur les hôtes
au démarrage
Votre nouvelle configuration IPv6 est supprimée lorsque vous redémarrez la machine.
Pour activer la fonctionnalité d’hôte IPv6 à chaque redémarrage du système, procédez
comme suit :
1. Ouvrez le fichier /etc/rc.tcpip avec votre éditeur favori.
2. Supprimez la mise en commentaire des lignes suivantes :
# Start up autoconf6 process
start /usr/sbin/autoconf6 ””
# Start up ndpd–host daemon
start /usr/sbin/ndpd–host ”$src_running”
Au redémarrage, la configuration IPv6 est définie. Répétez ce processus pour chaque hôte.
Procédures des tâches d’administration réseau
1-3
Etape 4 : Définition d’IPv6 pour une configuration
sur le routeur au démarrage
Votre nouvelle configuration IPv6 est supprimée lorsque vous redémarrez la machine.
Pour activer la fonctionnalité de routeur IPv6 à chaque redémarrage du système, procédez
comme suit :
1. Ouvrez le fichier /etc/rc.tcpip avec votre éditeur favori.
2. Supprimez la mise en commentaire de la ligne suivante :
# Start up autoconf6 process
start /usr/sbin/autoconf6 ””
3. Ajoutez les lignes suivantes immédiatement à la suite de la ligne dont vous venez
de supprimer la mise en commentaire :
# Configure global addresses for router
ifconfig en0 inet6 3ffe:0:0:aaaa::/64 eui64 alias
ifconfig en1 inet6 3ffe:0:0:bbbb::/64 eui64 alias
Dans ce scénario, le réseau comporte uniquement deux sous–réseaux, en0 et en1.
Vous devrez ajouter une ligne dans ce fichier pour chaque sous–réseau auquel votre
routeur envoie des paquets.
4. Supprimez la mise en commentaire de la ligne suivante :
# Start up ndpd–router daemon
start /usr/sbin/ndpd– router ”$src_running”
Au redémarrage, la configuration IPv6 est automatiquement lancée.
1-4
Guide de gestion du système – Communications et réseaux
Mise à niveau vers IPv6 sans configuration d’IPv4 dans AIX 5.2
et versions ultérieures
Le présent scénario indique comment configurer des hôtes et un routeur pour IPv6 sans
que les paramètres IPv4 soient configurés. Le réseau utilisé dans cet exemple est constitué
d’un routeur et de deux sous–réseaux. Il y a deux hôtes sur chaque sous–réseau : le
routeur et un autre hôte. A la fin du scénario, le routeur annonce le préfixe
3ffe:0:0:aaaa::/64 sur l’interface réseau en0 et le préfixe 3ffe:0:0:bbbb::/64
sur l’interface réseau en1. Vous allez d’abord configurer les machines pour qu’elles
prennent en charge de façon temporaire IPv6 à des fins de test. Vous les configurerez
ensuite pour qu’elles soient prêtes en configuration IPv6 au moment du démarrage.
Ce scénario part du principe que le fichier bos.net.tcp.client est installé.
Pour effectuer une mise à niveau IPv6 avec IPv4 déjà configuré, reportez–vous à Mise à
niveau vers IPv6 à partir d’une configuration d’IPv4 page 1-2.
Eléments à prendre en considération
Les informations contenues dans ces instructions ont été testées avec AIX 5.2.
Les résultats peuvent être sensiblement différents si vous utilisez une autre version
ou niveau de AIX.
Etape 1 : Configuration des hôtes pour IPv6
1. Avec les droits d’accès racine, entrez la commande suivante sur chaque hôte du
sous–réseau :
autoconf6 –A
Toutes les interfaces adaptées à IPv6 sur le système sont affichées.
Remarque :
Pour afficher un sous–ensemble d’interfaces, utilisez l’indicateur –i.
Par exemple, autoconf6 –i en0 en1 affiche les interfaces en0
et en1.
2. Entrez la commande suivante pour afficher vos interfaces :
netstat –ni
La commande affiche un résultat semblable à ce qui suit :
Name
en0
en0
lo0
lo0
lo0
Mtu
1500
1500
16896
16896
16896
Network
Address
link#3
0.4.ac.17.b4.11
fe80::204:acff:fe17:b411
link#1
127
127.0.0.1
::1
Ipkts Ierrs
7
0
7
0
436
0
436
0
436
0
Opkts Oerrs
17
0
17
0
481
0
481
0
481
0
Coll
0
0
0
0
0
3. Lancez les démons ndpd–host en tapant la commande suivante :
startsrc –s ndpd–host
Procédures des tâches d’administration réseau
1-5
Etape 2 : Configuration du routeur pour IPv6
1. Avec les droits d’accès racine, entrez la commande suivante sur l’hôte du routeur :
autoconf6 –A
Toutes les interfaces adaptées à IPv6 sur le système sont affichées.
Remarque :
Pour afficher un sous–ensemble d’interfaces, utilisez l’indicateur –i.
Par exemple, autoconf6 –i en0 en1 affiche les interfaces en0
et en1.
La commande affiche un résultat semblable à ce qui suit :
Name
en1
en1
en0
en0
lo0
lo0
lo0
Mtu
1500
1500
1500
1500
16896
16896
16896
Network
Address
link#2
0.6.29.dc.15.45
fe80::206:29ff:fedc:1545
link#3
0.4.ac.17.b4.11
fe80::204:acff:fe17:b411
link#1
127
127.0.0.1
::1
Ipkts Ierrs
0
0
0
0
7
0
7
0
436
0
436
0
436
0
Opkts Oerrs
7
0
7
0
17
0
17
0
481
0
481
0
481
0
Coll
0
0
0
0
0
0
0
2. Configurez manuellement les adresses générales sur les interfaces du routeur
appartenant à chacun des deux sous–réseaux en entrant les commandes suivantes :
# ifconfig en0 inet6 3ffe:0:0:aaaa::/64 eui64 alias
# ifconfig en1 inet6 3ffe:0:0:bbbb::/64 eui64 alias
Remarque :
Vous devrez réitérer cette action pour chaque sous–réseau auquel votre
routeur envoie des paquets.
3. Pour activer le réacheminement IPv6, entrez la commande suivante :
no –o ip6forwarding=1
4. Pour démarrer le démon ndpd–router, saisissez :
startsrc –s ndpd–router
Le démon ndpd–router annonce des préfixes correspondant aux adresses générales
que vous avez configurées sur le routeur. Dans ce cas, le routeur annonce le préfixe
3ffe:0:0:aaaa::/64 sur l’interface réseau en0 et le préfixe
3ffe:0:0:bbbb::/64 sur l’interface réseau en1.
Etape 3. Définition d’IPv6 pour une configuration sur les hôtes
au démarrage
Lorsque vous aurez exécuté l’étape 1 pour chaque hôte, la configuration IPv6 sera
supprimée lorsque vous redémarrez la machine. Pour activer la fonctionnalité d’hôte IPv6 à
chaque redémarrage du système, procédez comme suit :
1. Ouvrez le fichier /etc/rc.tcpip avec votre éditeur favori.
2. Supprimez la mise en commentaire des lignes suivantes :
# Démarrer processus autoconf6
start /usr/sbin/autoconf6 ””
# Démarrer le démon ndpd–host
start /usr/sbin/ndpd–host ”$src_running”
3. Ajoutez l’indicateur –A à start /usr/sbin/autoconf6 ””:
start /usr/sbin/autoconf6 ”” –A
4. Répétez ce processus pour chaque hôte.
Au redémarrage, la configuration IPv6 est automatiquement lancée.
1-6
Guide de gestion du système – Communications et réseaux
Etape 4 : Définition d’IPv6 pour une configuration sur le routeur
au démarrage
Lorsque vous aurez exécuté l’étape 2 pour le routeur, la configuration IPv6 sera supprimée
lorsque vous redémarrez la machine. Pour activer la fonctionnalité de routeur IPv6 à
chaque redémarrage du système, procédez comme suit :
1. Ouvrez le fichier /etc/rc.tcpip avec votre éditeur favori.
2. Supprimez la mise en commentaire de la ligne suivante :
# Démarrer processus autoconf6
start /usr/sbin/autoconf6 ””
3. Ajoutez l’indicateur –A à cette ligne :
start /usr/sbin/autoconf6 ”” –A
4. Ajoutez les lignes suivantes immédiatement à la suite de la ligne dont vous venez de
supprimer la mise en commentaire :
# Configurer les adresses générales pour le routeur
ifconfig en0 inet6 3ffe:0:0:aaaa::/64 eui64 alias
ifconfig en1 inet6 3ffe:0:0:bbbb::/64 eui64 alias
Dans ce scénario, le réseau comporte uniquement deux sous–réseaux, en0 et en1.
Vous devrez ajouter une ligne dans ce fichier pour chaque sous–réseau auquel votre
routeur envoie des paquets.
5. Supprimez la mise en commentaire de la ligne suivante :
# Démarre le démon ndpd–router
start /usr/sbin/ndpd–router ”$src_running”
6. Exécutez la commande ci–après pour activer le réacheminement IP au moment du
démarrage :
no –r –o ip6forwarding=1
Au redémarrage, la configuration IPv6 est automatiquement lancée.
Procédures des tâches d’administration réseau
1-7
Configuration de la tunnelisation dans IPv6
Vous avez le choix entre deux méthodes : prévoir un tunnel automatique ou mettre en place
un tunnel configuré.
Eléments à prendre en considération
Les informations contenues dans ces instructions ont été testées avec AIX 5.3.
Les résultats peuvent être sensiblement différents si vous utilisez une autre version
ou niveau de AIX.
Mise en oeuvre d’un tunnel automatique dans IPv6
Dans ce scénario, vous allez faire appel à la commande autoconf6 pour configurer IPv6 et
mettre en place un tunnel automatique via l’interface principale, en2. Vous utiliserez ensuite
la commande autoconf6 pour configurer un tunnel via l’interface secondaire, en0.
Voici le résultat obtenu avec la commande netstat –ni qui permet d’afficher la configuration
réseau actuelle du système :
en0
en0
en2
en2
1500
1500
1500
1500
link#2
1.1
link#3
10.1
MAC address here
1.1.1.3
MAC address here
10.1.1.1
0
0
79428
79428
0
0
0
0
33
33
409
409
0
0
0
0
0
0
0
0
• Pour activer IPv6 et un tunnel automatique, tapez la commande suivante :
autoconf6
L’exécution de la commande netstat –ni génère à présent les résultats suivants :
# netstat –in
en0
1500 link#2
MAC address here
en0
1500 1.1
1.1.1.3
en0
1500 fe80::204:acff:fe49:4910
en2
1500 link#3
MAC address here
en2
1500 10.1
10.1.1.1
en2
1500 fe80::220:35ff:fe12:3ae8
sit0 1480 link#7
10.1.1.1
sit0 1480 ::10.1.1.1
0
0
0
79428
79428
0
0
0
0
0
33
33
33
409
409
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Si en2 (adresse IP 10.1.1.1) est l’interface principale, l’adresse ::10.1.1.1 peut
maintenant est utilisée pour la tunnelisation automatique via l’interface en2.
• Pour activer un tunnel automatique via l’interface en0, entrez la commande suivante :
autoconf6 –s –i en0
L’exécution de la commande netstat –ni génère à présent les résultats suivants :
# netstat –in
en0
1500 link#2
MAC address here
en0
1500 1.1
1.1.1.3
en0
1500 fe80::204:acff:fe49:4910
en2
1500 link#3
MAC address here
en2
1500 10.1
10.1.1.1
en2
1500 fe80::220:35ff:fe12:3ae8
sit0 1480 link#7
1.1.1.3
sit0 1480 ::10.1.1.1
sit0 1480 ::1.1.1.3
0
0
0
79428
79428
0
0
0
0
0
33
33
33
409
409
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
3
3
3
0
0
0
0
0
0
Cette action a pour effet d’ajouter une adresse IPv6 compatible IPv4 à l’interface SIT
existante, sit0. La tunnelisation est également activée pour l’interface en0 utilisant
l’adresse ::1.1.1.3. La même interface, sit0, sera utilisée pour les deux tunnels.
1-8
Guide de gestion du système – Communications et réseaux
Remarque :
Les tunnels automatiques sont supprimés au redémarrage du système.
Pour conserver le tunnel automatique au démarrage, ajoutez les
arguments obligatoires à la commande autoconf6 dans le fichier
/etc/rc.tcpip.
Mise en oeuvre des tunnels configurés
Dans ce scénario, SMIT est utilisé pour mettre en place un tunnel configuré. Ce tunnel sera
disponible lors du redémarrage du système, car il est stocké dans le gestionnaire d’objets
(ODM). Vous allez configurer un tunnel entre les systèmes alpha et beta. L’adresse IPv4
du système alpha est 10.1.1.1 et celle du système beta est 10.1.1.2.
Pour mettre en oeuvre les tunnels configurés, procédez comme suit :
1. Pour configurer un tunnel entre alpha et beta, entrez la commande suivante sur les
deux systèmes :
smit ctinet6
2. Sélectionnez l’option permettant d’ajouter un IPV6 à l’interface de tunnel IPV4 sur les
deux systèmes.
3. Dans ce scénario, nous avons complété les valeurs de la façon suivante sur alpha, en
fonction des adresses IPv4 :
* Adresse source IPV4 (décimale à points)
* Adresse de destination IPV4 (décimale à points)
Adresse source IPV6 (séparateur :)
Adresse de destination IPV6 (séparateur :)
[10.1.1.1]
[10.1.1.2]
[]
[]
Voici les valeurs spécifiées sur beta :
* Adresse source IPV4 (décimale à points)
* Adresse de destination IPV4 (décimale à points)
Adresse source IPV6 (séparateur :)
Adresse de destination IPV6 (séparateur :)
[10.1.1.2]
[10.1.1.1]
[]
[]
4. Pour afficher les interfaces configurées, entrez la commande suivante :
ifconfig cti
X
où X est le numéro de l’interface. Dans ce scénario, voici les résultats qui ont été
renvoyés :
Sur alpha :
cti0: flags=8080051<UP,POINTOPOINT,RUNNING,MULTICAST>
inet6 fe80::a01:101/128 ––> fe80::a01:102
Sur beta :
cti0: flags=8080051 <UP,POINTOPOINT,RUNNING,MULTICAST>
inet6 fe80::a01:102/128 ––> fe80::a01:101
SMIT crée automatiquement les adresses IPv6 pour les deux extrémités du tunnel à l’aide
de la méthode suivante :
• Les 32 bits inférieurs contiennent l’adresse IPv4.
• Les 96 bits supérieurs contiennent le préfixe fe80::/96.
Vous pouvez renseigner des adresses IPv6 spécifiques, si cela est nécessaire.
Procédures des tâches d’administration réseau
1-9
Migration de SNMPv1 vers SNMPv3
Le présent scénario présente une migration classique de SNMPv1 vers SNMPv3.
Dans AIX 5.2 et les versions supérieures, l’agent SNMP par défaut s’exécutant au moment
de l’amorçage du système est la version non chiffrée de SNMPv3. SNMPv3 utilise le fichier
/etc/snmpdv3.conf comme fichier de configuration. Vous devez faire migrer tous les
paramètres que vous avez configurés dans le fichier /etc/snmpd.conf, qui est utilisé
par SNMPv1 dans AIX 5.1 et versions antérieures, dans le fichier /etc/snmpdv3.conf.
Dans ce scénario, les communautés et les interruption configurées dans le fichier
/etc/snmpd.conf seront migrées vers le fichier /etc/snmpdv3.conf. A la fin du scénario,
SNMPv3 fournira une fonctionnalité identique à celle proposée par SNMPv1. Si vous n’avez
configuré aucun de vos signaux d’interruption ou communautés SNMPv1, vous n’avez pas
besoin de suivre cette procédure.
Ce fichier ne contient aucune information sur les fonctions disponibles dans SNMPv3.
Pour plus d’informations sur la création d’utilisateurs avec des fonctions de SNMPv3 non
disponibles dans SNMPv1, reportez–vous à Création d’utilisateurs dans SNMPv3
page 1-14.
Le fichier suivant est l’exemple de fichier /etc/snmpd.conf qui va faire l’objet de la
migration. Les communautés suivantes sont configurées : daniel, vasu, et david. Vous
devez les faire migrer manuellement.
logging
logging
file=/usr/tmp/snmpd.log
size=0
community
community
community
daniel
vasu
david
view 1.17.35
view 10.3.5
udp icmp snmp 1.3.6.1.2.1.25
system interfaces tcp icmp
trap
trap
trap
daniel
vasu
david
smux
1.3.6.1.4.1.2.3.1.2.3.1.1
enabled
level=0
0.0.0.0
0.0.0.0
readWrite
9.3.149.49 255.255.255.255 readOnly
9.53.150.67 255.255.255.255 readWrite
9.3.149.49
9.3.149.49
9.53.150.67
1.17.35
10.3.5
1.17.35
1.17.35
10.3.5
1.17.35
fe
fe
fe
sampled_password
# sampled
Pour exécuter les étapes de ce scénario, reportez–vous au fichier /etc/snmpd.conf.
Gardez à votre portée une copie de ce fichier lorsque vous démarrez cette procédure.
Eléments à prendre en considération
Les informations contenues dans ces instructions ont été testées avec AIX 5.2.
Les résultats peuvent être sensiblement différents si vous utilisez une autre version
ou niveau de AIX.
Etape 1. Migration des informations de communauté
Les noms de communauté du fichier /etc/snmpd.conf sont intégrés aux entrées
VACM_GROUP du fichier /etc/snmpdv3.conf. Chaque communauté doit être placée dans
un groupe. Vous accordez ensuite aux groupes les droits d’accès et d’affichage
nécessaires.
1. Avec les droits de l’utilisateur racine, ouvrez le fichier /etc/snmpdv3.conf avec votre
éditeur favori. Recherchez les entrées VACM_GROUP dans le fichier.
2. Créez une entrée VACM_GROUP pour chaque communauté que vous voulez faire
migrer. Si plusieurs communautés doivent partager les mêmes droits d’accès et
d’affichage, vous ne devez créer qu’un seul groupe pour elles. Les noms de
communauté du fichier /etc/snmpd.conf deviennent les valeurs securityName des
entrées VACM_GROUP. Dans ce scénario, les entrées suivantes ont été ajoutées pour
vasu, daniel, et david:
1-10
Guide de gestion du système – Communications et réseaux
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# entrées VACM_GROUP
#
Définit un groupe de sécurité
(composé d’utilisateurs ou de communautés)
#
pour le modèle VACM (View–based Access Control Model).
# Format :
# groupName securityModel securityName storageType
VACM_GROUP group2 SNMPv1 vasu –
VACM_GROUP group3 SNMPv1 daniel –
VACM_GROUP group3 SNMPv1 david –
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
– groupName peut être la valeur de vote choix, sauf group1.
– securityModel reste SNMPv1 car nous migrons les communautés SNMPv1.
– Dans ce scénario, daniel et david partagent les mêmes droits d’affichage et
d’accès au fichier /etc/snmpd.conf. Par conséquent, ils sont tous les deux membres
de group3 dans le fichier /etc/snmpdv3.conf. La communauté vasu est placée
dans un groupe différent parce ses droits d’accès et d’affichage sont différents de
ceux de david et daniel.
Les communautés sont désormais placées dans des groupes.
Etape 2. Migration des informations d’affichage
Les informations d’affichage du fichier /etc/snmpd.conf deviennent les entrées
COMMUNITY, VACM_VIEW, et VACM_ACCESS dans le fichier /etc/snmpdv3.conf.
Ces entrées déterminent les droits d’accès et d’affichage pour chaque groupe.
1. Créez les entrées COMMUNITY pour daniel, vasu, et david, en conservant les
mêmes adresses IP pour netAddr et netMask que celles indiquées dans le fichier
/etc/snmpd.conf.
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# COMMUNITY
#
Définit une communauté pour une sécurité basée sur la communauté.
# Format :
# communityName securityName securityLevel netAddr netMask storageType
COMMUNITY public
public
noAuthNoPriv 0.0.0.0
0.0.0.0
–
COMMUNITY daniel
daniel
noAuthNoPriv 0.0.0.0
0.0.0.0
–
COMMUNITY vasu
vasu
noAuthNoPriv 9.3.149.49 255.255.255.255 –
COMMUNITY david
david
noAuthNoPriv 9.53.150.67 255.255.255.255 –
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
2. Créez une entrée VACM_VIEW pour chaque objet ou variable MIB auquel chaque
groupe a accès. D’après le fichier /etc/snmpd.conf, daniel et david ont accès à
udp, icmp, snmp, et 1.3.6.1.2.1.25 (sous–arborescence hôte définie dans RFC
1514), et vasu a accès aux interfaces system, interfaces, tcp, et icmp. La
migration de ces entrées d’affichage dans le fichier /etc/snmpdv3.conf s’effectue
comme suit :
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# Entrées VACM_VIEW
#
Définit un ensemble particulier de données MIB, appelé une vue, pour le
#
Modèle VACM (View–based Access Control Model).
# Format :
# viewName viewSubtree viewMask viewType storageType
VACM_VIEW
VACM_VIEW
VACM_VIEW
VACM_VIEW
group2View
group2View
group2View
group2View
system
interfaces
tcp
icmp
–
–
–
–
included
included
included
included
–
–
–
–
VACM_VIEW group3View
udp
– included –
VACM_VIEW group3View
icmp
– included –
VACM_VIEW group3View
snmp
– included –
VACM_VIEW group3View
1.3.6.1.2.1.25
– included –
#–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Procédures des tâches d’administration réseau
1-11
3. Définissez les droits d’accès aux variables MIB définies dans les entrées VACM_VIEW
en ajoutant les entrées VACM_ACCESS. Dans le fichier /etc/snmpd.conf, daniel et
david ont tous les deux un droit readWrite sur leurs variables MIB, tandis que vasu
a le droit readOnly.
Définissez ces droits en ajoutant les entrées VACM_ACCESS . Dans ce scénario, nous
avons donné à group2 ( vasu ) group2View pour readView, mais lui avons donné
– pour writeView car vasu avait le droit readOnly dans le fichier
/etc/snmpd.conf. Nous avons donné à group3 ( daniel et david ) group3View
pour à la fois readView et writeView car ces groupes avaient un accès readWrite
dans /etc/snmpd.conf. Voir l’exemple ci–après.
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# Entrées VACM_ACCESS
#
Identifie les droits d’accès accordés aux différents groupe de sécurité
#
pour le modèle VACM (View–based Access Control Model).
# Format :
# groupName contextPrefix contextMatch securityLevel securityModel readView
writeView notifyView storageType
VACM_ACCESS group1 – – noAuthNoPriv SNMPv1 defaultView – defaultView –
VACM_ACCESS group2 – – noAuthNoPriv SNMPv1 group2View – group2View –
VACM_ACCESS group3 – – noAuthNoPriv SNMPv1 group3View group3View
group3View –
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Etape 3. Migration des informations d’interruption
Les informations d’interruption du fichier /etc/snmpd.conf deviennent les entrées NOTIFY,
TARGET_ADDRESS, et TARGET_PARAMETERS dans le fichier /etc/snmpdv3.conf.
Toutefois, seuls TARGET_ADDRESS et TARGET_PARAMETERS ont besoin d’être migrés.
1. Les adresses IP figurant dans les entrées d’interruption du fichier /etc/snmpd.conf
sont intégrés aux entrées TARGET_ADDRESS du fichier /etc/snmpdv3.conf. Cette ligne
spécifie l’hôte vers lequel le signal d’interruption sera envoyé. Vous pouvez définir les
entrées targetParams. Dans ce scénario, nous utilisons trapparms1, trapparms2,
trapparms3, et trapparms4, qui seront définis dans les entrées
TARGET_PARAMETERS .
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# TARGET_ADDRESS
#
Définit l’adresse et les paramètres d’une application de gestion
#
à utiliser pour envoyer des notifications.
# Format :
# targetAddrName tDomain tAddress tagList targetParams timeout retryCount
storageType
TARGET_ADDRESS Target1 UDP 127.0.0.1
traptag trapparms1 – – –
TARGET_ADDRESS Target2 UDP 9.3.149.49
traptag trapparms2 – – –
TARGET_ADDRESS Target3 UDP 9.3.149.49
traptag trapparms3 – – –
TARGET_ADDRESS Target4 UDP 9.53.150.67 traptag trapparms4 – – –
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
2. Les noms de communauté figurant dans les entrées d’interruption du fichier
/etc/snmpd.conf sont intégrés aux entrées TARGET_ PARAMETERS du fichier
/etc/snmpdv3.conf. Les noms de communauté doivent être mappés avec une entrée
TARGET_ADDRESS spécifique avec les valeurs targetParams. Par exemple, la
communauté daniel est mappée avec trapparms2, qui, sous l’entrée
TARGET_ADDRESS est mappée avec l’adresse IP 9.3.149.49. La communauté
daniel et l’adresse IP 9.3.149.49 étaient à l’origine une entrée d’interruption
dans le fichier /etc/snmpd.conf. Voir l’exemple ci–après :
1-12
Guide de gestion du système – Communications et réseaux
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# TARGET_PARAMETERS
#
Définit les paramètres de traitement des messages et de sécurité à
#
utiliser pour envoyer les notifications à une cible de gestion
particulière.
# Format :
# paramsName mpModel securityModel securityName securityLevel storageType
TARGET_PARAMETERS trapparms1 SNMPv1 SNMPv1 public noAuthNoPriv –
TARGET_PARAMETERS trapparms2 SNMPv1 SNMPv1 daniel noAuthNoPriv –
TARGET_PARAMETERS trapparms3 SNMPv1 SNMPv1 vasu
noAuthNoPriv –
TARGET_PARAMETERS trapparms4 SNMPv1 SNMPv1 david
noAuthNoPriv –
#–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
3. Les informations trapmask du fichier /etc/snmpd.conf ne migrent pas vers le fichier
/etc/snmpdv3.conf.
Etape 4. Migration des informations smux
Si vous disposez des informations smux que vous devez faire migrer, vous pouvez copier
ces lignes directement dans le nouveau fichier. Dans ce scénario, l’entrée smux sampled
a été configurée dans le fichier /etc/snmpd.conf. Cette ligne doit être copiée dans le fichier
/etc/snmpdv3.conf.
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
#
smux <client OIdentifier> <password> <address> <netmask>
smux
1.3.6.1.4.1.2.3.1.2.3.1.1
sampled_password #
sampled
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Etape 5. Arrêt et démarrage du démon snmpd
Une fois terminée la migration du démon /etc/snmpd.conf vers le fichier
/etc/snmpdv3.conf, arrêtez et démarrez le démon snmpd. Vous devez arrêter et démarrer
le démon snmpd chaque fois que vous modifiez le fichier /etc/snmpdv3.conf.
1. Entrez la commande suivante pour arrêter le démon :
stopsrc –s snmpd
2. Entrez la commande suivante pour redémarrer le démon :
startsrc –s snmpd
Remarque :
La simple actualisation de l’agent SNMPv3 ne fonctionne pas comme sous
SNMPv1. Si vous modifiez le fichier /etc/snmpdv3.conf, vous devez
arrêter et redémarrer le démon, comme indiqué dans la procédure
précédente. La fonction de configuration dynamique prise en charge dans
SNMPv3 ne vous permet pas d’actualisation.
Procédures des tâches d’administration réseau
1-13
Création d’utilisateurs dans SNMPv3
Ce scénario montre comment créer un utilisateur dans SNMPv3 en éditant manuellement
les fichiers /etc/snmpdv3.conf et /etc/clsnmp.conf.
L’utilisateur u1 sera créé dans ce scénario. L’utilisateur u1 reçoit des clés d’autorisation
mais pas des clés de confidentialité (qui sont disponibles uniquement si vous avez installé
le fichier snmp.crypto). Le protocole HMAC–MD5 servira à créer les clés d’autorisation de
u1. Une fois qu’u1 aura été configuré, il sera placé dans un groupe, puis les droits d’accès
d’affichage de ce groupe seront définis. Enfin, des entrées de signaux d’interruption seront
créées pour u1.
Chaque valeur individuelle utilisée dans les fichiers /etc/snmpdv3.conf et
/etc/clsnmp.conf ne doit pas excéder 32 octets.
Eléments à prendre en considération
Les informations contenues dans ces instructions ont été testées avec AIX 5.2.
Les résultats peuvent être sensiblement différents si vous utilisez une autre version
ou niveau de AIX.
Etape 1. Création de l’utilisateur
1. Choisissez le protocole de sécurité à utiliser, HMAC–MD5 ou HMAC–SHA.
Dans le présent scénario, HMAC–MD5 est utilisé.
2. Générez les clés d’authentification à l’aide de la commande pwtokey. Votre sortie peut
différer, selon le protocole d’authentification utilisé et l’utilisation ou non de clés de
confidentialité. Ces clés sont utilisées dans les fichiers /etc/snmpdv3.conf et
/etc/clsnmp.conf. La commande employée pour l’utilisateur u1 est la suivante :
pwtokey –p HMAC–MD5 –u auth
anypassword
9.3.230.119
L’adresse IP spécifiée est celle où s’exécute l’agent. Le mot de passe est quelconque,
mais veillez à le conserver en un lieu sûr en vue d’une utilisation ultérieure. Le résultat
est présenté de la manière suivante :
Affichage de la clé d’authentification 16 octets HMAC–MD5 localized
authKey :
63960c12520dc8829d27f7fbaf5a0470
Affichage de la clé d’authentification 16 octets HMAC–MD5 localized
authKey :
b3b6c6306d67e9c6f8e7e664a47ef9a0
3. Avec les droits de l’utilisateur racine, ouvrez le fichier /etc/snmpdv3.conf avec votre
éditeur favori.
4. Créez un utilisateur en ajoutant une entrée USM_USER suivant le format donné dans
le fichier. La valeur authKey est la clé d’authentification localisée générée avec la
commande pwtokey. L’entrée associée à l’utilisateur u1 est la suivante :
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# Entrées USM_USER
# Définit l’utilisateur pour le modèle USM (User–based Security Model).
# Format :
# userName engineID authProto authKey privProto privKey keyType storageType
#
USM_USER u1 – HMAC–MD5 b3b6c6306d67e9c6f8e7e664a47ef9a0 – – L –
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
– userName est le nom de l’utilisateur. Dans ce cas, il s’agit de u1.
– authProto doit être le protocole que vous avez utilisé lors de la création des clés.
Dans ce cas, il s’agit de HMAC–MD5.
– authKey est la clé d’authentification localisée générée avec la commande pwtokey.
1-14
Guide de gestion du système – Communications et réseaux
– privProto et privkey ne sont pas précisés car nous n’utilisons pas les clés de
confidentialité dans ce scénario.
– keyType est L parce que nous utilisons la clé d’authentification localisée.
5. Sauvegardez puis fermez le fichier /etc/snmpdv3.conf.
6. Ouvrez le fichier /etc/clsnmp.conf du gestionnaire SNMP sous votre éditeur favori.
7. Ajoutez le nouvel utilisateur selon le format donné dans le fichier. L’entrée associée à
l’utilisateur u1 est la suivante :
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
#
# Format des entrées :
# winSnmpName targetAgent admin secName password context secLevel authProto
authKey privProto privKey
#
user1 9.3.230.119 SNMPv3 u1 – – AuthNoPriv HMAC–MD5
63960c12520dc8829d27f7fbaf5a0470 – –
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
– winSnmpName peut être la valeur de votre choix. Cette valeur est utilisée lors des
requêtes SNMP à l’aide de la commande clsnmp.
– targetAgent représente l’adresse IP d’exécution de l’agent, qui a également servi
lors de la création des clés d’authentification.
– admin est défini comme SNMPv3 car nous allons envoyer des requêtes SNMPv3.
– secName est le nom de l’utilisateur que vous créez. Dans ce cas, il s’agit de u1.
– seclevel est défini comme AuthNoPriv car il est configuré pour utiliser
l’authentification mais pas la confidentialité (par conséquent, il n’y a pas de valeurs
pour privProto et privKey ).
– authproto est défini comme le protocole d’authentification utilisé pour créer les
clés d’authentification.
– authKey est la clé d’authentification non localisée générée avec la commande
pwtokey.
8. Sauvegardez et fermez le fichier /etc/clsnmp.conf.
Etape 2. Configuration du groupe
L’utilisateur doit maintenant être placé dans un groupe. Si vous disposez déjà d’un groupe
configuré avec tous les droits d’accès et d’affichage que vous voulez accorder à cet
utilisateur, vous pouvez y placer l’utilisateur. Si vous voulez doter cet utilisateur de droits
d’accès et d’affichage n’existant dans aucun groupe existant, créez un groupe dans lequel
vous ajoutez l’utilisateur.
Pour ajouter l’utilisateur à un nouveau groupe, créez une nouvelle entrée VACM_GROUP
dans le fichier /etc/snmpdv3.conf. L’entrée de groupe associée à l’utilisateur u1 est la
suivante :
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# entrées VACM_GROUP
# Définit un groupe de sécurité (composé d’utilisateurs ou de communautés)
# pour le modèle VACM (View–based Access Control Model).
# Format :
# groupName securityModel securityName storageType
VACM_GROUP group1 USM u1 –
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
• groupName peut être le nom de votre choix. Il devient le nom du groupe.
Dans ce cas, il s’agit de group1.
• securityModel est défini comme USM, qui tire parti des fonctionnalités de sécurité
SNMPv3.
• securityName est le nom de l’utilisateur. Dans ce cas, il s’agit de u1.
Procédures des tâches d’administration réseau
1-15
Etape 3. Configuration des permissions d’accès et d’affichage
Les droits d’accès et d’affichage doivent être définis pour le nouveau groupe que vous
venez de créer. Ces droits sont définis en ajoutant les entrées VACM_VIEW
etVACM_ACCESS au fichier /etc/snmpdv3.conf.
1. Choisissez les droits d’accès et d’affichage à accorder au groupe.
2. Ajoutez les entrées VACM_VIEW au fichier /etc/snmpdv3.conf pour définir les objets
MIB auquel le groupe peut accéder. Dans ce scénario, group1 aura accès aux
sous–arborescences MIB interfaces, tcp, icmp, et system . Nous allons toutefois
limiter l’accès de group1 à la variable MIB sysObjectID au sein de la
sous–arborescence MIB système.
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# Entrées VACM_VIEW
#
Définit un ensemble particulier de données MIB, appelé une vue, pour le
#
Modèle VACM (View–based Access Control Model).
# Format :
# viewName viewSubtree viewMask viewType storageType
VACM_VIEW group1View
interfaces
– included –
VACM_VIEW group1View
tcp
– included –
VACM_VIEW group1View
icmp
– included –
VACM_VIEW group1View
system
– included –
VACM_VIEW group1View
sysObjectID
– excluded –
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
–
viewName est le nom de la vue. Dans ce cas, il s’agit de group1View.
– viewSubtree est la sous–arborescence MIB à laquelle vous voulez donner accès.
– viewType détermine si les sous–arborescences MIB définies sont incluses dans la
vue. Dans le cas présent, toutes les sous–arborescences sont incluses, à l’exception
de la variable MIB sysObjectIDqui fait partie de la sous–arborescence system.
3. Ajoutez une entrée VACM_ACCESS au fichier /etc/snmpdv3.conf afin de définir les
droits accordés au groupe sur les objets MIB indiqués ci–dessus. Pour group1, un
accès en lecture seule est accordé.
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# Entrées VACM_ACCESS
#
Identifie les droits d’accès accordés aux différents groupe de sécurité
#
pour le modèle VACM (View–based Access Control Model).
# Format :
# groupName contextPrefix contextMatch securityLevel securityModel readView
writeView notifyView storageType
VACM_ACCESS group1 – – AuthNoPriv USM group1View – group1View –
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
– groupName est le nom du groupe. Dans ce cas, il s’agit de group1.
– securityLevel est le niveau de sécurité utilisé. Dans le présent scénario, des clés
d’authentification sont utilisées, mais pas des clés de confidentialité. La valeur est
donc définie sur AuthNoPriv.
– securityModel correspond au modèle de sécurité que vous utilisez (SNMPv1,
SNMPv2c ou USM). Dans le présent scénario, il est défini sur USM pour permettre
l’utilisation des dispositifs de sécurité SNMPv3.
– readView détermine les VACM_VIEWs auxquels le groupe a un accès en lecture.
Dans ce scénario, group1View est accordé, ce qui donne à group1 un accès en
lecture aux entrées group1View VACM_VIEW.
– writeView détermine les VACM_VIEWs auxquels le groupe a un accès en écriture.
Dans le présent scénario, aucun accès en écriture n’est accordé au group1.
1-16
Guide de gestion du système – Communications et réseaux
– notifyView spécifie le nom de la vue à appliquer en cas de signal d’interruption
exécuté sous le contrôle de l’entrée dans la table d’accès.
Remarque :
Il arrive que plusieurs entrées VACM_ACCESS soient nécessaires pour
un groupe. Si des utilisateurs du groupe ont des paramètres
d’authentification et de confidentialité différents ( noAuthNoPriv,
AuthNoPriv, ou AuthPriv ), plusieurs entrées VACM_ACCESS sont
requises et le paramètre securityLevel doit être défini en
conséquence.
Etape 4. Configuration des entrées d’interruption pour l’utilisateur
Les entrées d’interruption dans SNMPv3 sont créées en ajoutant les entrées NOTIFY,
TARGET_ADDRESS etTARGET_PARAMETERS au fichier /etc/snmpdv3.conf. L’entrée
TARGET_ADDRESS indique la destination des interruptions et l’entrée
TARGET_PARAMETERS établit une équivalence entre les informations de
TARGET_ADDRESS et group1.
L’entrée NOTIFY a été configurée par défaut. Voici l’entrée NOTIFY par défaut :
NOTIFY notify1 traptag trap –
Dans le présent scénario, nous utilisons la valeur qui est spécifiée dans l’entrée par défaut,
traptag.
1. Ajoutez une entrée TARGET_ADDRESS pour spécifier la destination des signaux
d’interruption.
#–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# TARGET_ADDRESS
#
Définit l’adresse et les paramètres d’une application de gestion
#
à utiliser pour envoyer des notifications.
# Format :
# targetAddrName tDomain tAddress tagList targetParams timeout retryCount
storageType
#––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
TARGET_ADDRESS Target1 UDP 9.3.207.107
traptag trapparms1 – – –
– targetAddrName peut être le nom de votre choix. Dans ce scénario,
nous avons utilisé Target1.
– tAddress est l’adresse IP à laquelle doivent être envoyés les signaux
d’interruption du groupe.
– tagList est le nom configuré dans l’entrée NOTIFY . Dans ce cas,
il s’agit de traptag.
– targetParams peut être la valeur de votre choix. Nous avons utilisé trapparms1,
qui sera employé dans l’entrée TARGET_PARAMETERS.
2. Ajoutez une entrée TARGET_PARAMETERS.
#–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
# TARGET_PARAMETERS
#
Définit les paramètres de traitement des messages et de sécurité
#
à utiliser pour envoyer les notifications à une cible de gestion
particulière.
# Format :
# paramsName mpModel securityModel securityName securityLevel storageType
#–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
TARGET_PARAMETERS trapparms1 SNMPv3 USM
u1
AuthNoPriv –
Procédures des tâches d’administration réseau
1-17
– paramsName est identique à la valeur targetParams dans l’entrée
TARGET_ADDRESS qui, dans ce cas, est trapparms1.
– mpModel est la version de SNMP qui est utilisée.
– securityModel correspond au modèle de sécurité que vous utilisez (SNMPv1,
SNMPv3 ou USM). Dans le présent scénario, il est défini sur USM pour permettre
l’utilisation des dispositifs de sécurité SNMPv3.
– securityName est le nom d’utilisateur indiquée dans l’entrée USM_USER qui,
dans ce cas, est u1.
– securityLevel est défini comme AuthNoPriv car nous utilisons des clés
d’authentification mais pas des clés de confidentialité.
Etape 5. Arrêt et démarrage du démon snmpd
Après avoir modifié le fichier /etc/snmpdv3.conf, arrêtez et démarrez le démon snmpd.
1. Entrez la commande suivante pour arrêter le démon snmpd :
stopsrc –s snmpd
2. Entrez la commande suivante pour arrêter le démon snmpd :
startsrc –s snmpd
Les nouveaux paramètres sont désormais validés.
Remarque :
La simple actualisation de l’agent SNMPv3 utilisant refresh –s snmpd
ne fonctionne pas comme sous SNMPv1. Si vous modifiez le fichier
/etc/snmpdv3.conf, vous devez arrêter et redémarrer le démon,
comme indiqué dans la procédure précédente. La fonction de configuration
dynamique prise en charge dans SNMPv3 ne vous permet pas
d’actualisation.
Etape 6. Test de votre configuration
Pour vérifier que votre configuration est correcte, vous pouvez lancer la commande
suivante dans le gestionnaire SNMP.
clsnmp –h user1 walk
mib
où mib est une sous–arborescence MIB à laquelle l’utilisateur a accès. Dans ce scénario,
il peut s’agir de interfaces, tcp, icmp, ou system. Si la configuration est correcte, vous
visualisez les informations dans la sous–arborescence spécifiée.
Si la sortie obtenue n’est pas correcte, révisez les étapes présentées dans ce document
et vérifiez que vous avez entré correctement toutes les informations.
1-18
Guide de gestion du système – Communications et réseaux
Mise à jour dynamique des clés d’authentification
et de confidentialité dans SNMPv3
Le présent scénario démontre comment mettre à jour dynamiquement des clés pour
un utilisateur dans SNMPv3. Dans ce scénario, l’utilisateur u4 met à jour les clés
d’authentification pour l’utilisateur u8. Les deux utilisateurs u4 et u8 ont déjà créé des clés
d’authentification basées sur le mot de passe defaultpassword et l’adresse IP
9.3.149.49, et le tout fonctionne correctement.
Dans ce scénario, de nouvelles clés sont créées pour l’utilisateur u8 et le fichier
/etc/snmpdv3.conf est mis à jour dynamiquement. La clé d’authentification de l’utilisateur
u8 se trouvant dans le fichier /etc/clsnmp.conf côté gestionnaire doit être modifiée
manuellement pour correspondre aux nouvelles clés.
Effectuez une sauvegarde du fichier /etc/snmpdv3.conf dans l’agent SNMP et une
sauvegarde du fichier /etc/clsnmp.conf dans le gestionnaire SNMP avant de démarrer
la procédure.
Ci–dessous se trouve le fichier /etc/snmpdv3.conf qui va être mis à jour dynamiquement :
USM_USER u4 – HMAC–MD5 18a2c7b78f3df552367383eef9db2e9f – – N –
USM_USER u8 – HMAC–SHA 754ebf6ab740556be9f0930b2a2256ca40e76ef9 – – N –
VACM_GROUP group1 SNMPv1 public
VACM_GROUP group2 USM u4 –
VACM_GROUP group2 USM u8 –
VACM_VIEW defaultView
VACM_ACCESS
VACM_ACCESS
VACM_ACCESS
VACM_ACCESS
group1
group2
group2
group2
–
–
–
–
–
internet
–
–
–
–
– included –
noAuthNoPriv SNMPv1 defaultView – defaultView –
noAuthNoPriv USM defaultView defaultView defaultView –
AuthNoPriv USM defaultView defaultView defaultView –
AuthPriv USM defaultView defaultView defaultView –
NOTIFY notify1 traptag trap –
TARGET_ADDRESS Target1 UDP 127.0.0.1
TARGET_ADDRESS Target2 UDP 9.3.149.49
TARGET_ADDRESS Target3 UDP 9.3.149.49
TARGET_ADDRESS Target4 UDP 9.3.149.49
traptag trapparms1 – – –
traptag trapparms2 – – –
traptag trapparms3 – – –
traptag trapparms4 – – –
TARGET_PARAMETERS trapparms1 SNMPv1 SNMPv1 public noAuthNoPriv –
TARGET_PARAMETERS trapparms3 SNMPv2c SNMPv2c publicv2c noAuthNoPriv –
TARGET_PARAMETERS trapparms4 SNMPv3 USM
u4 AuthNoPriv –
Ci–dessous se trouve le fichier /etc/clsnmp.conf qui va être mis à jour pour l’utilisateur u8 :
testu4 9.3.149.49 snmpv3 u4 – – AuthNoPriv HMAC–MD5
18a2c7b78f3df552367383eef9db2e9f – –
testu8 9.3.149.49 snmpv3 u8 – – AuthNoPriv HMAC–SHA
754ebf6ab740556be9f0930b2a2256ca40e76ef9 – –
Eléments à prendre en considération
Les informations contenues dans ces instructions ont été testées avec AIX 5.2.
Les résultats peuvent être sensiblement différents si vous utilisez une autre version
ou niveau de AIX.
Pour mettre à jour votre mot de passe et vos clés d’authentification, procédez comme suit :
1. Du côté du gestionnaire SNMP, exécutez la commande pwchange. Dans ce scénario,
la commande suivante est exécutée :
pwchange –u auth –p HMAC–SHA defaultpassword newpassword 9.3.149.49
Cette commande génère une nouvelle clé d’authentification.
Procédures des tâches d’administration réseau
1-19
– –u auth précise que seule une clé d’authentification sera créée. Si vous mettez à
jour les clés de confidentialité également, indiquez –u all.
– –p HMAC–SHA indique le protocole qui sera utilisé pour créer la clé
d’authentification. Si vous mettez à jour les clés de confidentialité également,
indiquez –p all.
– defaultpassword est le mot de passe utilisé pour créer la dernière clé
d’authentification (par exemple si bluepen aurait été utilisé pour créer la dernière
clé d’authentification, bluepen serait aussi utilisé ici)
– newpassword est le nouveau mot de passe qui sera utilisé pour générer le clé
d’authentification. Conservez–le pour référence ultérieure.
– 9.3.149.49 est l’adresse IP où s’exécute l’agent SNMP.
Cette commande a généré le résultat suivant :
Cliché de la valeur de 40 octets HMAC–SHA authKey keyChange :
8173701d7c00913af002a3379d4b150a
f9566f56a4dbde21dd778bb166a86249
4aa3a477e3b96e7d
Vous utiliserez cette clé d’authentification à l’étape suivante.
Remarque :
Conservez en lieu sûr les nouveaux mots de passe que vous utilisez.
Vous devrez les réutiliser lorsque vous effectuerez des modifications
ultérieurement.
2. Sur le gestionnaire SNMP, l’utilisateur u4 modifiera la clé d’authentification pour
l’utilisateur u8 en entrant la commande suivante :
clsnmp –h testu4 set
usmUserAuthKeyChange.12.0.0.0.2.0.0.0.0.9.3.149.49.2.117.56
\’8173701d7c00913af002a3379d4b150af9566f56a4dbde21dd778bb166a862494aa3a47
7e3b96e7d\’h
– testu4 est utilisé car il est mappé avec l’utilisateur u4 dans le fichier
/etc/clsnmp.conf.
– L’ID d’instance de usmUserAuthKeyChange inclut, en valeurs décimales, l’ID de
moteur de l’agent SNMP où se produit la mise à jour et le nom d’utilisateur dont la clé
d’authentification est mise à jour. L’ID moteur peut être trouvé dans le fichier
/etc/snmpd.boots (le fichier /etc/snmpd.boots contient deux chaînes de chiffres.
L’ID moteur correspond à la première chaîne. Ignorez la deuxième chaîne.
Il est nécessaire de convertir les valeurs hexadécimales de cet ID moteur pour
pouvoir l’utiliser. Tous les deux chiffres de l’ID moteur hexadécimal se convertissent
en une seule valeur décimale. Par exemple, l’ID moteur
000000020000000009039531 sera lu sous la forme 00 00 00 02 00 00 00
00 09 03 95 31. Chacun de ces nombres doit être converti en valeurs décimales,
donnant 0.0.0.2.0.0.0.0.9.3.149.49 (vous trouverez une table de
conversion dans Annexe E. Table de conversion page E-1). Le premier nombre de la
chaîne est le nombre d’octets de la chaîne décimale. Dans ce cas, il s’agit de 12,
dont le résultat est 12.0.0.0.2.0.0.0.0.9.3.149.49.
Le nombre suivant est le nombre d’octets du nom d’utilisateur, suivi des valeurs
décimales du nom d’utilisateur lui–même. Dans ce cas, le nom d’utilisateur est u8.
Lorsqu’il est converti en valeurs décimales, u8 devient 117.56. Parce que le nom
d’utilisateur a une longueur de 2 octets, la valeur représentant le nom d’utilisateur
devient 2.117.56. Vous pouvez l’ajouter à la fin de l’ID moteur décimal (vous
trouverez une table de conversion dans Annexe E. Table de conversion page E-1).
Dans ce cas, le résultat est 12.0.0.0.2.0.0.0.0.9.3.149.49.2.117.56.
– La valeur suivante de la commande est la nouvelle clé d’authentification générée à
l’aide de la commande pwchange dans l’étape précédente.
1-20
Guide de gestion du système – Communications et réseaux
Remarque :
Si des clés de confidentialité sont également configurées pour
l’utilisateur, cette procédure soit être réitérée pour leur mise à jour.
Lors de la mise à jour des clés de confidentialité, utilisez la valeur
usmUserPrivKeyChange à la place de la valeur
usmUserAuthKeyChange.
L’utilisation de usmUserOwnAuthKeyChange au lieu de
usmUserAuthKeyChange permet à l’utilisateur de modifier sa propre clé
d’authentification. Par exemple, l’utilisateur u4 peut modifier sa propre clé
d’authentification avec usmUserOwnAuthKeyChange.
La sortie de la commande est la suivante :
1.3.6.1.6.3.15.1.2.2.1.6.12.0.0.0.2.0.0.0.0.9.3.149.49.2.117.56 =
’8173701d7c00913af002a3379
d4b150af9566f56a4dbde21dd778bb166a862494aa3a477e3b96e7d’h
Une fois la commande terminée, le fichier /etc/snmpdv3.conf est automatiquement mis
à jour, au bout de 5 minutes, côté agent SNMP. Vous pouvez également arrêter puis
démarrer le démon SNMP pour mettre à jour le fichier. L’entrée suivant pour l’utilisateur
u8 est mise à jour dynamiquement dans le fichier /etc/snmpdv3.conf :
USM_USER u8 000000020000000009039531 HMAC–SHA
4be657b3ae92beee322ee5eaeef665b338caf2d9
None – L nonVolatile
3. Côté gestionnaire SNMP, lancez la commande pwtokey pour générer la nouvelle clé
d’authentification sur la base du nouveau mot de passe à placer dans le fichier
/etc/clsnmp.conf. Dans ce scénario, la commande suivante est exécutée :
pwtokey –u auth –p HMAC–SHA
newpassword 9.3.149.49
– –u auth précise que seule une clé d’authentification sera créée.
Si vous mettez à jour les clés de confidentialité également, indiquez –u all.
– –p HMAC–SHA indique le protocole qui sera utilisé pour créer la clé
d’authentification. Si vous mettez à jour les clés de confidentialité également,
indiquez –p all.
– Le mot de passe utilisé (dans ce cas newpassword) doit être le même que le mot de
passe utilisé lors de la génération de nouvelles clés d’authentification avec la
commande pwchange.
– L’adresse IP utilisée (dans le cas présent, 9.3.149.49) doit être celle où s’exécute
l’agent.
Le résultat donne les clés d’authentification localisées et non localisées :
Affichage de la clé d’authentification 20 octets HMAC–SHA authKey :
79ce23370c820332a7f2c7840c3439d12826c10d
Affichage de la clé d’authentification localisée 20 octets HMAC–SHA
localized authKey :
b07086b278163a4b873aace53a1a9ca250913f91
4. Ouvrez le fichier /etc/clsnmp.conf avec l’éditeur de votre choix et placez la clé
d’authentification non localisée sur la ligne correspondant à l’utilisateur dont les clés
sont mises à jour. Dans le présent scénario, l’entrée est la suivante :
testu8 9.3.149.49 snmpv3 u8 – – AuthNoPriv HMAC–SHA
79ce23370c820332a7f2c7840c3439d12826c10d – –
Enregistrez, puis fermez le fichier.
5. Testez la configuration mise à jour en exécutant la commande suivante :
clsnmp –v –h testu8 walk
mib
où mib est une variable MIB à laquelle l’utilisateur u8 a un accès en lecture.
Dans ce cas, l’utilisateur u8 a accès à Internet.
Procédures des tâches d’administration réseau
1-21
Création d’un alias local pour la messagerie électronique
La création d’alias locaux pour la messagerie électronique permet de créer des groupes
ou des listes de distribution auxquels du courrier peut être envoyé.
Dans ce scénario, geo@medussa, mark@zeus, ctw@athena, and dsf@plato sont ajoutés
à l’alias de messagerie testers. Une fois l’alias testers créé, glenda@hera reçoit la
propriété de l’alias.
Eléments à prendre en considération
Les informations contenues dans ces instructions ont été testées avec AIX 5.2.
Les résultats peuvent être sensiblement différents si vous utilisez une autre version
ou niveau de AIX.
Une fois l’alias testers ajouté au fichier /etc/mail/aliases, la base de données des alias
est recompilée à l’aide de la commande sendmail. Une fois la base de données
recompilée, des messages électroniques peuvent être envoyés à l’alias testers.
1. Ouvrez le fichier /etc/mail/aliases sous votre éditeur favori.
2. Sur une ligne vierge, ajoutez un nom d’alias suivi de deux points (:) et d’une liste de
destinataires séparés par une virgule. Par exemple, l’entrée suivante définit l’alias
testers :
testers: geo@medussa, mark@zeus, ctw@athena, dsf@plato
3. Créez le propriétaire de l’alias. Si la commande sendmail ne parvient pas à envoyer
du courrier à l’alias, elle envoie un message d’erreur au propriétaire.
Ajoutez une ligne dans /etc/mail/aliases pour indiquer le propriétaire. Le format de cette
ligne est owner– groupname: owner, où groupname est le nom de l’alias et owner
l’adresse électronique du propriétaire. Dans cet exemple, glenda@hera est défini
comme le propriétaire de l’alias testers :
testers: geo@medussa, mark@zeus, ctw@athena, dsf@plato
owner–testers: glenda@hera
4. Une fois l’alias créé, exécutez la commande sendmail –bi pour recompiler la base
de données des alias. Vous devez exécuter cette commande à chaque fois que vous
mettez à jour le fichier /etc/mail/aliases.
Vous pouvez maintenant envoyer des messages à l’alias testers.
1-22
Guide de gestion du système – Communications et réseaux
Configuration des serveurs de nom de domaine
Dans ce scénario, un serveur de noms maître, un serveur de noms esclave et un serveur
de noms d’indice est configuré pour effectuer une résolution de noms. Chaque serveur de
noms est une machine distincte et pour chacun, un fichier /etc/named.conf est configuré,
même si les informations de chacun sont différentes. Le fichier /etc/named.conf est lu
chaque fois que le démon named est démarré. Il indique le type du serveur
(maître, esclave, indice) et l’endroit où il obtient ses données de résolution de noms.
Chacun de ces serveurs de noms exécute BIND 8.
Le serveur de noms maître est configuré pour fournir une résolution de noms pour la zone
abc.aus.century.com. Dans ce scénario, l’adresse IP du serveur de noms maître est
192.9.201.1, et son nom hôte est venus.abc.aus.century.com. Il fournit une
résolution de noms pour les noms hôte venus, earth, mars, et jupiter. Le fichier
/etc/named.conf est configuré pour indiquer que le démon named doit rechercher les
fichiers de données dans le répertoire /usr/local/domain. Les fichiers de données qui
seront configurés pour le serveur de noms maître sont named.ca, named.abc.local,
named.abc.data, et named.abc.rev.
Un serveur de noms esclave est alors configuré. Le nom hôte du serveur de noms esclave
est earth.abc.aus.century.com, et son adresse IP est 192.9.201.5. Dans le fichier
/etc/named.conf du serveur de noms esclave, nous indiquons l’adresse du serveur de
noms maître de façon à ce que le serveur de noms esclave puisse répliquer les fichiers
named.abc.data et named.abc.rev du serveur de noms maître. En outre, les fichiers de
données named.ca et named.abc.local sont configurés pour ce serveur.
Un serveur de noms d’indices est alors configuré. Le serveur de noms d’indices stocke une
cache locale contenant le nom hôte et les équivalences d’adresses. Si une adresse ou un
nom hôte demandé ne se trouve pas dans sa cache, le serveur d’indices contacte le
serveur de noms maître, obtient les informations de résolution et les ajoute à sa cache.
En outre, les fichiers de données named.ca et named.abc.local sont configurés pour ce
serveur.
Toutes les informations des fichiers de données named (pas le fichier /etc/named.conf)
des serveurs de noms doivent avoir le format Standard Resource Record Format. Pour
plus de détails sur les informations contenues dans les fichiers de données named,
reportez–vous à Standard Resource Record Format for TCP/IP dans le manuel AIX 5L
Version 5.3 Files Reference
L’administrateur de chacun des serveurs de noms est
gail.zeus.abc.aus.century.com. Ceci est indiqué dans les fichiers de données
locaux de chaque serveur de noms. En outre, dans ce scénario, le serveur de noms racine
est relay.century.com, avec l’adresse IP 129.114.1.2.
A la fin de ce scénario, la résolution de noms est fournie pour les hôtes venus, earth, mars,
et jupiter. En outre, une résolution de noms inverse (adresse IP en nom hôte) est fournie.
Lorsqu’une demande impossible à résoudre est reçue, le serveur de noms maître contacte
relay.century.com pour trouver les informations requises.
Eléments à prendre en considération
Les informations contenues dans ces instructions ont été testées avec AIX 5.2.
Les résultats peuvent être sensiblement différents si vous utilisez une autre version
ou niveau de AIX.
Procédures des tâches d’administration réseau
1-23
Etape 1. Configuration du serveur de noms maître
1. Sur le serveur de noms maître, ouvrez le fichier /etc/named.conf. S’il n’existe pas
de fichiers /etc/named.conf dans le répertoire /etc, créez–en un en exécutant la
commande suivante :
touch /etc/named.conf
Procédez comme suit pour configurer le fichier /etc/named.conf :
a. Indiquez une clause de répertoire dans la strophe des options. Ceci permet aux
fichiers de données named d’utiliser des chemins relatifs au répertoire
/usr/local/domain. Dans ce scénario, ce qui suit a été ajouté :
options {
directory ”/usr/local/domain”;
};
Si vous choisissez de ne pas indiquer de répertoire, les fichiers de données requis sont
recherchés dans le répertoire /etc.
b. Pour stocker des données d’enregistrement en dehors des zones définies, spécifiez
le nom du fichier de zone d’indices. Dans ce scénario, ce qui suit a été ajouté :
zone ”.” IN {
type hint;
file ”named.ca”;
};
c. Ajoutez les strophes suivantes pour spécifier chaque zone, le type de serveur de
noms que vous configurez et le fichier de données du domaine de votre serveur de
noms. Dans ce scénario, le serveur maître des zones avant et inverse est le suivant :
zone ”abc.aus.century.com” in {
type master;
file ”named.abc.data”;
};
zone ”201.9.192.in–addr.arpa” in {
type master;
file ”named.abc.rev”;
};
d. Définissez le nom du fichier named local. Par exemple :
zone ”0.0.127.in–addr.arpa” in {
type master;
file ”named.abc.local”;
};
Après avoir édité le fichier, enregistrez–le et fermez–le.
2. Ouvrez le fichier /usr/local/domain/named.ca. Ajoutez les adresses des serveurs de
noms racine du domaine. Ce qui suit a été ajouté dans ce scénario :
; root name servers.
.
IN
NS
relay.century.com.
relay.century.com.
3600000
IN
A
129.114.1.2
Après avoir édité le fichier, enregistrez–le et fermez–le.
3. Ouvrez le fichier /usr/local/domain/named.abc.local. Ajoutez les informations
suivantes :
1-24
Guide de gestion du système – Communications et réseaux
– La valeur de SOA (Start Of Authority) de la zone et les délais TTL (time–to–live)
par défaut. Ce qui suit a été ajouté dans ce scénario :
$TTL 3h
;3 hour
@ IN SOA venus.abc.aus.century.com. gail.zeus.abc.aus.century.com.
1
3600
600
3600000
3600
(
;serial
;refresh
;retry
;expire
;negative caching TTL
)
– L’enregistrement du serveur de noms (NS). Insérez une tabulation au début de la
ligne. Le démon named remplace la tabulation par le nom de zone :
IN
<tab>
NS
venus.abc.aus.century.com.
– L’enregistrement PTR (pointeur).
1
IN
PTR
localhost.
Après avoir édité le fichier, enregistrez–le et fermez–le.
4. Ouvrez le fichier /usr/local/domain/named.abc.data. Ajoutez les informations
suivantes :
– La valeur de SOA (Start Of Authority) et les délais TTL (timetolive) par défaut de
la zone. Cet article indique le début de la zone. Un seul article de SOA par zone est
autorisé. Dans ce scénario, ce qui suit a été ajouté :
$TTL 3h
;3 hour
@ IN
SOA
venus.abc.aus.century.com.
gail.zeus.abc.aus.century.com. (
1
;serial
3600
;refresh
600
;retry
3600000 ;expire
3600
;negative caching TTL
)
– Les enregistrements du serveur de noms de tous les serveurs de noms maîtres de
la zone. Insérez une tabulation au début de la ligne. Le démon named remplace la
tabulation par le nom de zone :
<tab>
IN
NS
venus.abc.aus.century.com.
– Les informations de résolution de noms en adresses pour tous les hôtes dans la zone
d’autorité du serveur de noms.
venus
earth
mars
jupiter
IN
IN
IN
IN
A
A
A
A
192.9.201.1
192.9.201.5
192.9.201.3
192.9.201.7
Insérez d’autres types d’entrée : articles de nom canonique ou de serveur de noms
(facultatif). Après avoir édité le fichier, enregistrez–le et fermez–le.
Procédures des tâches d’administration réseau
1-25
5. Ouvrez le fichier /usr/local/domain/named.abc.rev. Ajoutez les informations suivantes :
– La valeur de SOA (Start Of Authority) de la zone et les délais TTL (time–to–live) par
défaut. Cet article indique le début de la zone. Un seul article de SOA par zone est
autorisé :
$TTL 3h
@
(
IN
;3 hour
SOA
venus.abc.aus.century.com. gail.zeus.abc.aus.century.com.
1
3600
600
3600000
3600
;serial
;refresh
;retry
;expire
;negative caching TTL
)
– Les autres types d’entrées, tels que les articles de serveur de noms. Si vous incluez
ces articles, insérez une tabulation au début de la ligne. Le démon named remplace
la tabulation par le nom de zone. Dans ce scénario, ce qui suit a été ajouté :
<tab>
IN
NS
venus.abc.aus.century.com.
– Des informations de résolution adresse–nom sur tous les hôtes à placer dans la zone
d’autorité du serveur de noms.
1
5
3
7
IN
IN
IN
IN
PTR
PTR
PTR
PTR
venus.abc.aus.century.com.
earth.abc.aus.century.com.
mars.abc.aus.century.com.
jupiter.abc.aus.century.com.
Après avoir édité le fichier, enregistrez–le et fermez–le.
6. Créez un fichier /etc/resolv.conf via la commande :
touch /etc/resolv.conf
La présence de ce fichier indique que l’hôte doit utiliser un serveur de noms pour la
résolution de noms.
7. Ajoutez l’entrée suivante dans le fichier /etc/resolv.conf :
nameserver 127.0.0.1
127.0.0.1 est l’adresse de bouclage qui, pour l’accès au serveur de noms, dirige l’hôte
vers lui–même. Ce fichier /etc/resolv.conf peut également comporter une ligne du type :
domain abc.aus.century.com
Dans ce cas, abc.aus.century.com est le nom du domaine. Après avoir édité le
fichier, enregistrez–le et fermez–le.
8. Utilisez le raccourci SMIT smit stnamed pour activer le démon named. Cette
commande initialise le démon à chaque lancement du système. Indiquez quand vous
souhaitez lancer le démon named : immédiatement, au prochain lancement du système
ou les deux.
1-26
Guide de gestion du système – Communications et réseaux
Etape 2. Configuration du serveur de noms esclave
Pour configurer un serveur de noms esclave, utilisez la procédure suivante.
Editez une série de fichiers puis utilisez SMIT pour démarrer le démon named.
1. Sur le serveur de noms esclave, ouvrez le fichier /etc/named.conf. S’il n’existe pas
de fichiers /etc/named.conf dans le répertoire /etc, créez–en un en exécutant la
commande suivante :
touch /etc/named.conf
Procédez comme suit pour configurer le fichier /etc/named.conf :
a. Indiquez une clause de répertoire dans la strophe des options. Ceci permet aux
fichiers de données named d’utiliser des chemins relatifs au répertoire
/usr/local/domain. Dans ce scénario, ce qui suit a été ajouté :
options {
directory ”/usr/local/domain”;
};
Si vous choisissez de ne pas indiquer de répertoire, le démon named recherche les
fichiers de données requis dans le répertoire /etc.
b. Pour stocker des données d’enregistrement en dehors des zones définies,
spécifiez le nom du fichier de zone d’indices pour le serveur de noms.
zone ”.” IN {
type hint;
file ”named.ca”;
};
c. Spécifiez les clauses de zone esclave. Chaque strophe comprend le type de zone,
un nom de fichier dans lequel le serveur de noms peut sauvegarder ses données et
l’adresse IP du serveur de noms maître, à partir duquel le serveur de noms maître
peut répliquer ses fichiers de données. Dans ce scénario, nous avons ajouté les
clauses de zone esclave suivantes :
zone ”abc.aus.century.com” IN {
type slave;
file ”named.abc.data.bak”;
masters { 192.9.201.1; };
};
zone ”201.9.192.in–addr.arpa” IN {
type slave;
file ”named.abc.rev.bak”;
masters { 192.9.201.1; };
};
d. Pour supporter l’adressage en boucle, indiquez une zone de type maître avec comme
source le fichier named.abc.local, ainsi que le domaine dont le serveur de noms
est responsable.
zone ”0.0.127.in–addr.arpa” in {
type master;
file ”named.abc.local”;
};
Après avoir édité le fichier, enregistrez–le et fermez–le.
2. Editez le fichier /usr/local/domain/named.ca
Ce fichier contient le serveur d’adresses qui est le serveur de domaine racine du réseau.
Dans ce scénario, ce qui suit a été ajouté :
; root name servers.
.
IN
NS
relay.century.com.
relay.century.com.
3600000
IN
A
129.114.1.2
Après avoir édité le fichier, enregistrez–le et fermez–le.
Procédures des tâches d’administration réseau
1-27
3. Ouvrez le fichier /usr/local/domain/named.abc.local. Dans ce scénario,
ce qui suit a été ajouté :
– La valeur de SOA (Start Of Authority) de la zone et les délais TTL (time–to–live)
par défaut :
$TTL 3h
;3 hour
@ IN SOA earth.abc.aus.century.com. gail.zeus.abc.aus.century.com.
1
3600
600
3600000
3600
(
;serial
;refresh
;retry
;expire
;negative caching TTL
)
– L’enregistrement du serveur de noms (NS). Insérez une tabulation au début de la
ligne. Le démon named remplace la tabulation par le nom de zone. Par exemple :
IN
<tab>
NS
earth.abc.aus.century.com.
– L’enregistrement PTR (pointeur).
1
IN
PTR
localhost.
Après avoir édité le fichier, enregistrez–le et fermez–le.
4. Créez un fichier /etc/resolv.conf via la commande :
touch /etc/resolv.conf
5. Ajoutez les lignes suivantes au fichier :
nameserver 127.0.0.1
domain abc.aus.century.com
Après avoir édité le fichier, enregistrez–le et fermez–le.
6. Utilisez le raccourci SMIT smit stnamed pour activer le démon named. Cette
commande initialise le démon à chaque lancement du système. Indiquez quand vous
souhaitez lancer le démon named : immédiatement, au prochain lancement du système
ou les deux.
1-28
Guide de gestion du système – Communications et réseaux
Etape 3. Configuration du serveur de noms d’indices
Pour configurer un serveur de noms d’indices ou de mémoire cache uniquement, suivez la
procédure ci–dessous, qui édite une série de fichiers puis a recours à SMIT ou à la ligne de
commande pour démarrer le démon named.
1. Sur le serveur de noms d’indices, ouvrez le fichier /etc/named.conf. S’il n’existe pas
de fichiers /etc/named.conf dans le répertoire /etc, créez–en un en exécutant la
commande suivante :
touch /etc/named.conf
Procédez comme suit pour configurer le fichier /etc/named.conf :
a. Indiquez une clause de répertoire dans la strophe des options. Ceci permet aux
fichiers de données named d’utiliser des chemins relatifs au répertoire
/usr/local/domain. Dans ce scénario, ce qui suit a été ajouté :
options {
directory ”/usr/local/domain”;
};
b. Pour supporter l’adressage en boucle, indiquez une zone de type maître avec comme
source le fichier named.abc.local, ainsi que le domaine dont le serveur de noms est
responsable. Dans cet exemple, le mot–clé du répertoire d’options a été indiqué dans
le fichier /etc/named.conf.
zone ”0.0.127.in–addr.arpa” IN {
type master;
file ”named.abc.local”;
};
c. Spécifiez le nom du fichier de zone de cache. Par exemple :
zone ”.” IN {
type hint;
file ”named.ca”;
};
Après avoir édité le fichier, enregistrez–le et fermez–le.
2. Editez le fichier /usr/local/domain/named.ca
Ce fichier contient l’adresse des serveurs de noms ”experts” pour le domaine racine
(root) du réseau. Par exemple :
; root name servers.
.
IN
NS
relay.century.com.
relay.century.com.
3600000
IN
A
129.114.1.2
Après avoir édité le fichier, enregistrez–le et fermez–le.
3. Editez le fichier /usr/local/domain/named.local. Dans ce scénario, les informations
suivantes ont été ajoutées :
– La valeur de SOA (Start Of Authority) de la zone et les délais TTL (time–to–live)
par défaut :
$TTL 3h
@
(
IN
;3 hour
SOA
venus.abc.aus.century.com. gail.zeus.abc.aus.century.com.
1
3600
600
3600000
3600
;serial
;refresh
;retry
;expire
;negative caching TTL
)
Procédures des tâches d’administration réseau
1-29
– L’enregistrement du serveur de noms (NS). Insérez une tabulation au début de la
ligne. Le démon named remplace la tabulation par le nom de zone :
IN
<tab>
NS
venus.abc.aus.century.com.
– L’enregistrement PTR (pointeur).
1
IN
PTR
localhost.
Après avoir édité le fichier, enregistrez–le et fermez–le.
4. Créez un fichier /etc/resolv.conf via la commande :
touch /etc/resolv.conf
5. Ajoutez les lignes suivantes au fichier :
nameserver 127.0.0.1
domain abc.aus.century.com
Après avoir édité le fichier, enregistrez–le et fermez–le.
6. Utilisez le raccourci SMIT smit stnamed pour activer le démon named. Cette
commande initialise le démon à chaque lancement du système. Indiquez quand vous
souhaitez lancer le démon named : immédiatement, au prochain lancement du système
ou les deux.
1-30
Guide de gestion du système – Communications et réseaux
Chapitre 2. Communications et réseaux : généralités
Ce chapitre présente les concepts de base pour la compréhension des systèmes
en réseau. Il est destiné à l’administrateur système peu familiarisé avec les réseaux.
Ceux qui maîtrisent déjà ces concepts sous UNIX peuvent passer directement
au chapitre suivant.
Un réseau est la combinaison d’un ou plusieurs ordinateurs interconnectés.
Le réseau physique regroupe les éléments matériels du réseau (cartes, câbles,
lignes téléphoniques, etc). Quant au réseau logique, il comporte les éléments
logiciels et le modèle conceptuel du réseau.
Les concepts présentés sont les suivants :
• Fonctions de communication, page 2-2
• Présentation des réseaux, page 2-3
• Réseaux physiques, page 2-5
• Systèmes et protocoles réseau, page 2-6
• Communication avec d’autres systèmes d’exploitation, page 2-8
Communications et réseaux : généralités
2-1
Fonctions de communication
Les réseaux offrent diverses fonctions de communication dédiées aux applications et aux
utilisateurs. Ils permettent par exemple aux utilisateurs d’effectuer les tâches suivantes :
• Envoi de courrier électronique (e–mail)
• Emulation d’un terminal ou connexion à un autre ordinateur.
• Transfert de données.
• Exécution de programmes résidant sur un nœud distant.
L’application de réseau la plus répandue est la messagerie électronique, qui permet aux
utilisateurs d’échanger des messages. Les utilisateurs peuvent se trouver sur le même
système (dans ce cas un réseau n’est pas nécessaire), sur des systèmes différents situés
dans des immeubles différents, voire des pays différents.
Un réseau de communication permet également à un système d’en simuler un autre de
façon à accéder aux informations, comme s’il était un autre type d’ordinateur ou de terminal.
La connexion par le réseau à un système distant donne accès aux mêmes programmes et
fichiers qu’avec une connexion locale sans réseau.
La connexion par le réseau à un système distant donne accès aux mêmes programmes et
fichiers qu’avec une connexion locale sans réseau. Les données sont transférables par le
réseau d’un système à un autre, qu’il s’agisse de fichiers, de répertoires ou de systèmes de
fichiers complets. Elles peuvent être sauvegardées à distance et dupliquées sur plusieurs
machines pour parer aux défaillances matérielles.
Il existe plusieurs protocoles permettant aux applications et aux utilisateurs d’un système
d’appeler des procédures et des applications d’un autre système, ce qui est utile pour
répartir la charge des routines particulièrement lourdes.
2-2
Guide de gestion du système – Communications et réseaux
Présentation des réseaux
La complexité des réseaux informatiques modernes a donné lieu à plusieurs modèles
conceptuels de réseaux. Le plus connu est le modèle de référence pour l’interconnexion
des systèmes ouverts (OSI) proposé par l’organisation internationale de normalisation
(ISO), aussi appelé modèle OSI en sept couches. Les sept couches du modèle OSI
sont numérotées comme suit :
7
Application
6
Présentation
5
Session
4
Transport
3
Réseau
2
Liaison
1
Physique
Les niveaux 1 à 3 sont propres aux réseaux et varient en fonction du réseau physique
utilisé. Les niveaux 4 à 7 couvrent les fonctions de haut niveau, indépendantes du réseau.
Chacune de ces couches décrit une fonction de communication spécifique et non un
protocole donné. Les sept couches fonctionnent du niveau le plus bas (niveau machine)
au niveau le plus haut (le niveau auquel la plupart des échanges humains interviennent),
comme suit :
Application
Englobe les applications qui utilisent le réseau.
Présentation
Met en forme les données pour les rendre cohérentes pour les
applications.
Session
Gère les connexions entre les applications.
Transport
Assure l’acheminement des données sans erreur.
Réseau
Gère les connexions aux autres machines du réseau.
Liaison
Assure la transmission des données à travers la couche physique
(qui, par nature, n’est pas fiable).
Physique
Décrit les supports physiques du réseau. Par exemple, le câble à
fibre optique requis pour un réseau FDDI (Fiber Distributed Data
Interface) fait partie de la couche physique.
Remarque :
Le modèle de référence OSI, utile pour la présentation conceptuelle,
n’est en pratique pas toujours scrupuleusement suivi par les protocoles
de réseau. Par exemple, lors de la discussion du protocole TCP/IP, les
fonctions des couches Application et Présentation peuvent être combinées,
de même que les couches Session et Transport, ainsi que les couches
Liaison et Physique.
Chaque couche du modèle OSI communique avec la couche équivalente sur la machine
distante (cf. figure Modèle de référence OSI). Elle transmet les données uniquement aux
couches situées immédiatement au-dessus ou au-dessous d’elle. Chaque couche
encapsule les informations héritées des couches supérieures et ajoute ses propres
informations d’en-tête (et de fin pour la couche Liaison).
Communications et réseaux : généralités
2-3
Figure 1. Modèle de référence OSI Cette illustration montre les différents niveaux
de communication du Modèle OSI décrits dans le texte précédent.
Données
7 Application
En–tête
6 Présentation
5 Session
En–tête
En–tête
4 Transport
En–tête
3 Réseau
En–tête
2 Liaison
1 Physique
En–tête
Données
Données
Données
Données
Données
Bas de page
Données
Les réseaux offrent nombre de possibilités aux entreprises et aux particuliers :
• Entrée de données,
• Recherche de données,
• Soumission par lots à distance,
• Partage des ressources
• Partage des données,
• Courrier électronique.
Une entrée de données correspond à une importation de données directement dans des
fichiers de données locaux ou distants. Par là-même, les risques d’échec ou d’erreur liés
à un transfert en plusieurs étapes sont réduits. La recherche des données consiste à
examiner des fichiers de données pour obtenir des informations particulières. Leur mise à
jour consiste à modifier, ajouter ou supprimer des informations stockées dans des fichiers
locaux ou distants. La soumission par lots à distance consiste à entrer à distance des trains
de données traités le plus souvent durant la nuit ou une période de faible activité. Pour
toutes ces fonctions, les communications et réseaux se révèlent non seulement
souhaitables mais aussi indispensables.
Les réseaux autorisent également le partage des ressources : données, programmes,
espace de stockage et périphériques (tels que les imprimantes, les modems, les terminaux
et les disques inamovibles). Cette particularité accroît à la fois la rentabilité du système
(périphériques partagés) et sa fonctionnalité (une seule copie des programmes et fichiers,
évitant ainsi tout problème de cohérence inhérent aux copies multiples).
2-4
Guide de gestion du système – Communications et réseaux
Réseaux physiques
Le réseau physique est constitué par l’ensemble des câbles (coaxiaux, à paire torsadée,
optiques ou téléphoniques) qui relient les unités matérielles, les cartes des systèmes hôtes
raccordés et les éventuels concentrateurs, répéteurs, routeurs et ponts utilisés sur le
réseau. (Le terme hôte est employé dans le sens d’ordinateur connecté au réseau.)
Les réseaux physiques varient en fonction de leur taille et du type de matériel qui les
composent. On distingue généralement les réseaux locaux (LAN) des réseaux longue
distance (WAN). Un réseau local couvre une zone géographiquement réduite (1 à 10 km),
comme par exemple un immeuble de bureaux, un entrepôt, un campus, par opposition au
réseau longue distance (WAN) qui dessert une zone plus vaste (pays, continent, etc.) Un
réseau longue distance (WAN) fournit des communications de données dans une zone plus
vaste (pays, continent, etc.) que celle desservie par un réseau local (LAN). Un modèle
intermédiaire de réseau existe également, appelé metropolitan area networks (MAN).
Dans ce guide, les réseaux MAN sont généralement englobés dans les réseaux WAN.
Les réseaux locaux utilisent généralement des équipements Ethernet standard,
IEEE 802.3 ou en anneau à jeton, et les réseaux longue distance et asynchrones utilisent
les moyens de communication fournis par les entreprises de télécommunications.
Dans les deux cas, les opérations effectuées sur le réseau physique sont généralement
soumises à des normes de communications réseau telles que l’EIA (Electronics Industry
Association) ou l’ITU (International Telecommunication Union).
Communications et réseaux : généralités
2-5
Systèmes réseau et protocoles
Toute communication sur un réseau requiert un support matériel et logiciel. Le matériel est
l’équipement physique connecté au réseau physique. Le logiciel regroupe les programmes
et les pilotes de périphérique utilisés pour l’exploitation d’un système.
L’équipement matériel d’un système comprend les cartes et autres dispositifs qui donnent
accès ou font office d’interface entre la partie logicielle du système et le réseau physique.
Chacune de ces cartes doit être installée à un emplacement de carte d’entrée/sortie (E/S)
sur le système. D’autres dispositifs, tels que les modems, peuvent être raccordés à un port
standard de l’ordinateur.
Ces cartes sont compatibles avec les normes du réseau physique (par exemple, EIA 232D,
Smartmodem, V.25 bis, EIA 422A, X.21 ou V.35) et avec les protocoles utilisés (par
exemple, les protocoles SDLC, HDLC et bisynchrones). Le support logiciel, s’il n’est pas
intégré à la carte, est fourni par le pilote de la carte.
Protocoles
Tout logiciel de communication fait appel à un protocole (ou plusieurs), ensemble de règles
sémantiques et syntaxiques qui définissent comment les unités fonctionnelles assurent la
communication : livraison de l’information, conditionnement des données pour en assurer
l’intégrité jusqu’à destination, et chemin d’accès. Les protocoles se chargent également de
coordonner le flux de messages et leur acquittement.
Les protocoles interviennent à différents niveaux du noyau et ne peuvent être manipulés
directement. Leur activation s’effectue en fonction des programmes sollicités par l’utilisateur
au niveau de l’interface de programmation d’application (API) lors de l’exécution des tâches
(transfert de fichiers, connexion à distance, émulation de terminal, etc.).
Adresses
Les adresses associées à la fois au logiciel et au matériel, indiquent à la station expéditrice
ou au poste de contrôle comment identifier la station du destinataire : elles permettent de
localiser les emplacements de stockage et de réception. Une adresse physique est un code
unique attribué à chaque unité ou station connectée à un réseau.
Par exemple, sur un réseau en anneau à jeton, la commande netstat –iv affiche l’adresse
de la carte dédiée à ce type de réseau. Il s’agit de l’adresse physique. La commande
netstat –iv procure également des informations d’adressage au niveau de l’utilisateur et de
la classe. Les adresses sont souvent définies par le logiciel, mais il arrive qu’elles soient
créées également par l’utilisateur.
Domaines
Liée au concept d’adresse, la notion de domaine est commune à un grand nombre de
réseaux de communication. La structure d’Internet, par exemple, illustre comment les
domaines définissent l’adresse IP (Internet Protocol). Internet est un réseau extensif qui
regroupe de nombreux réseaux de moindre envergure. Les adresses Internet sont
structurées hiérarchiquement en domaines pour faciliter le routage et l’adressage.
Au sommet de la structure se trouvent les catégories les plus générales, par exemple com
pour le secteur commercial, edu pour le secteur de l’enseignement et gov.
Le domaine com est divisé en domaines plus restreints correspondant aux entreprises
individuelles, ibm, par exemple. Ce domaine ibm.com est à son tour divisé en
sous-domaines qui, cette fois, correspondent aux adresses Internet des divers sites, par
exemple austin.ibm.com ou raleigh.ibm.com. C’est à ce niveau que commencent à
apparaître le nom des hôtes. Dans ce contexte, les hôtes sont les ordinateurs connectés au
réseau. Par exemple, le domaine austin.ibm.com peut comporter les systèmes hamlet
et lear, aux adresses respectives hamlet.austin.ibm.com et
lear.austin.ibm.com.
2-6
Guide de gestion du système – Communications et réseaux
Passerelles et ponts
Le réseau Internet regroupe une grande variété de réseaux faisant intervenir divers
matériels et logiciels. La communication entre ces réseaux hétérogènes s’effectue par le
biais de passerelles et de ponts. Un pont est une unité fonctionnelle qui relie deux réseaux
locaux pouvant utiliser la même procédure de contrôle de liaison logique (LLC), Ethernet
par exemple, mais des procédures de contrôle d’accès au support (MAC) différentes. La
passerelle couvre un champ plus large : elle intervient au–dessus de la couche Liaison et
assure, s’il y a lieu, la conversion des protocoles et des interfaces pour permettre à deux
protocoles de communiquer entre eux. Elle permet le transfert des données à travers les
divers réseaux qui composent Internet.
Routage
L’utilisation de noms de domaines pour l’adressage et de passerelles pour le transfert
facilite grandement le routage, opération qui consiste à définir le parcours d’un message
jusqu’à sa destination. En effet, c’est le nom du domaine qui définit la destination : dans un
réseau étendu comme Internet, l’information est acheminée d’un réseau de communication
au suivant jusqu’à destination. Chacun des réseaux vérifie le nom du domaine en fonction
de ceux qu’il connaît et achemine l’information, jusqu’à l’extrémité logique suivante. Ainsi,
chaque réseau par lequel les données transitent participe au processus de routage.
Noeud local et noeud distant
Un réseau physique est utilisé par les systèmes hôtes qui y résident. Chacun de ces
systèmes hôtes est un noeud sur le réseau. C’est-à-dire un point adressable du réseau qui
offre des services de traitement hôte. L’intercommunication entre ces différents nœuds
engendre les notions de local et de distant. Local s’applique aux unités, fichiers ou
systèmes directement accessibles à partir de votre système, sans recourir à une ligne de
communication. Distant s’applique aux unités, fichiers ou systèmes accessibles à partir de
votre système via une ligne de communication. En effet, les fichiers locaux sont implantés
sur votre système alors que les fichiers distants résident sur un serveur de fichiers ou un
autre noeud accessible via un réseau physique, par exemple, un réseau Ethernet, un
réseau en anneau à jeton ou des lignes téléphoniques.
Client et serveur
Les concepts de client et de serveur sont liés aux notions de ”local” et de ”distant”. Un
serveur est un ordinateur qui contient des données ou fournit des services accessibles aux
autres ordinateurs du réseau. Les types de serveur les plus courants sont les serveurs de
fichiers dans lesquels sont stockés des fichiers, les serveurs de noms qui stockent les noms
et adresses, les serveurs d’application qui stockent les programmes et applications et les
serveurs d’impression, qui planifient et dirigent les travaux d’impression vers leur
destination.
Un client est un ordinateur qui sollicite des services ou des données auprès d’un serveur.
Par exemple, un client peut demander un code de programme mis à jour ou une application
auprès d’un serveur de code. Pour obtenir un nom ou une adresse, le client contacte un
serveur de noms. Un client peut également interroger un serveur de fichiers pour retrouver
des fichiers et des données, et effectuer des opérations (saisie de données, recherches,
mise à jour d’articles).
Communications et réseaux : généralités
2-7
Communication avec d’autres systèmes d’exploitation
Un réseau peut relier divers types d’ordinateurs (modèles ou constructeurs hétérogènes).
Des programmes de communication sont alors utilisés pour pallier les disparités entre les
systèmes d’exploitation installés sur ces machines.
Parfois, ces programmes nécessitent l’installation préalable d’un autre programme sur le
réseau. Certains programmes peuvent nécessiter la présence sur le réseau d’un autre
programme ou de protocoles de connexion (tels que TCP/IP ou SNA).
Par exemple, avec AIX 4.3.2 et les versions supérieures, AIX Fast Connect permet aux
clients PC d’accéder aux fichiers du système d’exploitation et aux imprimantes à l’aide du
logiciel réseau client du PC natif. Les utilisateurs PC peuvent accéder directement aux
systèmes de fichiers distants à partir de leurs machines comme si ces fichiers étaient
sauvegardés en local. De plus, ils peuvent lancer des tâches d’impression sur des
imprimantes utilisant le système de spoulage, visualiser celles qui sont disponibles et
configurer une imprimante en réseau. Pour plus d’informations sur AIX Fast Connect,
reportez–vous au Guide AIX Fast Connect Version 3.1.
2-8
Guide de gestion du système – Communications et réseaux
Chapitre 3. Messagerie électronique
La messagerie fournit un outil d’échange du courrier électronique (e–mail) entre les
utilisateurs d’un même système ou de systèmes distincts connectés via un réseau.
Ce chapitre décrit le système de messagerie, l’interface utilisateur standard, et les
protocoles IMAP (Internet Message Access Protocol) et POP (Post Office Protocol).
La messagerie, outil de livraison de messages interréseau, comprend une interface
utilisateur, un programme de routage et un programme de livraison des messages
(aussi appelé programme facteur). L’acheminement des messages est assuré entre
deux utilisateurs d’un même système hôte ou de systèmes hôtes ou réseaux différents.
L’outil comporte également une fonction d’édition limitée pour présenter les en-têtes dans
un format reconnu par l’hôte récepteur.
Une interface utilisateur permet aux utilisateurs de créer, envoyer et recevoir des
messages. La messagerie propose deux interfaces : mail et mhmail. La commande mail
est l’interface utilisateur standard des systèmes UNIX. La commande mhmail est l’interface
utilisateur du gestionnaire de message (MH). Plus évoluée, cette dernière s’adresse aux
utilisateurs chevronnés.
Un programme de routage des messages sert à acheminer les messages jusqu’à
destination. Dans la messagerie présentée ici, il s’agit du programme sendmail. Ce
programme, intégré au système d’exploitation de base (BOS), est installé avec ce dernier.
Sendmail est un démon qui utilise les informations des fichiers /etc/mail/sendmail.cf et
/etc/mail/aliases pour effectuer le routage nécessaire.
Remarque : Dans les versions antérieures à AIX 5.1, les fichiers sendmail.cf et aliases
sont respectivement situés dans /etc/sendmail.cf et /etc/mail/aliases.
En fonction de la route, la commande sendmail fait appel à différents programmes facteur
pour livrer les messages.
Mail
3-1
Figure 2. Programmes facteur utilisés par la commande Sendmail Cette illustration
représente un type d’organigramme structuré du haut vers le bas avec la messagerie et MH
en haut. Il en part des branches correspondant à bellmail, BNU et SMTP. Sous le niveau
précédent se trouvent respectivement la boîte aux lettres locale, la liaison UUCP et la
liaison TCP/IP. Sous la liaison UUCP et sous la liaison TCP/IP se trouvent des boîtes aux
lettres distantes.
Mail
MH
sendmail
bellmail
BNU
SM TP
local
boîte aux lettres
UUCP
liaison
TCP/IP
liaison
distant
boîte aux lettres
distant
boîte aux lettres
Comme l’illustre la figure :
• Pour acheminer un courrier local, le programme sendmail achemine les messages au
programme bellmail. Le programme bellmail transmet le courrier au système local,
dans la boîte aux lettres système de l’utilisateur, située dans le répertoire
/var/spool/mail.
• Pour acheminer le courrier via une liaison réseau UUCP, le programme sendmail
achemine les messages à l’aide de BNU (Basic Network Utilities).
• Pour transmettre un courrier via TCP/IP, la commande sendmail établit une connexion
TCP/IP au système distant et utilise le protocole SMTP (Simple Mail Transfer Protocol)
pour effectuer le transfert.
3-2
System Management Guide: Communications and Networks
Gestion du courrier
L’administrateur du courrier est responsable de l’exécution des tâches suivantes :
1. Pour que sendmail soit exécuté à l’amorçage du système, configurez le fichier
/etc/rc.tcpip comme suit. Reportez–vous à Configuration du fichier /etc/rc.tcpip pour
lancer le démon sendmail, page 3-3.
2. Personnaliser le fichier de configuration /etc/mail/sendmail.cf. Le fichier par défaut
/etc/mail/sendmail.cf est configuré pour permettre la livraison du courrier local et du
courrier TCP/IP. Le fichier /etc/mail/sendmail.cf doit être personnalisé pour pouvoir
acheminer le courrier via une liaison BNU. Pour plus d’informations, reportez–vous au
Fichier sendmail.cf dans les Références fichiers AIX 5L Version 5.3.
3. Définir les alias de courrier aux niveaux système et domaine dans le fichier
/etc/mail/aliases. Pour plus d’informations, reportez–vous à Gestion des alias courrier,
page 3-4.
4. Gérer les files d’attente de messages. Pour plus d’informations, reportez–vous à Gestion
des fichiers et répertoires de file d’attente courrier, page 3-6.
5. Gérer le journal des messages. Pour plus d’informations, reportez–vous à Gestion de
journalisation, page 3-11.
Configuration du fichier /etc/rc.tcpip pour lancer le démon sendmail
Pour que sendmail soit exécuté à l’amorçage du système, configurez le fichier /etc/rc.tcpip
comme suit :
1. Modifiez le fichier /etc/rc.tcpip avec l’éditeur de votre choix.
2. Recherchez la ligne introduite par start /usr/lib/sendmail. Par défaut, cette ligne ne doit
pas être en commentaire, c’est-à-dire précédée du signe #. Si ce signe figure en début
de ligne, supprimez-le.
3. Sauvegardez le fichier.
Le démon sendmail sera exécuté à l’amorçage du système.
Mail
3-3
Gestion des alias
Les alias mettent en correspondance des noms et des listes d’adresses par le biais de
fichiers personnels, système ou domaine. Il existe trois types d’alias :
personnel
Défini par l’utilisateur dans son fichier $HOME/.mailrc.
système
local
Défini par l’administrateur du système de messagerie dans le fichier
/etc/mail/aliases. Les alias de ce type s’appliquent au courrier traité par le
programme sendmail sur le système local. Ils ont rarement besoin d’être
modifiés.
domaine
Par défaut, le programme sendmail lit /etc/alias pour convertir les alias.
Pour effacer les paramètres par défaut et utiliser NIS, modifiez ou créez la
commande /etc/netsvc.conf et ajoutez la ligne :
aliases=nis
Fichier /etc/mail/aliases
Le fichier /etc/mail/aliases se compose d’une série d’entrées au format suivant :
Alias:
Nom1 , Nom2 , ...
NomX
Alias étant une chaîne alphanumérique de votre choix (sans caractères spéciaux, tels
que @ et !). Les variables Nom1 à NomX représentent une liste de noms de destinataires.
Cette liste de noms peut s’étendre sur plusieurs lignes. Chaque ligne de suite doit
commencer par un espace ou une tabulation. Les lignes blanches ou précédées d’un dièse
(#) sont des commentaires.
Le fichier /etc/mail/aliases doit comporter les trois alias suivants :
MAILER-DAEMON
ID de l’utilisateur destinataire des messages adressés au démon du
programme facteur. Ce nom est attribué initialement à l’utilisateur
racine :
MAILER-DAEMON: root
postmaster
ID de l’utilisateur chargé de l’exploitation de la messagerie locale.
L’alias postmaster définit une adresse de boîte aux lettres unique
valable sur chaque système du réseau. Cette adresse permet
d’envoyer des requêtes à l’alias postmaster à partir de n’importe
quel système, sans connaître l’adresse exacte de l’utilisateur sur ce
système. Ce nom est attribué initialement à l’utilisateur racine :
postmaster: root
nobody
ID destinataire des messages adressés aux programmes tels que
news et msgs. Ce nom est attribué initialement à /dev/null :
nobody: /dev/null
Pour recevoir ces messages, déclarez l’alias comme utilisateur
valide.
A chaque modification du fichier, vous devez le recompiler dans un format de base de
données exploitable par la commande sendmail. Reportez–vous à Création d’une base de
données d’alias, page 3-5.
3-4
System Management Guide: Communications and Networks
Création d’alias de système local
Pour obtenir des instructions pas à pas sur la création d’un local system alias,
reportez–vous à Créer un alias local de messagerie, page 1-22.
Création d’une base de données d’alias
La commande sendmail n’utilise pas directement les définitions d’alias dans le fichier
/etc/mail/aliases du système local. Elle fait appel à une version de ce fichier générée par le
gestionnaire de base de données. Pour compiler la base de données d’alias, vous avez le
choix entre les méthodes suivantes :
• Lancez la commande /usr/sbin/sendmail assortie de l’indicateur -bi.
• Exécutez la commande newaliases. Cette commande provoque la lecture, par
sendmail, du fichier /etc/mail/aliases du système local et la création d’un nouveau
fichier contenant les informations de la base d’alias. Ce fichier est au format Berkeley,
plus efficace :
/etc/mail/aliases.db
(Les versions antérieures à AIX 5.1 créaient deux fichiers de bases de données,
/etc/aliases.dir et /etc/aliases.pag.)
• Lancez la commande sendmail assortie de l’indicateur Rebuild Aliases. Cette
commande reconstruit automatiquement la base de données d’alias lorsqu’elle est
périmée. Le reconstruction automatique peut être dangereuse sur des machines très
chargées, contenant de gros fichiers d’alias. Si la reconstruction dure plus longtemps que
le délai imparti (normalement, 5 minutes), il y a des chances que plusieurs processus la
lancent simultanément.
Remarques :
1. Sans ces fichiers, la commande sendmail ne peut pas traiter le courrier et génère un
message d’erreur.
2. Si plusieurs bases de données d’alias sont spécifiées, l’indicateur -bi reconstruit tous les
types qu’il peut interpréter (il peut, par exemple, reconstruire les bases de données
NDBM, et non les bases NIS).
Le fichier /etc/netsvc.conf contient l’ordonnancement des services système. Pour spécifier
l’ordonnancement des services des alias, ajoutez la ligne suivante :
aliases=service, service
service pouvant être files ou nis. Par exemple:
aliases=files, nis
Indique à la commande sendmail de tenter d’abord le fichier d’alias local puis, en cas
d’échec, d’essayer nis. Si nis est défini comme un service, il doit être actif.
Pour plus d’informations sur le fichier /etc/ netsvc.conf, reportez–vous à AIX 5L
Version 5.3 Files Reference.
Mail
3-5
Gestion des fichiers et répertoires de file d’attente courrier
La file d’attente courrier est un répertoire qui stocke des données et gère les files d’attente
de messages distribués par la commande sendmail. Son nom par défaut est
/var/spool/mqueue.
Les messages peuvent être mis en attente pour diverses raisons : si la commande
sendmail est configurée pour exécuter la file d’attente à intervalles réguliers et non
immédiatement, les messages y sont stockés temporairement. Par ailleurs, si un système
hôte distant ne répond pas à une demande de connexion courrier, la messagerie met les
messages en attente en vue d’une tentative ultérieure.
Impression de la file d’attente courrier
Pour imprimer le contenu de la file d’attente, lancez la commande mailq
(ou spécifiez l’indicateur -bp avec la commande sendmail).
Une liste des ID de file d’attente est générée, indiquant la taille de chaque
message, la date de son insertion dans la file et les noms d’expéditeur et de
destinataire.
Fichiers de file d’attente courrier
Chaque message en attente est associé à un certain nombre de fichiers, désignés par :
TypefID
ID est l’ID unique de file d’attente et Type, le type du fichier symbolisé par une lettre :
d
Fichier de données contenant le corps du texte du message sans l’en-tête.
q
Fichier de contrôle de file d’attente contenant les informations utiles au traitement
du travail.
t
Fichier temporaire correspondant à l’image du fichier q lors de sa reconstitution.
Très vite renommé q.
x
Fichier de transcription créé pour la durée d’une session, dans lequel sont
consignés tous les événements de la session.
Par exemple, soit le message portant l’ID de file d’attente AA00269, les fichiers suivants
sont générés et supprimés du répertoire de file d’attente courrier pendant que sendmail
tente de livrer ce message :
3-6
dfAA00269
Fichier de données
qfAA00269
Fichier de contrôle
tfAA00269
Fichier temporaire
xfAA00269
Fichier de transcription
System Management Guide: Communications and Networks
Fichier de contrôle q
Ce fichier contient une série de lignes commençant par les lettres suivantes :
B
Spécifie le body type. Le reste de la ligne est une chaîne de texte définissant le
body type. En l’absence de ce champ, le body type est de 7 bits par défaut et
aucun traitement particulier n’est entrepris. Valeurs possibles : 7BIT et 8BITMIME.
C
Contient l’adresse de contrôle. Pour les adresses de destinataires constituées
d’un fichier ou d’un programme, sendmail se comporte comme le propriétaire du
fichier ou du programme. L’utilisateur de contrôle devient propriétaire du fichier ou
du programme. Les adresses de destinataires sont lues à partir d’un fichier
.forward ou :include: comportant aussi un utilisateur de contrôle propriétaire du
fichier. sendmail délivre les messages à ces destinataires en tant qu’utilisateur de
contrôle, puis retourne à la racine.
F
Contient des bits d’indicateur. Les indicateurs sont une combinaison de w,
indiquant le message d’avertissement EF_WARNING, r, indiquant le message de
réponse EF_RESPONSE, 8, définissant l’indicateur EF_HAS8BIT et b,
définissant l’indicateur EF_DELETE_BCC. Les autres lettres sont ignorées.
H
Ligne(s) contenant la définition de l’en-tête. Le nombre de lignes est indifférent.
L’ordre d’apparition des lignes H détermine leur disposition dans le message final.
Elles utilisent la syntaxe de définition des en-têtes appliquée dans le fichier
/etc/mail/sendmail.cf. (Pour les versions antérieures à AIX 5.1, ce fichier est
/etc/sendmail.cf.)
I
Définit l’information sur le i–node et l’unité pour le fichier df. Utile pour recouvrer la
file d’attente courrier après un crash de disque.
K
Heure (en secondes) de la dernière tentative de distribution.
M
Lorsqu’un message est mis en file d’attente suite à une erreur lors d’une tentative
de livraison, le type d’erreur est stocké sur la ligne M.
N
Nombre total de tentatives de distribution.
O
Spécifie la valeur MTS originale de la transaction ESMTP. Utilisé exclusivement
pour les Notifications d’état de distribution.
P
Ligne précisant le niveau de priorité du message courant, lequel détermine l’ordre
d’exécution des messages en file d’attente. Plus le numéro est élevé, plus la
priorité est basse, autrement dit, la priorité croît à mesure que l’on descend dans
la liste des messages. Autrement dit, la priorité croît à mesure que l’on descend
dans la liste des messages. Le niveau de priorité initial est fonction de la classe et
de la taille du message.
Q
Destinataire initial tel que spécifié par le champ ORCPT= dans une transaction
ESMTP. Utilisé exclusivement pour les Notifications d’état de distribution. Il ne
s’applique qu’à la ligne ”R” figurant immédiatement après.
R
Lignes comportant chacune une adresse de destinataire.
S
Lignes comportant chacune une adresse d’expéditeur.
T
Ligne indiquant l’heure de création, qui sert à calculer le délai de rétention du
message en file d’attente.
V
Numéro de version du format de fichier de file d’attente utilisé pour que les
nouveaux fichiers binaires sendmail puissent lire les fichiers créés sous les
versions antérieures. Valeur par défaut : zero. Si présent, doit figurer sur la
première ligne du fichier.
Z
ID enveloppe initiale (issu de la transaction SMTP). Utilisé exclusivement pour les
Notifications d’état de distribution.
$
Contient une définition de macro. Les valeurs de certaines macros ($r et $s) sont
passées au cours de la phase d’exécution de la file.
Mail
3-7
Le fichier q associé au message adressé à amy@zeus se présenterait comme suit :
P217031
T566755281
MDeferred: Connection timed out during user open with zeus
Sgeo
Ramy@zeus
H?P?return-path: <geo>
Hreceived: by george (0.13 (NL support)/0.01)
id AA00269; Thu, 17 Dec 87 10:01:21 CST
H?D?date: Thu, 17 Dec 87 10:01:21 CST
H?F?From: geo
Hmessage-id: <8712171601.AA00269@george>
HTo: amy@zeus
Hsubject: test
où :
P217031
Priorité du message
T566755281
Temps de soumission en secondes
MDeferred: Connection timed out
during user open with zeus
Message d’état
Sgeo
ID de l’expéditeur
Ramy@zeus
ID du destinataire
HLines
Informations d’en-tête du message.
Spécification des délais au démon sendmail
Un format horaire spécial est prévu pour spécifier les délais associés au message et les
intervalles de traitement des files d’attente. Ce format est le suivant :
–qNombreUnité
Nombre est un entier et Unité est une des lettres symbolisant l’unité utilisée. Unité peut
avoir l’une des valeurs suivantes :
s
secondes
m
minutes
h
heures
d
jours
w
semaines
L’unité de temps par défaut est la minute (m). Voici trois exemples :
/usr/sbin/sendmail -q15d
Avec cette commande, sendmail traite la file d’attente tous les 15 jours.
/usr/sbin/sendmail -q15h
Avec cette commande, sendmail traite la file d’attente toutes les 15 heures.
/usr/sbin/sendmail -q15
Avec cette commande, sendmail traite la file d’attente toutes les 15 minutes.
3-8
System Management Guide: Communications and Networks
Exécution forcée de la file d’attente courrier
Si vous trouvez qu’une file d’attente commence à saturer, vous pouvez forcer son exécution
par le biais de l’indicateur –q (sans autre valeur). Vous pouvez également spécifier
l’indicateur –v (verbose) pour voir ce qui se passe :
/usr/sbin/sendmail -q-v
Vous pouvez également limiter les travaux à ceux dotés d’un identificateur de file,
d’un expéditeur ou d’un destinataire donné, via l’un des modificateurs de file d’attente.
Par exemple, -qRsally limite l’exécution de la file d’attente aux travaux dont l’adresse d’un
des destinataires contient la chaîne sally. De même, -qS chaîne limite l’exécution à
quelques expéditeurs et -qI chaîne, à quelques identificateurs de file d’attente.
Intervalle de traitement de la file d’attente
L’intervalle de traitement de la file d’attente courrier par le démon sendmail est déterminé
par l’indicateur -q, qui est pris en compte au lancement du démon.
Généralement, sendmail est lancé par le fichier /etc/rc.tcpip au démarrage du système.
Ce fichier contient la variable QPI (Queue Processing Interval), qui sert à attribuer une
valeur à l’indicateur -q à l’exécution du démon sendmail. Par défaut, la valeur de qpi est
30 minutes. Pour la modifier :
1. Modifiez le fichier /etc/rc.tcpip avec l’éditeur de votre choix.
2. Recherchez la ligne qui définit cette valeur, par exemple :
qpi=30m
3. Changez la valeur de qpi en fonction de vos besoins.
Ces modifications prendront effet au prochain lancement du système. Pour une prise en
compte immédiate, arrêtez puis relancez le démon sendmail en spécifiant la nouvelle
valeur pour l’indicateur –q. Pour plus d’informations, reportez-vous à ”Arrêt du démon
sendmail”, page3-10 et ”Lancement du démon sendmail”, page 3-10.
Transfert de file d’attente courrier
Si un système hôte est hors service pendant quelques temps, de nombreux messages
envoyés ou en transit sur ce système sont peut-être stockés dans votre file d’attente
courrier. Ce phénomène alourdit le traitement de la file d’attente au détriment des
performances de votre système. Dans ce cas, vous avez la possibilité de transférer
temporairement la file d’attente vers un autre emplacement et d’en créer une nouvelle. Vous
pourrez ainsi traiter l’ancienne file une fois le système hôte remis en service. Pour effectuer
ces opérations :
1. Arrêtez le démon sendmail en suivant les instructions dans Arrêt du démon sendmail,
page 3-10.
2. Déplacez la totalité du répertoire de file d’attente :
cd/var/spool
mv mqueue omqueue
3. Relancez le démon sendmail en suivant les instructions dans Lancement du démon
sendmail, page 3-10.
4. Pour traiter l’ancienne file d’attente, entrez :
/usr/sbin/sendmail -oQ/var/spool/omqueue -q.
L’indicateur –oQ désigne le répertoire temporaire de la file transférée, et l’indicateur –q
demande l’exécution de tous les travaux de la file. Pour obtenir un compte rendu du
déroulement des opérations, précisez -v.
Remarque :
Cette opération peut durer un certain temps.
Mail
3-9
5. Supprimez fichiers journaux et répertoire temporaire une fois la file d’attente vidée :
rm /var/spool/omqueue/*
rmdir /var/spool/omqueue
Lancement du démon sendmail
Pour lancer le démon sendmail, entrez :
startsrc –s sendmail –a ”–bd –q15”
/usr/lib/sendmail –bd –q15
Si sendmail est déjà activé à l’exécution de ces commandes, un message vous indique que
le démon ne peut être lancé plusieurs fois :
The sendmail subsystem is already active. Multiple instances are
not supported.
Sinon, un message vous confirme le lancement du démon.
Arrêt du démon sendmail
Pour arrêter le démon sendmail, exécutez la commande stopsrc -s sendmail. Sinon :
• Recherchez l’ID de processus de sendmail.
• Saisissez la commande kill sendmail_pid
(où sendmail_pid est l’ID de processus du processus sendmail).
3-10
System Management Guide: Communications and Networks
Gestion de la journalisation
La commande sendmail consigne dans un journal les activités de la messagerie en faisant
appel au démon syslogd. Le démon syslogd doit être configuré et exécuté pour permettre
la journalisation. Dans le fichier /etc/syslog.conf notamment, la ligne ci-après doit être
activée (et non mise en commentaire) :
mail.debug
/var/spool/mqueue/log
Si elle est désactivée, modifiez-la à l’aide de l’éditeur de votre choix, en prenant soin
d’indiquer le chemin d’accès correct. Si vous modifiez le fichier /etc/syslog.conf au cours
de l’exécution du démon syslogd, vous devez régénérer le démon comme suit :
refresh –s syslogd
Si le fichier /var/spool/mqueue/log n’existe pas, vous devez le créer via la commande :
touch /var/spool/mqueue/log
Les messages sont consignés dans le fichier journal au format suivant :
Chaque ligne d’un journal système comporte un horodateur, le nom de la machine qui l’a
généré (pour les journaux concernant plusieurs machines d’un réseau local), le mot
”sendmail:,” et un message. La plupart des messages sont constitués d’une série de
paires nom=valeur.
Deux lignes communes sont consignées lorsqu’un message est traité. La première indique
la réception d’un message : il y en a une par message. Certains champs peuvent être omis.
Les champs du message sont les suivants :
from
Adresse de l’expéditeur de l’enveloppe.
size
Taille du message (en octets).
class
Classe (priorité numérique) du message.
pri
Priorité initiale du message (pour le tri des files d’attente).
nrcpts
Nombre de destinataires de l’enveloppe pour ce message
(après définition d’alias et transmission).
proto
Protocole utilisé pour la réception du message
(par exemple, ESMTP ou UUCP).
relay
Machine d’où provient le message.
Une autre ligne est consignée à chaque tentative de livraison (il peut donc y en avoir
plusieurs par message - si le message est différé ou qu’il y a plusieurs destinataires).
Les champs du message sont les suivants :
to
Liste des destinataires, séparés par une virgule.
ctladdr
“Utilisateur contrôleur”, c’est-à-dire nom de l’utilisateur dont les références
sont utilisées pour la livraison.
delay
Délai total entre le moment où le message a été reçu et le moment
où il a été délivré.
xdelay
Durée nécessaire pour cette tentative de livraison.
mailer
Nom du programme facteur utilisé pour délivrer à ce destinataire.
relay
Nom de l’hôte qui a effectivement accepté (ou rejeté) ce destinataire.
stat
Etat de la livraison.
Mail
3-11
Les informations qui peuvent être consignées sont nombreuses. Le journal est structuré en
niveaux. Au niveau le plus bas, seules les situations très inhabituelles sont consignées.
Au niveau le plus élevé, même les événements insignifiants le sont. Par convention, les
niveaux inférieurs à 10 sont considérés utiles. Les niveaux supérieurs à 64 sont réservés à
la mise au point et les niveaux intermédiaires (11–64), dédiés aux informations détaillées.
Les types d’activité consignés par la commande sendmail dans le journal sont spécifiés
via l’option L dans le fichier /etc/mail/sendmail.cf. (Pour les versions antérieures à AIX 5.1,
ce fichier est /etc/sendmail.cf.)
Gestion du journal
Sans cesse alimenté par de nouvelles données, le journal peut prendre des proportions non
négligeables. Par ailleurs, il arrive que certains incidents génèrent des entrées inattendues
dans la file d’attente courrier. Pour limiter l’encombrement du journal et de la file d’attente,
exécutez le script shell /usr/lib/smdemon.cleanu. Ce script force la commande sendmail
à traiter la file d’attente et tient à jour quatre copies des fichiers journaux à des niveaux de
mise à jour croissants log.0, log.1, log.2 et log.3. A chaque exécution du script, le contenu
des fichiers est transféré comme suit :
• log.2 à log.3
• log.1 à log.2
• log.0 à log.1
• log à log.0.
Ces transferts permettent de reprendre la journalisation sur un nouveau fichier.
Exécutez le script manuellement ou à intervalle régulier à l’aide du démon cron.
Journalisation du trafic
De nombreuses versions de SMTP n’implémentent pas complètement le protocole.
Par exemple, certains SMTP basés sur PC ne savent pas interpréter les lignes de suite
dans les codes de réponse. Ceci peut être très difficile à déceler. Si vous suspectez un
problème de cet ordre, vous pouvez activer la journalisation du trafic via l’indicateur -X.
Par exemple :
/usr/sbin/sendmail-X /tmp/traffic -bd
Cette commande consigne l’intégralité du trafic dans le fichier /tmp/traffic.
Cette opération consigne une énorme quantité de données en très peu de temps et ne doit
jamais être effectuée dans le cadre de l’exploitation normale. Après avoir lancé un démon
de ce type, forcez l’implémentation errant à envoyer un message à votre hôte. Tout le trafic
entrant et sortant de sendmail, trafic SMTP entrant compris, sera consigné dans ce fichier.
Via sendmail, vous pouvez consigner un cliché des fichiers ouverts et du cache de
connexion en lui envoyant un signal SIGUSR1. Les résultats sont consignés avec la priorité
LOG_DEBUG.
3-12
System Management Guide: Communications and Networks
Journalisation des données statistiques
La commande sendmail assure le suivi du volume de courrier traité par chaque programme
facteur qui communique avec la commande. Ces programmes sont définis dans le fichier
/etc/sendmail.cf. (Pour les versions antérieures à AIX 5.1, ce fichier est /etc/sendmail.cf.)
Figure 3. Programmes facteur utilisés par la commande Sendmail Cette illustration
représente un type d’organigramme structuré du haut vers le bas avec la messagerie et MH
en haut. Il en part des branches correspondant à bellmail, BNU et SMTP. Sous le niveau
précédent se trouvent respectivement la boîte aux lettres locale, la liaison UUCP et la
liaison TCP/IP. Sous la liaison UUCP et sous la liaison TCP/IP se trouvent des boîtes aux
lettres distantes.
Mail
MH
sendmail
bellmail
BNU
SMTP
local
boîte aux lettres
UUCP
liaison
TCP/IP
liaison
distant
boîte aux lettres
distant
boîte aux lettres
Pour lancer la collecte des données statistiques, créez le fichier /var/tmp/sendmail.st
comme suit :
touch /var/tmp/sendmail.st
Si la commande sendmail rencontre des erreurs pendant l’enregistrement des données
statistiques, elle inscrit un message via la sous-routine syslog. Ces erreurs n’entravent
pas les autres opérations de sendmail.
La commande sendmail met les informations à jour chaque fois qu’un courrier est traité.
La taille du fichier reste égale, mais les nombres dans le fichier augmentent.
Ils représentent le volume de courrier depuis que vous avez créé ou réinitialisé le fichier
/etc/mail/statistics.
Remarque : Dans les versions antérieures à AIX 5.1, les statistiques étaient conservées
dans le fichier /var/tmp/sendmail.st.
Mail
3-13
Affichage des informations des programmes facteurs
Les données statistiques conservées dans le fichier /etc/mail/statistics sont sauvegardées
sous un format de base de données, et ne peuvent donc être consultées comme un fichier
texte. Pour les afficher, tapez ceci à une invite de commande :
/usr/sbin/mailstats
Cette commande lit les données du fichier /etc/mail/statistics, et les formate avant de les
envoyer vers la sortie standard. Pour obtenir de plus amples informations sur la sortie de la
commande /usr/sbin/mailstats, lisez sa description dans la AIX Version 5.3 Commands
Reference.
3-14
System Management Guide: Communications and Networks
Mise au point de sendmail
Il existe de nombreux indicateurs de mise au point, intégrés à la commande sendmail.
A chaque indicateur sont associés un numéro et un niveau, les niveaux supérieurs indiquant
un accroissement des informations. Par convention, les niveaux supérieurs à 9 fournissent
tellement d’informations que vous ne souhaiterez pas les consulter - sauf pour mettre au
point un module particulier de code source. Les indicateurs de mise au point sont définis via
l’indicateur –d, comme illustré dans l’exemple ci-dessous :
debug–flag:
debug–list:
debug–flag:
debug–range:
debug–level:
–d debug–list
debug–flag[.debug–flag]*
debug–range[.debug–level]
integer|integer–integer
integer
–d12
–d12.3
–d3–17
–d3–17.4
Set
Set
Set
Set
flag 12
flag 12
flags 3
flags 3
to level 1
to level 3
through 17 to level 1
through 17 to level 4
Les indicateurs de mise au point disponibles sont les suivants :
–d0
Mise au point générale.
–d1
Affiche les informations d’envoi.
–d2
Prend fin avec fini ( ).
–d3
Indique la charge moyenne.
–d4
Espace disque suffisant.
–d5
Affiche les événements.
–d6
Affiche le courrier non parvenu.
–d7
Nom du fichier de file d’attente.
–d8
Résolution de noms DNS.
–d9
Effectue un suivi des requêtes RFC1413.
–d9.1
Met le nom d’hôte sous forme canonique.
–d10
Affiche le courrier reçu par le destinataire.
–d11
Effectue un suivi des livraisons.
–d12
Affiche le mappage de l’hôte relatif.
–d13
Affiche les livraisons.
–d14
Affiche les virgules du champ d’en-tête.
–d15
Affiche l’activité des requêtes d’obtention (get) du réseau.
–d16
Connexions sortantes.
–d17
Affiche la liste des hôtes MX.
Remarque : Il existe désormais près de 200 indicateurs de mise au point définis
dans le programme sendmail.
Mail
3-15
Protocoles IMAP (Internet Message Access Protocol)
et POP (Post Office Protocol)
Pour l’accès à distance à la messagerie, il existe deux serveurs de protocole de messagerie
électronique basés sur Internet :
• POP (Post Office Protocol),
• IMAP (Internet Message Access Protocol).
Ces deux types de serveur stockent le courrier électronique et y donnent accès. Grâce à
ces protocoles, l’ordinateur n’a plus besoin d’être allumé pour la réception du courrier.
Le serveur POP fournissant un système de courrier électronique hors ligne, par le biais du
logiciel client POP, le client a accès à distance au serveur de messagerie pour réceptionner
son courrier. Il peut télécharger son courrier et, ensuite, soit le supprimer immédiatement du
serveur, soit le conserver sur le serveur POP. Le courrier, une fois chargé sur la machine
cliente, est traité localement sur cette machine. Le serveur POP autorise l’accès à une boîte
aux lettres utilisateur à un seul client à la fois.
Le serveur IMAP propose un ”super-ensemble” de fonctions POP, mais avec une autre
interface. Le serveur IMAP fournit un service hors ligne, un service en ligne et un service
déconnecté. Le protocole IMAP permet de manipuler des boîtes aux lettres à distance
comme si elles étaient locales. Par exemple, les clients peuvent faire des recherches dans
les messages et y insérer des indicateurs d’état tels que ”deleted” ou ”answered”
(”supprimé” ou ”répondu”). En outre, les messages peuvent être conservés dans la base de
données du serveur tant qu’ils ne sont pas supprimés explicitement. Le serveur IMAP
permet à plusieurs clients d’accéder de façon interactive et simultanée aux boîtes aux
lettres utilisateur.
Les serveurs IMAP et POP sont exclusivement des serveurs d’accès au courrier. Pour
l’envoi du courrier, ils utilisent le protocole SMTP (Simple Mail Transfer Protocol).
IMAP et POP sont tous deux des protocoles ouverts, qui reposent sur les normes décrites
dans les RFC (Request for Comments). Le serveur IMAP repose sur le RFC 1730 et le
serveur POP sur le RFC 1725. Les deux serveurs sont “ orientés connexion ” et utilisent des
sockets TCP. L’écoute IMAP et POP a respectivement lieu sur les ports identifiés 143
et 110. En outre, le démon inetd gère les deux serveurs.
Configuration des serveurs IMAP et POP
Prérequis
Vous devez être utilisateur racine (root).
Procédure
1. Désactivez le commentaire des entrées imapd et pop3d dans le fichier /etc/inetd.conf.
2. Rafraîchissez le démon inetd avec la commande :
refresh –s inetd
3-16
System Management Guide: Communications and Networks
Tests de configuration
Vous pouvez lancer quelques tests pour vous assurer que les serveurs imapd et pop3d sont
opérationnels.
Tout d’abord, vérifiez que leur écoute a lieu sur les ports identifiés : Pour cela, procédez
comme suit :
netstat –a | grep imap
netstat –a | grep pop
En principe, le résultat de la commande netstat donne :
tcp
tcp
0
0
0
0
*.imap2
*.pop3
*.*
*.*
LISTEN
LISTEN
Si vous n’obtenez pas ce résultat, vérifiez à nouveau les entrées dans le fichier
/etc/inetd.conf, puis relancez la commande refresh –s inetd.
Testez la configuration du serveur imapd, via telnet, au niveau du imap2, port 143. En vous
connectant via telnet, vous obtenez l’invite imapd. Vous pouvez entrer les commandes
IMAP version 4 définies dans la RFC 1730. Pour ce faire, tapez un point (.) puis un espace
suivi du nom de la commande de jeton, ainsi que tous les paramètres. Le jeton est
utilisé pour ordonner le nom de la commande. Par exemple :
.
Paramètres du nom de la commande de jeton
Notez l’écho des mots de passe quand telnet est utilisé vers le serveur imapd.
Dans l’exemple telnet suivant, vous devez indiquer votre propre mot de passe à la place
de id_password dans la commande login.
telnet e–xbelize 143
Trying...
Connected to e–xbelize.austin.ibm.com.
Escape character is ’^]’.
* OK e–xbelize.austin.ibm.com IMAP4 server ready
. 1 login id id_password
. OK
. 2 examine /usr/spool/mail/root
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 823888143]
. OK [READ–ONLY] Examine completed
. 3 logout
* BYE Server terminating connection
. OK Logout completed
Connection closed.
Testez la configuration du serveur pop3d, via telnet, au niveau du port pop3, 110.
Vous obtenez l’invite pop3d. Vous pouvez entrer les commandes POP définies dans la
RFC 1725. Pour ce faire, tapez un point (.) puis un espace suivi du nom de la commande.
Par exemple :
.
CommandName
Notez l’écho des mots de passe quand telnet est utilisé vers le serveur pop3d.
Mail
3-17
Dans l’exemple telnet suivant, vous devez indiquer votre propre mot de passe à la place
de id_password dans la commande pass.
telnet e–xbelize 110
Trying...
Connected to e–xbelize.austin.ibm.com.
Escape character is ’^]’.
+OK e–xbelize.austin.ibm.com POP3 server ready
user id
+OK Name is a valid mailbox
pass id_password
+OK Maildrop locked and ready
list
+OK scan listing follows
.
stat
+OK 0 0
quit
+OK
Connection closed.
syslog
Le logiciel serveur IMAP et POP adresse des journaux à l’outil syslog.
Pour configurer la journalisation IMAP et POP sur votre système par le biais de syslog,
vous devez être un utilisateur racine. Editez le fichier de configuration /etc/syslog.conf
pour y ajouter une entrée pour *.debug comme suit :
*.debug /usr/adm/imapd.log
Le fichier usr/adm/imapd.log doit être existant avant la relecture par le démon syslogd
du fichier /etc/syslog.conf. Pour créer usr/adm/imapd.log, utilisez la commande :
touch /usr/adm/imapd.log
Ensuite, rafraîchissez syslogd avec la commande suivante pour la relecture de son fichier
de configuration :
refresh –s syslogd
3-18
System Management Guide: Communications and Networks
Informations de référence du courrier
Cette section fournit un bref récapitulatif des commandes, fichiers et répertoires intervenant
dans la messagerie.
Liste des commandes
Cette liste répertorie les commandes d’exploitation et de gestion de la messagerie.
bugfiler
Enregistre les comptes rendus d’anomalies dans des
répertoires courrier spécifiques.
comsat
Avertit les utilisateurs de l’arrivée d’un courrier (démon).
mailq
Imprime le contenu de la file d’attente courrier.
mailstats
Affiche les statistiques relatives au trafic du courrier.
newaliases
Crée une copie de la base de données d’alias à partir
du fichier /etc/aliases.
rmail
Gère le courrier distant reçu via la commande uucp de
BNU.
sendbug
Envoie un compte rendu d’anomalies à une adresse
spécifique.
sendmail
Délivre le courrier en local ou sur le réseau.
smdemon.cleanu
Epure la file d’attente sendmail pour les tâches de
routine.
Liste des fichiers et répertoires courrier
Les fichiers et répertoires sont présentés par fonction.
Remarque : Dans les versions antérieures à AIX 5.1, les fichiers sendmail.cf et aliases
sont respectivement situés dans /etc/sendmail.cf et /etc/aliases.
Messagerie
/usr/share/lib/Mail.rc
Définit les valeurs par défaut du système local pour tous
les utilisateurs de la messagerie. Fichier de texte
modifiable pour définir les caractéristiques par défaut de
la commande mail.
$HOME/.mailrc
Permet de modifier les valeurs par défaut du système
local pour la messagerie.
$HOME/mbox
Stocke le courrier traité d’un utilisateur.
/usr/bin/Mail, /usr/bin/mail,
ou /usr/bin/mailx
Indique trois noms associés au même programme.
La messagerie est l’une des interfaces entre l’utilisateur
et le système de messagerie.
/var/spool/mail
Indique le répertoire par défaut de dépôt du courrier.
Le courrier est stocké par défaut dans le fichier
/var/spool/mail/nom-utilisateur.
/usr/bin/bellmail
Prend en charge la livraison du courrier local.
/usr/bin/rmail
Assure l’interface courrier distant pour BNU.
/var/spool/mqueue
Contient le fichier journal et les fichiers temporaires
associés aux messages de la file d’attente courrier.
Mail
3-19
Commande sendmail
/usr/sbin/sendmail
Commande sendmail.
/usr/ucb/mailq
Pointe sur le fichier /usr/sbin/sendmail.
Equivaut à /usr/sbin/sendmail –bp.
/usr/ucb/newaliases
Pointe sur le fichier /usr/sbin/sendmail.
Equivaut à /usr/sbin/sendmail –bi.
/etc/netsvc.conf
Spécifie l’ordre de certains services de résolution
de noms.
/usr/sbin/mailstats
Formate et affiche les données statistiques sendmail
recueillies dans le fichier par défaut /etc/sendmail.st,
s’il existe. Vous pouvez spécifier un autre fichier.
/etc/aliases
Décrit une version texte du fichier d’alias pour la
commande sendmail. Vous pouvez éditer ce fichier pour
créer, modifier ou supprimer des alias de votre système.
/etc/aliasesDB
Décrit un répertoire contenant les fichiers de base de
données d’alias, DB.dir et DB.pag, créés à partir du
fichier /etc/aliases à l’exécution de la commande
sendmail –bi.
/etc/sendmail.cf
Contient les informations de configuration de sendmail
dans un format texte. Editez ce fichier pour modifier les
informations.
/usr/lib/smdemon.cleanu
Spécifie un fichier shell qui exécute la file d’attente
courrier et tient à jour des fichiers journaux sendmail
dans le répertoire /var/spool/mqueue.
/var/tmp/sendmail.st
Rassemble les statistiques relatives au trafic du courrier.
Ce fichier a une taille fixe. Utilisez la commande
/usr/sbin/mailstats pour afficher son contenu.
Supprimez-le si vous ne voulez pas recueillir ce type
d’informations.
/var/spool/mqueue
Désigne le répertoire contenant les fichiers temporaires
associés à chaque message en file d’attente. Ce
répertoire peut contenir le fichier journal.
/var/spool/cron/crontabs
Désigne le répertoire contenant les fichiers lus par le
démon cron pour déterminer le travail à exécuter. Le
fichier root comporte une ligne d’exécution du script shell
smdemon.cleanu.
Liste des commandes IMAP et POP
3-20
/usr/sbin/imapd
Process serveur IMAP
(Internet Message Access Protocol).
/usr/sbin/pop3d
Process serveur POP3
(Post Office Protocol version 3.
System Management Guide: Communications and Networks
Chapitre 4. Protocole TCP/IP
Ce chapitre décrit la suite de logiciels réseau TCP/IP (Transmission Control
Protocol/Internet Protocol). TCP/IP est un protocole normalisé souple et puissant,
permettant de connecter plusieurs ordinateurs à d’autres machines.
Ce chapitre traite des points suivants :
• Préparation du réseau TCP/IP, page 4-2
• Installation et configuration de TCP/IP, page 4-3
• Protocoles TCP/IP, page 4-6
• Cartes réseau LAN TCP/IP, page 4-38
• Interfaces réseau TCP/IP, page 4-52
• Adressage TCP/IP, page 4-60
• Résolution de noms sous TCP/IP, page 4-66
• Affectation des adresses et paramètres TCP/IP – Protocole DHCP, page 4-96
• Démon DHCP avec structure PXED (Preboot Execution Environment Proxy), page 4-169
• Démon BINLD (Boot Image Negotiation Layer Daemon), page 4-186
• Démons TCP/IP, page 4-201
• Routage TCP/IP, page 4-208
• Mobile IPv6, page 4-220
• Adresse IP virtuelle (VIPA), page 4-224
• Agrégation de liaison EtherChannel et IEEE 802.3ad, page 4-227
• Protocole Internet (IP) via Fibre Channel, page 4-248
• Initiateur logiciel iSCSI, page 4-250
• Protocole de transmission du contrôle de flot, page 4–247
• Détection de la MTU d’accès, page 4-258
• Qualité de Service (QoS) TCP/IP, page 4-260
• Détermination des incidents TCP/IP, page 4-274
• Référence TCP/IP, page 4-285
Remarque :
La plupart des tâches abordées dans ce chapitre nécessitent les droits
d’utilisateur racine.
Protocole TCP/IP
4-1
Préparation du réseau TCP/IP
TCP/IP étant un protocole réseau très souple, vous pouvez le personnaliser et l’adapter aux
besoins spécifiques de votre organisation. Les principaux points à prendre en compte pour
préparer votre réseau sont les suivants. Chaque point fait l’objet d’un étude détaillée dans la
suite de ce manuel. Cette liste vous permettra simplement d’évaluer la portée des actions
possibles.
1. Choisissez le type de matériel réseau que vous souhaitez utiliser : anneau à jeton
(token–ring), Ethernet Version 2, IEEE 802.3, interface FDDI (Fiber Distributed Data
Interface), canal optique série (Serial Optical Channel, SOC) ou protocole SLIP
(Serial Line Interface Protocol).
2. Tracez l’implantation physique du réseau.
Réfléchissez aux fonctions que devra assurer chaque machine hôte. Par exemple,
vous devez choisir à ce stade les machines qui serviront de passerelles avant de passer
au câblage du réseau.
3. Optez selon vos besoins pour un réseau plat ou une structure de réseau hiérarchisée.
Si votre réseau est de petite taille, concentré sur un seul site, et ne comprend qu’un
réseau physique, un réseau plat peut parfaitement convenir. Si votre réseau est très
étendu, complexe, avec de nombreux sites ou plusieurs réseaux physiques, il sera
peut–être plus pratique d’opter pour un réseau hiérarchisé.
4. Si votre réseau doit être raccordé à d’autres réseaux, vous devez réfléchir à l’installation
et à la configuration des passerelles qui seront nécessaires. Les éléments à prendre en
compte sont :
a. choisir les machines qui serviront de passerelles ;
b. décider si vous utiliserez le routage statique ou le routage dynamique, à moins que
vous ne choisissiez une combinaison des deux. Si vous optez pour le routage
dynamique, choisissez les démons de routage que devra utiliser chaque passerelle,
en tenant compte des différents types de protocoles de communication à prendre en
charge.
5. préparez un schéma d’adressage.
Si votre réseau n’est pas destiné à faire partie d’un interréseau plus étendu, choisissez
le schéma d’adressage convenant le mieux à vos besoins. Si vous souhaitez intégrer
votre réseau au sein d’un interréseau plus étendu tel qu’Internet, vous devrez vous
procurer un jeu officiel d’adresses auprès de votre fournisseur d’accès à Internet (FAI).
6. Voyez s’il convient d’envisager la division de votre système en plusieurs sous–réseaux.
Si oui, décidez du mode d’attribution des masques de sous–réseau.
7. Choisissez des conventions de noms. Chaque machine du réseau doit posséder un nom
d’hôte unique.
8. Décidez si votre réseau requiert un serveur de noms pour la résolution des noms ou si le
recours au fichier /etc/hosts est suffisant.
Si vous décidez d’utiliser des serveurs de noms, choisissez le type de serveur
nécessaire et combien de serveurs de noms vous devez prévoir pour être efficace.
9. Décidez des types de services que le réseau doit, selon vous, proposer aux utilisateurs
distants : services de messagerie, d’impression, partage de fichiers, connexion à
distance, exécution de commandes à distance, etc.
4-2
Guide de gestion du système – Communications et réseaux
Installation et configuration pour TCP/IP
Pour plus d’informations sur l’installation de TCP/IP, reportez–vous au manuel AIX 5L
Version 5.3 Installation Guide and Reference.
Configuration de TCP/IP
Une fois TCP/IP installé, la configuration du système peut être effectuée.
Pour configurer TCP/IP, vous pouvez :
• utiliser l’application Web–based System Manager Network (raccourci wsm network),
• utiliser SMIT (System Management Interface System),
• éditer un format de fichier,
• lancer une commande à partir de l’invite du shell.
Par exemple, le script shell rc.net effectue la configuration minimale du système hôte pour
TCP/IP au démarrage du système (ce script est lancé à la seconde phase de l’amorçage
par le gestionnaire de configuration). Si vous utilisez SMIT ou Web–based System Manager
pour configurer le système hôte, le fichier rc.net est automatiquement configuré.
Vous pouvez également configurer le fichier /etc/rc.bsdnet à l’aide d’un éditeur de texte
standard. Cette méthode vous permet de spécifier les commandes de configuration
traditionnelles UNIX TCP/IP comme ifconfig, nom hôte et route. Pour plus d’informations,
reportez–vous à laListe des commandes TCP/IP, page 4-285. Si vous utilisez la méthode
d’édition de fichiers, entrez le raccourci smit configtcp puis sélectionnez une
configuration rc de type BSD.
Certaines tâches, telles que la configuration d’un serveur de noms, ne peuvent être
accomplies via SMIT ou via Web–based System Manager.
Configuration des systèmes hôte
Chaque système hôte du réseau doit être adapté aux besoins des utilisateurs et aux
contraintes du réseau. Pour chaque hôte, vous devez configurer l’interface de réseau,
définir l’adresse Internet, le nom d’hôte et les routes statiques vers les passerelles ou les
autres systèmes hôte. Il faut également spécifier les démons à lancer par défaut et
configurer le fichier /etc/hosts pour la résolution des noms (ou configurer l’hôte de telle
sorte qu’il utilise le serveur de noms).
Configuration des hôtes en tant que serveurs
Si la machine hôte joue un rôle spécifique (passerelle, serveur de fichiers ou serveur
de noms), la configuration de base doit être complétée.
Par exemple, si le réseau est organisé hiérarchiquement et que vous utilisez le protocole
DOMAIN pour la résolution des noms dans les adresses Internet, vous devez configurer
au moins un serveur de noms.
N’oubliez pas qu’un hôte serveur n’a pas besoin d’être une machine dédiée : elle peut
également servir à d’autres fonctions. Par exemple, si la fonction de serveur de noms est
relativement limitée, la machine peut également être utilisée comme station de travail ou
serveur de fichiers sur le réseau.
Remarque :
Si NIS ou NIS+ est installé sur votre système, ces services peuvent
également vous aider à la résolution des noms. Pour plus d’informations,
reportez–vous au AIX 5L Version 5.3 Network Information Services
(NIS and NIS+) Guide.
Protocole TCP/IP
4-3
Configuration des passerelles
Si vous envisagez de connecter votre réseau à d’autres réseaux, il vous faut configurer au
moins une machine hôte passerelle. Pour cela, vous devez déterminer les protocoles de
communication nécessaires et les démons de routage (routed ou gated) correspondants.
Commandes de gestion système TCP/IP
Voici la liste des commandes utiles pour configurer et gérer le réseau TCP/IP :
arp
Affichage/modification des tables de traduction d’adresse Internet en
adresse matérielle, utilisées par ARP (Address Resolution Protocol).
finger
Retour d’informations concernant les utilisateurs sur un hôte
spécifique.
host
Affichage de l’adresse Internet d’un hôte spécifique ou d’un nom
d’hôte figurant dans une adresse Internet spécifique.
hostname
Affichage ou définition du nom et de l’adresse Internet d’un système
hôte local.
ifconfig
Configuration des interfaces de réseau.
netstat
Affichage des adresses locales et distantes, des tables de routage,
des données statistiques sur le matériel et du compte rendu des
paquets transférés.
no
Affichage ou définition des options courantes du noyau de réseau.
ping
Détermination de l’accessibilité d’un système hôte.
route
Manipulation des tables de routage.
ruptime
Affichage des informations d’état sur les hôtes connectés aux
réseaux physiques locaux et exécutant le serveur rwhod.
rwho
Affichage des informations d’état sur les utilisateurs des hôtes
connectés aux réseaux physiques locaux et exécutant le
serveur rwhod.
setclock
Calage de l’heure et de la date de l’hôte local sur celles du service
horaire du réseau.
timedc
Informations sur le démon timed.
trpt
Compte rendu de suivi du protocole sur les prises TCP.
whois
Service du répertoire de noms Internet.
Configuration d’une liste de contrôle du réseau TCP/IP
Utilisez la procédure suivante comme guide de configuration de votre réseau.
Prenez le temps nécessaire pour rassembler les informations et comprendre les
instructions.
Une fois le réseau installé et opérationnel, cette liste de contrôle vous servira à résoudre
des incidents.
Prérequis
1. Les matériels réseau sont installés et câblés. Reportez–vous à la documentation Cartes
réseau LAN TCP/IP, page 4-38.
2. Le logiciel TCP/IP est installé. Reportez–vous à Guide d’installation et référence AIX 5L
Version 5.3.
4-4
Guide de gestion du système – Communications et réseaux
Procédure
1. Consultez “Protocoles TCP/IP”, page 4-6, pour la structure de base de TCP/IP.
Vous devez comprendre :
– la structure en couches de TCP/IP
(différents protocoles résidant sur différentes couches),
– le mécanisme de flux des données à travers les couches.
2. Effectuez la configuration minimale de chaque machine hôte du réseau : ajout d’une
interface réseau, affectation d’une adresse IP, attribution d’un nom d’hôte à chaque
machine hôte et définition d’une route par défaut d’accès au réseau. Consultez tout
d’abord les sections “Interfaces de réseau TCP/IP”, page 4-52, “Adressage TCP/IP”,
page 4-60 et “Définition des noms d’hôte”, page 4-68.
3. Adressage TCP/IP page 4-60, et Choix des noms pour les hôtes de votre réseau
page 4-68.
Remarque : Chaque machine du réseau doit subir cette configuration minimale, qu’il
s’agisse d’un hôte utilisateur, d’un serveur de fichiers, d’une passerelle ou d’un serveur
de noms.
4. Configurez et lancez le démon inetd sur chaque machine hôte du réseau. Consultez la
section “Démons TCP/IP”, page 4-201, et procédez comme indiqué à “Configuration du
démon inetd”, page 4-204.
5. Configurez chaque machine hôte pour effectuer la résolution des noms en local ou
utiliser le serveur de noms. Si vous installez un système hiérarchique de type DOMAIN,
vous devez configurer au moins une machine hôte en tant que serveur de noms.
Reportez-vous à “Résolution de noms sous TCP/IP”, page 4-66.
6. Si votre réseau doit être connecté à d’autres réseaux distants, configurez au moins une
machine hôte comme passerelle. Pour l’acheminement interréseau, la passerelle peut
utiliser des routes statiques ou un démon de routage. Reportez-vous à
“Routage TCP/IP”, page 4-208.
7. Déterminez pour chaque machine hôte du réseau, les services accessibles. Par défaut,
ils le sont tous. Pour changer cette configuration, procédez comme indiqué à “Services
réseau client”, page 4-205.
8. Désignez, parmi les machines hôtes, celles qui joueront le rôle de serveurs et définissez
leurs services respectifs. Pour lancer les démons de serveur de votre choix,
reportez-vous à ”Services réseau serveur”, page 4-206.
9. Configurez les serveurs d’impression à distance nécessaires. Pour en savoir plus,
reportez-vous aux généralités sur les imprimantes dans AIX 5L Version 5.3 Guide to
Printers and Printing.
10.Si vous le souhaitez, configurez une machine à utiliser comme serveur horaire maître
pour le réseau. Pour en savoir plus, reportez-vous au démon timed dans le manuel AIX
5L Version 5.3 Commands Reference.
Protocole TCP/IP
4-5
Protocoles TCP/IP
Cette section traite des points suivants :
• IP (Internet Protocol) Version 6 : Généralités, page 4-9
• Suivi de paquet, page 4-17
• En-têtes de paquets au niveau interface de réseau, page 4-18
• Protocoles Internet de niveau réseau, page 4-22
• Protocoles Internet de niveau transport, page 4-27
• Protocoles Internet de niveau application, page 4-31
• Nombres réservés, page 4-37
Les protocoles sont des ensembles de règles de formats de message et de procédures qui
permettent aux machines et aux applications d’échanger des informations. Ces règles
doivent être observées par chaque machine impliquée dans la communication pour que le
message puisse être interprété par le système destinataire.
La suite de protocoles TCP/IP (voir figure) peut être représentée en couches (ou niveaux).
Figure 4. Suite de protocoles TCP/IP Cette illustration représente les couches du
protocole TCP/IP. Ce sont, à partir du haut : couche d’application, couche de transport,
couche réseau, couche d’interface réseau et matériel.
COUCHE
Application
Transport
PROTOCOLE
APPLICATION
UDP
TCP
Réseau
PROTOCOLE INTERNET
Interface de réseau
INTERFACE DE RESEAU
Matériel
RESEAU PHYSIQUE
TCP/IP définit précisément l’acheminement de l’information de l’émetteur au destinataire.
Les messages ou trains de données sont envoyés par les programmes d’application à l’un
des deux protocoles Internet de niveau transport : UDP (User Datagram Protocol) ou TCP
(Transmission Control Protocol). A la réception des données, ces protocoles les divisent
en paquets, y ajoutent une adresse de destination et les transmettent à la couche de
protocole suivante, la couche Réseau Internet.
La couche Réseau Internet encapsule le paquet dans un datagramme IP (Internet
Protocol), insère les données d’en-tête et de fin, décide de la destination du datagramme
(directement à destination ou via une passerelle) et transmet le datagramme à la couche
Interface réseau.
La couche Interface réseau réceptionne les datagrammes IP et les transmet sous forme
de trames à travers un réseau spécifique, tel que Ethernet ou anneau à jeton (voir figure).
4-6
Guide de gestion du système – Communications et réseaux
Figure 5. Mouvement des informations de l’application émettrice vers l’hôte
récepteur Cette illustration représente le flux d’informations descendant dans les couches
de protocole TCP/IP de l’émetteur vers l’hôte.
COUCHE APPLICATION
Données
Message ou flot (stream)
COUCHE TRANSPORT
En-tête TCP
Données
Paquet du protocole
de transport
COUCHE RESEAU
En-tête IP
En-tête TCP
Données
Paquet de la couche réseau
COUCHE INTERFACE DE L’APPLICATION
En-tête Ethernet
En-tête IP
En-tête TCP
Données
Trame Ethernet
RESEAU PHYSIQUE
Les trames reçues par une machine hôte sont réexpédiées à travers les couches de
protocoles dans le sens inverse. Chaque couche supprime l’information d’en-tête
correspondante jusqu’à ce que les données atteignent de nouveau la couche Application
(reportez–vous à la figure).
Protocole TCP/IP
4-7
Figure 6. Mouvement des informations de l’hôte vers l’application Cette illustration
représente le flux d’informations remontant les couches de protocole TCP/IP de l’hôte vers
l’émetteur.
COUCHE APPLICATION
Données
Message ou flot (stream)
COUCHE TRANSPORT
En-tête TCP
Données
Paquet du protocole
de transport
COUCHE RESEAU
En-tête IP
En-tête TCP
Données
Paquet de la couche réseau
COUCHE INTERFACE DE L’APPLICATION
En-tête Ethernet
En-tête IP
En-tête TCP
Données
Trame Ethernet
RESEAU PHYSIQUE
Les machines hôtes envoient et reçoivent des informations simultanément. En ce sens,
la figure Transmission et réception des données hôtes représente avec plus d’exactitude
le mode de communication de l’hôte.
Les hôtes d’un réseau envoient et reçoivent les informations simultanément. La Figure 7
page 4-9 représente avec davantage de précision un hôte en cours de communication.
4-8
Guide de gestion du système – Communications et réseaux
Figure 7. Transmissions et réceptions des données hôte Cette illustration représente
les flux de données dans les deux sens dans les couches TCP/IP.
COUCHE APPLICATION
Données
Message ou flot (stream)
COUCHE TRANSPORT
En-tête TCP
Données
Paquet du protocole de
transport
COUCHE RESEAU
En-tête IP
En-tête TCP
Données
Paquet de la couche réseau
COUCHE INTERFACE DE L’APPLICATION
En-tête Ethernet
En-tête IP
En-tête TCP
Données
Trame Ethernet
RESEAU PHYSIQUE
Remarque : Les en–têtes sont ajoutés et supprimés dans chaque couche de protocole
au fur et à mesure que les données sont transmises et reçues par l’hôte.
IP version 6 - Généralités
IP (Internet Protocol) version 6 (IPv6 ou IP ng) est la prochaine génération IP, conçue
comme une évolution d’IP version 4 (IPv4). Si IPv4 a permis le développement d’un Internet
global, il n’est cependant pas capable de progresser davantage à cause de deux facteurs
fondamentaux : espace d’adressage limité et complexité du routage. Les adresses 32 bits
IPv4 ne fournissent pas suffisamment de flexibilité pour le routage global Internet. Le
déploiement de CIDR (Classless InterDomain Routing) a étendu la durée de vie du routage
IPv4 d’un certain nombre d’années, mais l’effort de gestion du routage continue toutefois à
augmenter. Même si le routage IPv4 pouvait être augmenté, Internet finirait par être à court
de numéros de réseau.
L’IETF (Internet Engineering Task Force) ayant reconnu qu’IPv4 ne serait pas capable
d’assumer la croissance phénoménale d’Internet, le groupe de travail IETF IP ng a été
formé. Parmi les propositions effectuées, SIPP (Simple Internet Protocol Plus) a été
choisi comme étape dans le développement d’IP. Il a été renommé IP ng, et RFC1883 a été
finalisé en décembre 1995.
IPv6 étend le nombre maximal d’adresses Internet de façon à gérer la croissance de la
population utilisatrice d’Internet. Par rapport à IPv4, IPv6 présente l’avantage de permettre
la coexistence des nouveautés et des éléments existants. Ceci permet une migration
ordonnée d’IPv4 (adressage 35 bits) à IPv6 (adressage 128 bits) sur un réseau
opérationnel.
Cette présentation est destinée à donner au lecteur une compréhension générale du
protocole IPng. Pour plus d’informations, veuillez vous reporter à RFC 2460, 2373, 2465,
1886, 2461, 2462 et 2553.
Protocole TCP/IP
4-9
Routage et adressage étendus
IPv6 augmente la taille de l’adresse IP de 32 bits à 128 bits, prenant ainsi en charge
davantage de niveaux dans la hiérarchie d’adressage, un nombre beaucoup plus grand de
nœuds adressables et une configuration automatique plus simple des adresses.
Dans IPv6, il existe trois types d’adresses :
unicast
Un paquet envoyé à une adresse unicast est livré à
l’interface identifiée par cette adresse. Une adresse unicast
a une portée particulière : local–liaison, local–site, global. Il
existe également deux adresses unicast spéciales :
•
::/128 (adresse non spécifiée)
•
::1/128 (adresse en boucle)
multicast
Un paquet envoyé à une adresse multicast est livré à
l’interface identifiée par cette adresse. Une adresse
multicast est identifiée par le préfixe ff::/8. Les adresses
multicast ont une portée semblable à celle des adresses
unicast : local–nœud, local–liaison, local–site et
local–organisation.
anycast
Une adresse anycast a un seul expéditeur, plusieurs
auditeurs et un seul interlocuteur (normalement le “plus
proche”, conformément à la mesure de distance des
protocoles de routage). Par exemple, il peut y avoir
plusieurs serveurs Web à l’écoute d’une adresse anycast.
Lorsqu’une requête est envoyée à cette adresse, un seul
serveur répond.
Une adresse anycast ne se distingue pas d’une
adresse unicast. Une adresse unicast devient une
adresse anycast lorsque plus d’une interface est
configurée avec cette adresse.
Remarque :
Il n’existe pas d’adresse de diffusion dans IPv6. Cette fonction est
remplacée par l’adresse multicast.
Configuration automatique
Les principaux mécanismes disponibles, permettant à un nœud de s’initialiser et de
commencer à communiquer avec d’autres nœuds sur un réseau IPv4 sont le codage
“hard–coding”, BOOTP et DHCP.
IPv6 introduit le concept de portée aux adresses IP, dont l’une est local–liaison. Ceci
permet à un hôte à créer une adresse valide à partir du préfixe local–liaison prédéfini et son
identificateur local. Cet identificateur local est en général extrait de l’adresse MAC
(medium access control) de l’interface à configurer. A l’aide de cette adresse, le nœud peut
communiquer avec les autres hôtes sur le même sous–réseau et, pour un sous–réseau
entièrement isolé, peut ne pas avoir besoin d’une autre configuration d’adresse.
Adresses significatives
Avec IPv4, la seule signification généralement identifiable dans les adresses est la diffusion
(en général tout 1 ou tout 0), et les classes (par exemple, une classe D est multicast).
Avec IPv6, il est possible d’examiner rapidement le préfixe pour déterminer la portée
(par exemple, local-liaison), multicast ou unicast, et un mécanisme d’affectation (basé sur
le fournisseur, sur l’implantation géographique, etc.).
Les informations de routage peuvent également être chargées explicitement dans les bits
supérieurs des adresses, bien que l’IETF n’ait pas encore finalisé ce point (pour les
adresses basées sur le fournisseur, les informations de routage sont implicitement
présentes dans l’adresse).
4-10
Guide de gestion du système – Communications et réseaux
Détection d’adresse en double
Lorsqu’une interface est initialisée, ou réinitialisée, elle se sert de la configuration
automatique pour essayer d’associer une adresse de type local-liaison à cette interface
(l’adresse n’est pas encore affectée à cette interface dans le sens traditionnel). A ce stade,
l’interface rejoint les groupes multicast tous nœuds et nœuds sollicités, et leur envoie un
message de découverte de voisinage. Avec l’adresse multicast, le noeud peut déterminer
si cette adresse local-liaison particulière a été préalablement affectée, puis choisir une autre
adresse. Ceci évite une des erreurs communes de gestion de réseau, c’est-à-dire
l’affectation de la même adresse à deux interfaces différentes sur le même lien.
(Il est encore possible de créer des adresses en double de portée globale pour les nœuds
ne se trouvant pas sur le même lien.)
Configuration automatique de découverte voisinage/adresse sans état
Le protocole NDP (Neighbor Discovery Protocol) pour IPv6 est utilisé par des nœuds
(hôtes et routeurs) pour déterminer les adresses de couche liaison pour les voisins connus
sur des liens rattachés, et maintient les tables de routage par destination pour les
connexions actives. Les hôtes utilisent également NDP pour découvrir des routeurs de
voisinage désireux d’acheminer des paquets pour leur compte et détectent les adresses de
couche liaison modifiées. NDP (Neighbor Discovery Protocol) utilise ICMP (Internet Control
Message Protocol) version 6 avec ses propres types de messages uniques. D’une façon
générale, le protocole NDP IPv6 correspond à la combinaison du protocole ARP IPv4,
RDISC (ICMP Router Discovery) et ICMP Redirect (ICMPv4), avec beaucoup
d’améliorations.
IPv6 définit le mécanisme de configuration automatique d’une adresse avec et sans état. La
configuration automatique sans état n’exige pas de configuration manuelle des hôtes, une
configuration, éventuelle, minimale des routeurs; et pas de serveur supplémentaire. Le
mécanisme sans état permet à un hôte de générer ses propres adresses à l’aide d’une
combinaison d’informations disponibles localement et présentées par les routeurs. Les
routeurs annoncent les préfixes qui identifient le(s) sous–réseau(x) associés à un lien,
tandis que les hôtes génèrent un jeton d’interface qui identifie de façon unique une interface
sur un sous–réseau. Une adresse est formée par la combinaison des deux éléments.
En l’absence de routeurs, un hôte ne peut générer que des adresses de type local-liaison.
Ces adresses sont toutefois suffisantes pour la communication entre nœuds rattachés au
même lien.
Simplification de routage
Pour simplifier les problèmes de routage, les adresses IPv6 sont décomposées en deux
parties : un préfixe et un ID. La différence avec le découpage des adresses IPv4 n’est pas
très sensible, mais présente deux avantages :
absence de classe
Il n’y a pas de nombre fixe de bits pour le préfixe ou l’ID, ce
qui permet de réduire les pertes dues à une suraffectation.
imbrication
Il est possible d’utiliser un nombre arbitraire de divisions si
l’on considère différents nombres de bits comme préfixe.
Protocole TCP/IP
4-11
Cas 1 :
_________________________________________________________________
|
128 bits
|
|_______________________________________________________________|
|
Adresse de nœud
|
|_______________________________________________________________|
Cas 2 :
__________________________________________________________________|
|
n bits
|
128– n bits
|
|____________________________________________|____________________|
|
Préfixe sous–réseau
|
ID interface
|
|____________________________________________|____________________|
Cas 3 :
__________________________________________________________________|
|
n bits
|
80– n bits
|
48 bits
|
|_________________________|___________________|___________________|
|
Préfixe abonné
| ID sous–réseau
|
ID interface
|
|_________________________|___________________|___________________|
Cas 4 :
__________________________________________________________________|
|
|
|
|
|
|
s bits
|
n bits
|
m bits | 128–s–n–m bits |
|__________________|________________|____________|________________|
|
|
|
|
|
| Préfixe abonné
| ID zone
| ID sous–
| ID interface
|
|__________________|________________|____________|________________|
En général, IPv4 ne peut aller au delà du cas 3, même avec VLSM (Variable Length Subnet
Mask, masque de sous–réseau de longueur variable). (VLSM est un moyen d’allouer des
ressources d’adresses IP à des sous–réseaux selon leurs besoins plutôt qu’en respectant
des règles générales à l’échelle du réseau). Il s’agit autant d’un artefact de la longueur
d’adresse la plus courte que de la définition des préfixes de longueur variable, mais cela
mérite cependant d’être noté.
Simplification du format d’en-tête
IPv6 simplifie l’en-tête IP, soit par suppression complète soit par déplacement sur un en-tête
d’extension de certains champs trouvés dans l’en-tête IPV4, et il définit un format plus
souple pour les informations facultatives (en-têtes d’extension). Spécifiquement, notez
l’absence de :
• longueur d’en-tête (la longueur est constante)
• identification
• indicateurs
• décalage de fragment (déplacé dans les en-têtes d’extension de fragmentation)
• total de contrôle d’en-tête (l’en-tête de protocole de couche supérieure ou d’extension
de sécurité gère l’intégrité des données)
4-12
Guide de gestion du système – Communications et réseaux
Tableau 1. En–tête IPv4 :
IHL
Version
Type de service
Identification
Durée de vie
Longueur totale
Identificateurs
Protocole
Décalage
fragment
(Offset)
Total de contrôle
d’en–tête (checksum)
Adresse source
Adresse de destination
Options
Remplissage
Tableau 2. En–tête Ipv6 :
Prio
Version
Longueur bloc
Libellé du flux
En–tête suivant
Limite de
tronçon
Adresse source
Adresse de destination
IP ng inclut un mécanisme d’options amélioré par rapport à IPv4. Les options IPv6 sont
placées dans des en-têtes d’extension séparés qui résident entre l’en-tête IPv6 et l’en-tête
de couche transport dans un paquet. La plupart des en-têtes d’extension ne sont pas
examinés ou traités par un routeur le long du chemin de livraison de paquets.
Ce mécanisme apporte une grande amélioration aux performance du routeur pour les
paquets contenant des options. Dans IPv4, la présence d’options requiert l’examen de
toutes les options par le routeur.
Une autre amélioration provient du fait que, contrairement aux options IPv4, les en-têtes
d’extension IPv6 peuvent être d’une longueur arbitraire et le nombre total d’options
transmises dans un paquet n’est pas limité à 40 octets. Cette fonction, ainsi que la façon
dont elle est traitée, permet aux options IPv6 d’être utilisées pour les fonctions qui n’étaient
pas pratiques dans IPv4, comme les options d’authentification et d’encapsulage de
sécurité IPv6.
Pour améliorer les performances de gestion des en-têtes d’option suivants et du protocole
de transport qui suit, les options IPv6 sont toujours un multiple entier de huit octets, pour
conserver cet alignement pour les en–têtes suivants.
En utilisant des en-têtes d’extension au lieu d’un spécificateur de protocole et de champs
d’options, l’intégration des extensions nouvellement définies est plus facile.
Les spécifications actuelles définissent les en-têtes d’extension comme suit :
• Options bond par bond s’appliquant à chaque bond (routeur) sur le chemin
• En-tête de routage pour un routage de source strict ou non (rarement utilisé)
• Un fragment définit le paquet comme un fragment et contient des informations à ce sujet
(les routeur Ipv6 ne fragmentent pas les paquets)
• Authentification (reportez–vous à Sécurité IP dans AIX 5L Version 5.3 Security Guide
• Chiffrement (reportez–vous à Sécurité IP dans AIX 5L Version 5.3 Security Guide
• Options de destination pour le nœud de destination (ignoré par les routeurs)
Protocole TCP/IP
4-13
Amélioration du contrôle trafic/qualité du service
La qualité du service peut être contrôlée à l’aide d’un protocole de contrôle comme RSVP,
et IPv6 fournit une définition de priorité explicite pour les paquets en utilisant le champ de
priorité dans l’en-tête IP. Un nœud peut définir cette valeur pour indiquer la priorité relative
d’un paquet ou d’un ensemble de paquets, pouvant être alors utilisés par le nœud, un
ou plusieurs routeurs, ou la destination pour indiquer que faire du paquet (l’abandonner
ou non).
IPv6 spécifie deux types de priorités, une pour le trafic contrôle en cas de congestion,
et une pour le trafic non contrôlé en cas de congestion. Il n’y a aucun ordre relatif entre
ces deux types.
Le trafic contrôle en cas de congestion est un trafic répondant aux embouteillages par
un algorithme de limitation. Dans ce cas, les priorités sont :
0
trafic non caractérisé
1
trafic ”de remplissage” (par exemple, informations sur le réseau)
2
transfert de données non assisté (par exemple, messagerie automatique)
3
(réservé)
4
transfert de lot assisté (par exemple, FTP)
5
(réservé)
6
trafic interactif (par exemple, Telnet)
7
trafic de contrôle (par exemple, protocoles de routage)
Le trafic non contrôlé en cas de congestion est un trafic répondant à des situations
d’embouteillage par l’abandon (ou simplement la non réexpédition) des paquets, par
exemple le trafic vidéo, audio ou autre trafic en temps réel. Les niveaux explicites ne sont
pas définis avec des exemples, mais l’ordre est semblable à celui utilisé pour le trafic
contrôlé en cas de congestion.
• La valeur la plus basse que la source cherche le plus à rejeter doit être utilisée
pour le trafic.
• La valeur la plus haute que la source cherche le moins à rejeter doit être utilisée
pour le trafic.
Ce contrôle de priorité ne s’applique qu’au trafic provenant d’une adresse source
particulière. Le contrôle de trafic à partir d’une adresse ne constitue pas une priorité
explicitement supérieure à un transfert de lot assisté à partir d’une autre adresse.
Libellé du flux
En-dehors de la définition de priorité de base pour le trafic, IPv6 définit un mécanisme de
spécification d’un flux particulier de paquets. En termes IPv6, un flux est une suite de
paquets envoyés à partir d’une source spécifique vers une destination spécifique (unicast
ou multicast), pour laquelle la source recherche un traitement spécial par les routeurs
intervenants.
Cette identification de flux peut servir pour le contrôle de priorité, mais peut également être
utilisée pour un certain nombre de contrôles.
Le libellé de flux est choisi de façon aléatoire, et ne doit pas être utilisé pour identifier une
caractéristique du trafic différente du flux correspondant. Un routeur ne peut donc pas
déterminer qu’un paquet est d’un type particulier (par exemple, FTP) par le seul examen du
libellé de flux. Il pourra cependant déterminer qu’il s’agit d’une partie de la même suite de
paquets que le dernier paquet portant ce libellé.
Remarque :
4-14
Jusqu’à généralisation de l’utilisation d’IPv6, le libellé de flux est
principalement expérimental. Les utilisations et les contrôles impliquant
des libellés de flux n’ont pas encore été définis ni standardisés.
Guide de gestion du système – Communications et réseaux
Tunnellisation IPv6
La clé d’une transition IPv6 réussie est la compatibilité avec la base installée existante
d’hôtes IPv4 et de routeurs. Le maintien de cette compatibilité permet un passage en
douceur d’Internet sur IPv6.
Dans la plupart des cas, l’infrastructure de routage IPv6 évolue dans le temps. Pendant le
déploiement de l’infrastructure IPv6, l’infrastructure de routage IPv4 existante peut rester
fonctionnelle et peut servir à acheminer le trafic IPv6. L’utilisation de tunnels permet
d’utiliser une infrastructure de routage IPv4 existante pour acheminer le trafic IPv6.
Les hôtes et routeurs IPv6/IPv4 peuvent utiliser des tunnels pour les datagrammes IPv6
sur des zones de la topologie de routage IPv4 en les encapsulant dans des paquets IPv4.
Le tunnel peut être utilisé d’une multitude de façons.
Routeur-routeur
Les routeurs IPv6/IPv4 interconnectés par une
infrastructure IPv4 peuvent faire passer dans un tunnel les
reliant des paquets IPv6. Dans ce cas, le tunnel fractionne
un segment du chemin complet qu’emprunte le paquet
IPv6.
Hôte-routeur
Les hôtes IPv6/IPv4 peuvent faire passer dans un tunnel
des paquets IPv6 vers un routeur intermédiaire IPv6/IPv4
accessible via une infrastructure IPv4. Ce type de tunnel
fractionne le premier segment du chemin complet du
paquet.
Hôte-hôte
Les hôtes IPv6/IPv4 interconnectés par une infrastructure
IPv4 peuvent faire passer des paquets IPv6 dans un tunnel
les reliant. Dans ce cas, le tunnel fractionne tout le chemin
qu’emprunte le paquet.
Routeur-hôte
Les routeurs IPv6/IPv4 peuvent faire passer dans un tunnel
des paquets IPv6 jusqu’à leur hôte final IPv6/IPv4. Dans ce
cas, le tunnel ne fractionne que le dernier segment du
chemin complet.
Les techniques de tunnel sont généralement classées en fonction du mécanisme par lequel
le nœud d’encapsulage détermine l’adresse du nœud en fin de tunnel. Dans les méthodes
routeur-routeur ou hôte-routeur, le paquet IPv6 est acheminé par tunnel vers un routeur.
Dans les méthodes hôte-hôte ou routeur-hôte, le paquet IPv6 passe dans un tunnel tout le
long jusqu’à sa destination.
Le noeud d’entrée du tunnel (noeud d’encapsulage) crée un en-tête IPv4 d’encapsulage et
transmet le paquet encapsulé. Le noeud de sortie du tunnel (noeud de décapsulage) reçoit
le paquet encapsulé, supprime l’en-tête IPv4, met à jour l’en-tête IPv6 et traite le paquet
IPv6 reçu. Toutefois, le nœud d’encapsulage doit mettre à jour les informations sur l’état du
logiciel pour chaque tunnel, par exemple MTU pour chaque tunnel, pour traiter les
paquets IPv6 acheminés dans le tunnel.
Deux types de tunnel existent dans IPv6 : des tunnels automatiques et des tunnels
configurés.
Tunnels automatiques
Les tunnels automatiques sont configurés à l’aide des informations de l’adresse IPv4
incorporées dans une adresse IPv6. L’adresse IPv6 de l’hôte de destination inclut des
informations sur l’adresse IPv4 à laquelle le paquet doit être raccordé.
Tunnels configurés
La configuration des tunnels configurés doit être effectuée manuellement. Vous utilisez les
tunnels configurés lorsque vous travaillez avec des adresses IPv6 qui ne contiennent pas
d’informations IPv4. Les adresses IPv6 et IPv4 des extrémités du tunnel doivent être
spécifiées.
Protocole TCP/IP
4-15
Pour plus d’informations sur la configuration automatique et les tunnels configurés,
reportez–vous à la section Configuration de la tunnellisation dans IPv6, page 1-8.
Sécurité IPv6
Pour plus d’informations sur la sécurité IP, versions 4 et 6, reportez–vous à la section
Sécurité du protocole (IP) dans le manuel AIX 5L Version 5.3 – Guide de sécurité.
Support IPv6 des adresses locales du site et des liens Multihomed
Plusieurs interfaces peuvent être définies pour un hôte. Un hôte comportant deux ou
plusieurs interfaces interactives est dit multihomed. Chaque interface est associée à une
adresse de type local. Ces adresses sont suffisantes pour la communication entre nœuds
rattachés à un même lien.
Un hôte multihomed est associés à deux ou plusieurs adresses de type local. Dans cette
implémentation IPv6, 4 options permettent de déterminer comment la résolution des
adresses de couche liaison s’effectue sur les hôtes multihomed. L’option 1 est activée par
défaut.
4-16
Option 0
Aucune action multihomed n’est effectuée. Les transmissions sortent
par la première interface de type local. Lorsque le protocole NDP
(Neighbor Discovery Protocol) doit résoudre les adresses, il
envoie (multicast) un message de découverte de voisinage sur
chaque interface pour laquelle est définie cette adresse de type
local. NDP met le paquet de données en attente jusqu’à ce qu’il
reçoive le premier message d’avis de voisinage (Neighbor
Advertisement). Le paquet de données est alors transmis par cette
liaison.
Option 1
Lorsque le protocole NDP doit résoudre une adresse (lorsqu’il
envoie un paquet de données vers une destination et que les
informations relatives à la liaison pour le tronçon suivant ne sont pas
dans le cache de voisinage (Neighbor Cache), il envoie (multicast)
un message de découverte de voisinage sur chaque interface pour
laquelle est définie cette adresse de type local. NDP met alors le
paquet de données en attente jusqu’à ce qu’il reçoive les
informations concernant la liaison. NDP attend de recevoir la
réponse de chaque interface. Ceci permet de garantir que les
paquets de données sont envoyés par l’intermédiaire des interfaces
sortantes appropriées. Si NDP répondait au premier avis de
voisinage sans attendre les autres réponses, il pourrait arriver qu’un
paquet de données soit envoyé sur une liaison non associée à
l’adresse source du paquet. Comme NDP doit attendre toutes les
réponses, on constate un certain délai avant l’envoi du premier
paquet. De toute façon, un délai est également à prévoir lors de
l’attente de la première réponse.
Guide de gestion du système – Communications et réseaux
Option 2
Le fonctionnement multihomed est autorisé mais l’expédition d’un
paquet de données est limitée à l’interface spécifiée par main_if6.
Lorsque le protocole NDP doit résoudre les adresses, il envoie
(multicast) un message de découverte de voisinage sur chaque
interface pour laquelle est définie cette adresse de type local. Il
attend alors le message d’avis de voisinage en provenance de
l’interface spécifiée par main_if6 (voir la commande no). Dès qu’il
reçoit la réponse de cette interface, le paquet de données est
envoyé sur cette liaison.
Option 3
Le fonctionnement multihomed est autorisé mais l’expédition d’un
paquet de données est limitée à l’interface spécifiée par main_if6 et
les adresses de type local ne sont acheminées que pour l’interface
spécifiée par main_site6 (voir la commande no). Le protocole NDP
fonctionne comme avec l’option 2. Pour les applications qui
acheminent des paquets de données en utilisant des adresses de
type local, sur un hôte multihomed, seule l’adresse locale spécifiée
par main_site6 est utilisée.
Suivi de paquet
Le suivi de paquet consiste à contrôler le parcours d’un paquet à travers les couches
jusqu’à destination. La commande iptrace permet d’effectuer ce contrôle au niveau de la
couche Interface de réseau. La commande ipreport génère en sortie un compte rendu de
suivi aux formats hexadécimal et ASCII. La commande trpt effectue le contrôle au niveau
de la couche transport pour le protocole TCP. La sortie de la commande trpt est plus
détaillée : elle comprend des informations sur la date et l’heure, l’état TCP et la mise en
séquence des paquets.
Protocole TCP/IP
4-17
En-têtes de paquet au niveau interface de réseau
Au niveau de la couche Interface de réseau, des en-têtes sont associés aux données
sortantes.
Figure 8. Flux de paquet dans la structure de l’interface réseau Cette illustration
représente un flux de données bidirectionnel dans les couches de la structure de l’interface
réseau. Ce sont, en partant du haut : (logiciel) couche réseau, couche d’interface réseau,
pilote de périphérique, et (matériel) carte adaptateur réseau ou connexion.
Réseau
Interface de réseau
Pilote d’unité
LOGICIEL
MATERIEL
Carte réseau
Carte/Connexion
Les paquets transitent alors par la carte de réseau vers le réseau correspondant. Ils
traversent parfois plusieurs passerelles avant d’atteindre leur destination. Une fois arrivés
au réseau de destination, ces en-têtes sont supprimés et les données envoyées à l’hôte
concerné.
Ce processus s’applique aux informations d’en-tête de plusieurs interfaces de réseau
courantes.
4-18
Guide de gestion du système – Communications et réseaux
En-têtes de trame pour carte Ethernet
Le tableau ci-après représente un en-tête de trame IP (Internet Protocol) ou ARP
(Address Resolution Protocol) pour la carte Ethernet.
En-tête de trame de carte Ethernet
Zone
Longueur
Définition
DA
6 octets
Adresse de destination.
SA
6 octets
Adresse source. Si le bit 0 de cette zone est positionné
à 1, l’information de routage (RI) est présente.
Type
2 octets
Type du paquet : IP ou ARP. IP ou ARP (le type est
représenté par des numéros, comme indiqué
ci-dessous).
Numéros de la zone Type :
IP
0800
ARP
0806
En-tête de trame pour réseau en anneau à jeton
L’en-tête MAC (Medium Access Control) pour carte anneau à jeton se compose des cinq
zones ci-dessous :
En-tête MAC pour réseau en anneau à jeton
Zone
Longueur
Définition
AC
1 octet
Contrôle d’accès. La valeur x‘00’ confère à l’en-tête la priorité 0.
FC
1 octet
Contrôle de la zone. La valeur x‘40’ indique une trame LLC
(Logical Link Control).
DA
6 octets
Adresse de destination.
SA
6 octets
Adresse source. Si le bit 0 de cette zone est positionné à 1,
l’information de routage (RI) est présente.
RI
18 octets
Information de routage. Les valeurs possibles sont fournies plus
loin.
L’en-tête MAC comprend deux zones d’informations sur le routage, de 2 octets chacune :
le contrôle de routage (RC) et les numéros de segment. Huit numéros de segment au
maximum peuvent être utilisés pour désigner les destinataires d’une diffusion limitée.
Les informations RC sont fournies aux octets 0 et 1 de la zone RI. Les deux premiers bits
de la zone RC peuvent prendre les valeurs suivantes :
bit (0) = 0
Utilisation de la route de non–diffusion, spécifiée dans la zone RI.
bit (0) = 1
Création de la zone RI et diffusion vers tous les anneaux.
bit (0) = 1
Diffusion via tous les ponts.
bit (1) = 1
Diffusion via certains ponts.
Protocole TCP/IP
4-19
L’en-tête LLC (contrôle de liaison logique) comporte les cinq zones suivantes :
En-tête LLC 802.3
Zone
Longueur
Définition
DSAP
1 octet
Point d’accès au service de destination. La valeur est x‘aa’.
SSAP
1 octet
Point d’accès au service source. La valeur est x‘aa’.
CONTROL 1 octet
Commandes et réponses LLC (contrôle de liaison logique).
Trois valeurs possibles (présentées plus loin).
PROT_ID
3 octets
ID de protocole. Cette zone est réservée. Sa valeur est de x‘0’.
TYPE
2 octets
Type du paquet : IP ou ARP.
Valeurs de la zone CONTROL
4-20
x‘03’
Trame d’information non numérotée (UI). Mode de transmission normale
ou non séquentielle des données de la carte anneau à jeton sur le réseau.
Les données sont mises en séquence par TCP/IP.
x‘AF’
Trame XID (Exchange Identification). Elle transmet les caractéristiques
de l’hôte émetteur.
x‘E3’
Trame de test. Cette trame teste la route de transmission,
et renvoie les données reçues.
Guide de gestion du système – Communications et réseaux
En-têtes de trame 802.3
L’en-tête MAC (Medium Access Control) pour la carte 802.3 est composé de deux zones,
comme vous pouvez le constater dans le tableau d’en–têtes suivant.
En-tête MAC 802.3
Zone
Longueur
Définition
DA
6 octets
Adresse de destination.
SA
6 octets
Adresse source. Si le bit 0 de cette zone est positionné à 1,
l’information de routage (RI) est présente.
L’en-tête LLC (Logical Link Control) pour la carte 802.3 est identique à l’en-tête MAC
de l’anneau à jeton.
Protocole TCP/IP
4-21
Protocoles Internet de niveau réseau
Les protocoles Internet de niveau réseau gèrent la communication entre les machines.
Autrement dit, c’est la couche qui assure le routage TCP/IP. Ces protocoles réceptionnent
les demandes de transmission de paquets (dotés de l’adresse réseau de la machine
destinataire) issues de la couche Transport, convertissent les paquets en datagrammes
et les communiquent à la couche Interface de réseau (voir figure).
Figure 9. Couche réseau de la suite de protocoles TCP/IP Cette illustration représente
les différentes couches de la suite de protocoles TCP/IP. En partant du haut, la couche
d’application comprend l’application. La couche de transport comprend UDP et TCP.
La couche réseau comprend l’interface réseau (matériel). La couche matérielle contient
le réseau physique.
PROTOCOLE
COUCHE
Application
APPLICATION
Transport
UDP
Réseau
Interface de réseau
TCP
PROTOCOLE INTERNET
INTERFACE DE RESEAU (MATERIEL)
Matériel
RESEAU PHYSIQUE
TCP/IP fournit les protocoles requis pour être conforme à RFC 1100 (Official Internet
Protocols), ainsi que d’autres protocoles couramment utilisés par les machines hôtes
en environnement Internet.
Remarque : Sous TCP/IP, l’utilisation des numéros de réseau, version, prise,
service et protocole Internet est également conforme à RFC 1010 (Assigned Numbers).
Protocole de résolution d’adresse
Le premier protocole intervenant au niveau réseau est le protocole de résolution
d’adresse (ARP). Ce protocole est chargé de traduire dynamiquement les adresses
Internet en adresses matérielles uniques sur les réseaux locaux.
Pour illustrer le fonctionnement d’ARP, prenons le cas de deux noeuds, jim et fred. Si le
nœud jim désire communiquer avec fred, et que jim et fred ne résident pas sur le
même réseau local (LAN), jim et fred doivent utiliser des ponts, routeurs ou passerelles
et des adresses IP. Au sein d’un réseau local, les nœuds requièrent en outre les adresses
matérielles (niveau inférieur).
Les noeuds implantés sur le même segment d’un réseau local font appel au protocole ARP
pour déterminer l’adresse matérielle d’autres noeuds. Tout d’abord, le noeud jim diffuse
une demande ARP pour connaître l’adresse matérielle de fred. Cette demande comporte
les adresses IP et matérielle de jim et l’adresse IP de fred. Lorsque fred reçoit la
requête ARP, il place une entrée destinée à jim dans sa mémoire cache ARP (utilisée pour
établir rapidement l’équivalence entre l’adresse IP et l’adresse matérielle). Ensuite, fred
renvoie directement à jim une réponse ARP avec l’adresse IP et l’adresse matérielle de
fred. Lorsque le nœud jim reçoit cette réponse, il place à son tour une entrée destinée à
fred dans sa mémoire cache ARP.
Dès lors, jim peut correspondre directement avec fred sans recours au protocole ARP
(à moins que l’entrée en mémoire cache ARP destinée à fred ne soit supprimée).
Contrairement à la plupart des protocoles, les en-têtes de paquet ARP n’ont pas un format
fixe. Le message est conçu pour s’adapter à diverses technologies de réseau, telles que :
• Carte de réseau local Ethernet (qui prend en charge les protocoles Ethernet et 802.3)
4-22
Guide de gestion du système – Communications et réseaux
• Carte de réseau en anneau à jeton
• Carte de réseau FDDI (Fiber Distributed Data Interface)
En revanche, ARP ne traduit pas les adresses pour SLIP ou convertisseur optique série
(SOC), car il s’agit de connexions point à point.
Les tables de traduction sont tenues à jour par le noyau et les utilisateurs ou les
applications n’ont pas d’accès direct à ARP. Lorsqu’une application envoie un paquet
Internet à l’un des pilotes d’interface, le pilote demande l’équivalence d’adresse. Si cette
équivalence ne figure pas dans la table, un paquet ARP de diffusion est envoyé aux hôtes
du réseau local via le pilote d’interface demandeur.
Les entrées de la table d’équivalence (mappage) ARP sont supprimées au bout de
20 minutes et les entrées incomplètes au bout de 3 minutes. Pour insérer une entrée
permanente dans la table, lancez la commande arp assortie du paramètre pub :
arp –s 802.3 host2 0:dd:0:a:8s:0 pub
Lorsqu’un hôte prenant en charge ARP reçoit un paquet de demande ARP, il note l’adresse
IP et l’adresse matérielle du système demandeur et met à jour sa table d’équivalence. Si
son adresse IP ne correspond pas à l’adresse demandée, il rejette le paquet. Sinon, il
envoie un paquet de réponse au système demandeur. Le système demandeur enregistre la
nouvelle équivalence pour l’appliquer aux paquets Internet similaires en attente.
Protocole ICMP
Le deuxième protocole intervenant au niveau réseau est le protocole de message de
contrôle interréseau (ICMP). Ce protocole, partie intégrante de toute implémentation IP gère
les messages d’erreur et de contrôle pour IP. Il est utilisé par les passerelles et les
systèmes hôtes pour transmettre les comptes rendus d’incidents aux machines émettrices
d’un paquet. Il est chargé de :
• tester l’accessibilité d’une destination,
• signaler les erreurs de paramètres dans un en-tête de datagramme,
• effectuer la synchronisation horaire et évaluer le temps de transit,
• obtenir les adresses Internet et les masques de sous-réseau.
Remarque :
ICMP utilise la prise en charge de base d’IP comme s’il s’agissait d’un
protocole de niveau supérieur. ICMP fait partie intégrante du protocole IP
et doit être mis en œuvre par tout module IP.
ICMP rend compte des anomalies de l’environnement de communications sans garantir
pour autant la fiabilité du protocole IP. Autrement dit, il ne garantit pas la livraison d’un
paquet IP ni l’envoi d’un message ICMP à l’hôte source en cas d’échec ou d’erreur de
livraison.
Les messages ICMP sont émis dans les cas suivants :
• destination d’un paquet inaccessible,
• capacité tampon insuffisante sur l’hôte passerelle pour la réexpédition d’un paquet,
• passerelle capable d’obtenir que l’hôte achemine le courrier via un chemin plus court.
TCP/IP envoie et reçoit plusieurs types de message ICMP (reportez–vous à Types de
messages ICMP page 4-24). Le protocole ICMP intégré au noyau, ne dispose d’aucune
interface API.
Protocole TCP/IP
4-23
Types de messages ICMP
ICMP peut envoyer ou recevoir des messages du type :
echo request
Demande d’écho envoyée par les hôtes et les passerelles
pour tester l’accessibilité de la destination.
information request
Demande d’information envoyée par les hôtes et les
passerelles pour obtenir l’adresse Internet d’un réseau auquel
ils sont connectés. Avec ce type de message, la portion
réseau de l’adresse de destination IP est positionnée à 0.
timestamp request
Demande de l’heure courante à la machine de destination.
address mask request
Demande de masque d’adresse envoyée par l’hôte pour
identifier son masque de sous-réseau. Cette demande est
envoyée à une passerelle s’il en connaît l’adresse ou sous
forme de message de diffusion.
destination unreachable Message envoyé lorsqu’une passerelle ne parvient pas à
livrer un datagramme IP.
source quench
Demande effectuée auprès de l’émetteur de datagrammes
lorsque son débit d’émission est trop élevé pour que les
passerelles ou hôtes puissent traiter les datagrammes
entrants.
redirect message
Message de redirection envoyé lorsqu’une passerelle détecte
qu’un hôte n’utilise pas une route optimale.
echo reply
Réponse d’écho renvoyée, par la machine réceptrice,
à l’émetteur d’une demande d’écho.
information reply
Message envoyé par les passerelles en réponse aux
demandes d’adresse (avec les zones source et destination
du datagramme IP renseignées).
timestamp reply
Réponse indiquant l’heure courante.
address mask reply
Réponse de masque d’adresse envoyée aux machines
qui requièrent des masques de sous-réseau.
parameter problem
Message envoyé lorsqu’un hôte ou une passerelle relève
une anomalie dans un en-tête de datagramme.
time exceeded
Message envoyé lorsque les conditions ci–dessous sont
réunies :
• A chaque datagramme IP est associée une durée de vie
(nombre de bonds), décrémentée par chaque passerelle.
• Un datagramme est rejeté par une passerelle,
sa durée de vie ayant atteint la valeur 0.
Internet Timestamp
Horodateur Internet utilisé pour enregistrer les dates
et heures durant le parcours.
Protocole Internet
Le troisième protocole intervenant au niveau réseau est le protocole Internet (IP).
IP est un protocole sans connexion car il traite chaque paquet d’informations séparément.
Il effectue la livraison des paquets pour Internet, sans garantie de livraison (aucun
acquittement de message n’est exigé auprès des hôtes émetteur, récepteur et
intermédiaires) et sans connexion (chaque paquet d’informations est traité séparément).
4-24
Guide de gestion du système – Communications et réseaux
IP assure l’interface avec les protocoles de niveau Interface de réseau. Les connexions
physiques d’un réseau transmettent l’information sous forme d’une trame composée d’un
en-tête et de données. L’en-tête contient les adresses source et destination. IP utilise un
datagramme Internet contenant des informations similaires à celles de la trame physique.
Son en–tête comporte également les adresses Internet source et de destination des
données.
IP définit le format des données acheminées sur le réseau Internet (voir figure).
Figure 10. En–tête de paquet IP (Internet Protocol) Cette illustration représente les
premiers 32 bits d’un en–tête de paquet IP typique. Le tableau ci–dessous dresse la liste
des différentes entités.
Bits
31
4
8
0
16
19
Longueur totale
Version Longueur Type de service
Décalage fragment
Identi–
Identificateur
ficateur
(Offset)
Contrôle d’en–tête (checksum)
Durée de vie
Protocole
Adresse source
Adresse de destination
Option
Données
Définitions des zones d’en-tête IP
Version
Version IP utilisée. La version courante du protocole IP est 4.
Longueur
Longueur de l’en-tête du datagramme, en nombre de mots de
32 bits.
Type de service
Zone comprenant cinq champs qui définissent pour le paquet
concerné le type de priorité, le délai, le débit et le niveau de
fiabilité souhaités. Cette demande n’est pas garantie par Internet.
Les paramètres par défaut de ces cinq champs sont normaux.
Actuellement, cette zone n’est pas utilisée par Internet de façon
généralisée. La mise en œuvre d’IP est conforme à la
spécification IP RFC 791, Internet Protocol.
Longueur totale
Longueur du datagramme, en octets, incluant l’en-tête et les
données. La fragmentation en paquets au niveau des passerelles
et le réassemblage à destination sont assurés. La longueur totale
du paquet IP peut être configurée par interface individuelle à l’aide
de wsm de Web-based System Manager, de la commande
ifconfig ou via le raccourci smit chinet de SMIT. Pour déclarer
ces valeurs comme permanentes dans la base de données de
configuration, utilisez Web-based System Manager ou SMIT,
et pour les définir ou les modifier dans le système en exécution,
utilisez la commande ifconfig.
Identificateur
Nombre entier unique identifiant le datagramme.
Indicateurs (flags)
de fragment
Contrôle la fragmentation du datagramme ainsi que le champ
Identification. Indique si le datagramme doit être fragmenté et
si le fragment courant est le dernier.
Protocole TCP/IP
4-25
Décalage fragment
(Offset)
Décalage du fragment dans le datagramme d’origine, en unités
de 8 octets.
Durée de vie
Durée de rétention du datagramme sur Internet. Ce paramètre
évite de conserver indéfiniment sur Internet les datagrammes
qui n’ont pas abouti. La durée de rétention par défaut est de
255 secondes.
Protocole
Type de protocole de niveau supérieur.
Total de contrôle
d’en–tête
(checksum)
Nombre calculé pour assurer l’intégrité des valeurs d’en-tête.
Adresse source
Adresse Internet de l’hôte émetteur.
Adresse de
destination
Adresse Internet de l’hôte récepteur.
Options
Options de test et de mise au point du réseau. Zone facultative
pour certains datagrammes.
End of Option List
Indique la fin de la liste des options. Utilisé à la fin de la liste des
options (et non de chaque option) Cette option doit être utilisée
uniquement si la fin de la liste ne coïncide par avec la fin de
l’en–tête IP. Cette option n’est utilisée que si les options
excèdent la longueur du datagramme.
No Operation
Permet l’alignement avec d’autres options. Par exemple,
alignement à 32 bits du début de l’option suivante.
Loose Source and record Route
Informations de routage fournies par la source du datagramme
Internet aux passerelles, qui les utilisent pour expédier le
datagramme à destination et les enregistrent. Il s’agit d’une
route source libre : la passerelle ou l’IP hôte peut utiliser
n’importe quelle route via un nombre quelconque de passerelles
intermédiaires pour atteindre l’adresse suivante dans la route.
Strict Source and record Route
Informations de routage fournies par la source du datagramme
Internet aux passerelles, qui les utilisent pour expédier le
datagramme à destination et les enregistrent. Il s’agit d’une
route source imposée : la passerelle ou l’IP hôte doit envoyer le
datagramme directement à l’adresse suivante spécifiée par la
route source en passant par le réseau direct indiqué dans
l’adresse, pour atteindre la passerelle ou l’hôte suivant spécifié
dans la route.
Record Route
Cette option permet d’enregistrer le parcours suivi par le
datagramme Internet.
Stream Identifier
Cette option véhicule un identificateur de flot (stream) à travers
des réseaux qui ne prennent pas en charge le concept de flot.
Internet Timestamp
Enregistre la date et l’heure le long du parcours du
datagramme.
L’en-tête IP est automatiquement préfixé aux paquets sortants, et supprimé des paquets
entrants qui vont être envoyés aux protocoles de niveau supérieur. Le protocole IP procure
un système d’adressage universel des hôtes sur le réseau Internet.
4-26
Guide de gestion du système – Communications et réseaux
Protocoles Internet de niveau transport
Les protocoles TCP/IP de niveau transport (voir figure) permettent aux programmes
d’application de communiquer entre eux.
Figure 11. Couche de transport de la suite de protocoles TCP/IP Cette illustration
représente les différentes couches de la suite de protocoles TCP/IP. En partant du haut, la
couche d’application comprend l’application. La couche de transport comprend UDP et TCP.
La couche réseau comprend l’interface réseau (matériel). La couche matérielle contient le
réseau physique.
COUCHE
Application
Transport
PROTOCOLE
APPLICATION
UDP
TCP
Réseau
PROTOCOLE INTERNET
Interface de réseau
INTERFACE DE RESEAU
Matériel
RESEAU PHYSIQUE
Les protocoles UDP (User Datagram Protocol) et TCP en sont les principaux : ils
autorisent l’interconnexion d’hôtes Internet et l’échange de messages entre applications
implantées sur des hôtes différents. Le mécanisme est le suivant : lorsqu’une application
envoie à la couche Transport une demande d’expédition de message, les protocoles UDP
et TCP fragmentent l’information en paquets qu’ils dotent d’un en-tête portant l’adresse de
destination. Ces paquets sont alors soumis par les protocoles à la couche réseau. Pour
déterminer la destination exacte du message, les protocoles TCP et UDP se servent des
ports de protocole de l’hôte.
Les protocoles et applications de niveau supérieur utilisent UDP pour les connexions
datagramme et TCP pour les connexion Stream (trains de données). Ces protocoles
sont mis en œuvre par l’interface Sockets du système d’exploitation.
Protocole UDP
Le protocole UDP intervient lorsqu’une application de réseau doit envoyer des messages à
une application ou un process d’un autre réseau : il fournit aux applications d’hôtes Internet
le moyen de communiquer par datagramme. L’émetteur d’un message ne connaît pas les
process actifs au moment de l’envoi, c’est pourquoi le protocole UDP utilise les ports de
protocole de destination (ou sur un hôte, points de destination abstraits dans une machine),
identifiés par des nombres entiers positifs, pour envoyer les messages à un ou plusieurs
points de destination. A la réception des messages, les ports de protocole placent les
messages dans des files d’attente, où ils seront récupérés en temps voulu par les
applications du réseau récepteur.
UDP fait appel à l’IP sous–jacent pour envoyer ses datagrammes, il assure donc la livraison
des messages sans connexion comme le fait le protocole IP, mais sans garantie de livraison
ni de protection contre la duplication. UDP présente cependant deux particularités : il
autorise l’émetteur à spécifier le numéro des ports source et cible et calcule le total de
contrôle de l’en-tête et des données. Il offre ainsi aux applications émettrices et réceptrices
un moyen de fiabiliser la livraison d’un message.
Protocole TCP/IP
4-27
Figure 12. En–tête de paquet UDP (User Datagram Protocol) Cette illustration
représente les premiers 32 bits d’un en–tête de paquet UDP typique. Les 16 premiers bits
contiennent le numéro de port source et la longueur. Les 16 bits suivants contiennent le
numéro de port de destination et le total de contrôle.
Bits
16
0
NUMERO DE PORT SOURCE
LONGUEUR
31
NUMERO DE PORT CIBLE
TOTAL DE CONTROLE
Les applications qui exigent une garantie de livraison des datagrammes doivent exercer
elles-mêmes un contrôle si elles utilisent UDP. Les applications qui exigent une garantie de
livraison des flots de données doivent recourir à TCP.
Définitions des zones d’en-tête UDP
Numéro de port source
Adresse du port de protocole émetteur de l’information.
Numéro de port cible
Adresse du port de protocole récepteur de l’information.
Longueur
Longueur en octets du datagramme UDP.
Total de contrôle
(Checksum)
Contrôle du datagramme UDP sur la base du même
algorithme que le protocole IP.
L’interface de programmation d’applications (API) avec UDP est constituée d’un ensemble
de sous-routines de bibliothèque fourni par l’interface Sockets.
Protocole TCP
Le protocole TCP (Transmission Control Protocol) assure le transfert fiable des flots entre
les hôtes Internet. Comme UDP, il fait appel au protocole sous-jacent IP pour véhiculer les
datagrammes et en assurer la transmission par bloc en flot continu d’un port de process à
l’autre. Contrairement à UDP, TCP garantit une livraison fiable des messages. Il garantit que
les données ne seront livrées au process destinataire sans que les données soient altérées,
perdues, dupliquées ou restituées dans le désordre. Ainsi, les programmeurs d’applications
ne sont pas contraints de gérer ce type d’erreurs dans leur logiciel.
4-28
Guide de gestion du système – Communications et réseaux
TCP présente les caractéristiques suivantes :
Transfert de données
de base
TCP peut véhiculer entre ses utilisateurs un flot continu
d’octets 8 bits en regroupant des octets en segments pour
les transmettre par Internet. Avec TCP, la taille des segments
atteint au moins 1024 octets. En général, c’est TCP qui
détermine le moment propice pour assembler et expédier les
paquets.
Fiabilité
TCP doit récupérer les données altérées, perdues,
dupliquées ou désorganisées par Internet. Pour ce faire, il
affecte un numéro de séquence à chaque octet transmis et
exige un accusé de réception positif (ACK) de la part du TCP
récepteur. S’il ne reçoit pas cet accusé après un certain délai,
les données sont retransmises. Ce délai est fixé
dynamiquement pour chaque connexion, en fonction du
temps de transmission aller-retour. Côté destinataire, les
numéros de séquence servent à réordonner les segments et
à éliminer les doublons. Les données altérées sont traitées
grâce au total de contrôle ajouté à chaque segment : ce total
est vérifié à la réception des segments et les segments
altérés sont rejetés.
Contrôle de flux
TCP permet de réguler le débit des données émises, en
associant à chaque accusé de réception une fenêtre
indiquant l’intervalle de numéros de séquence admis au-delà
du dernier segment reçu. La fenêtre précise le nombre
d’octets que l’émetteur est autorisé à envoyer avant de
recevoir la prochaine autorisation.
Multiplexage
TCP permet à un grand nombre de process d’un même hôte
d’utiliser simultanément les fonctions de communication TCP.
TCP reçoit un ensemble d’adresses de ports pour chaque
hôte et combine le numéro de port à l’adresse réseau et à
l’adresse hôte pour pouvoir identifier chaque prise de façon
unique. Une paire de prises identifie à son tour chaque
connexion de façon unique.
Connexions
TCP doit initialiser et tenir à jour certaines informations d’état
pour chaque flot de données. La combinaison de ces
informations (prises, numéros de séquence, tailles de
fenêtre) est appelée connexion. Chaque connexion est
identifiée par une paire de prises uniques, une pour chaque
extrémité.
Priorité et protection
Les utilisateurs de TCP peuvent spécifier un niveau de
priorité et de protection pour leurs communications. Sinon,
des valeurs par défaut sont prévues.
La figure d’un en–tête de paquet TCP illustre ces caractéristiques.
Protocole TCP/IP
4-29
Figure 13. En–tête de paquet TCP (Transmission Control Protocol) Cette illustration
représente le contenu de l’en–tête du paquet TCP. Les entités individuelles sont
répertoriées dans le texte ci–dessous.
Bits
0
16
8
31
Port cible
Port source
Numéro de séquence
Numéro d’acquittement
Décalage
Réservé
Code
Total de contrôle (Checksum)
Fenêtre
Pointeur urgent
Options
Remplissage
Données
Définitions de zones d’en-tête TCP
Port source
Numéro de port du programme d’application source.
Port cible
Numéro de port du programme d’application cible.
Numéro de séquence
Numéro d’ordre du premier octet de données dans le
segment.
Numéro d’acquittement
Numéro identifiant la position du plus grand octet reçu.
Décalage
Décalage (Offset) de la portion de données du segment.
Réservé
Zone réservée à un usage ultérieur.
Code
Bits de contrôle servant à identifier l’objet d’un segment :
URG
La zone Pointeur urgent est valide.
ACK
La zone Acquittement est valide.
PSH
Le segment requiert un PUSH.
RTS
Réinitialise la connexion.
SYN
Synchronise les numéros de séquence.
FIN
Fin du flot d’octets.
4-30
Fenêtre
Volume de données admissible par la destination.
Total de contrôle
(Checksum)
Vérifie l’intégrité des données et de l’en-tête du segment.
Guide de gestion du système – Communications et réseaux
Pointeur urgent
Indique les données à livrer dès que possible.
Le pointeur marque la fin des données urgentes.
Options
End of Option List
Utilisé à la fin de la liste des options options (et non
de chaque option) uniquement si la fin de la liste ne
coïncide par avec la fin de l’en–tête TCP.
No Operation
Indique la limite entre deux options. Par exemple,
alignement du début d’une option suivante sur un mot.
L’émetteur n’étant pas obligé d’utiliser cette option, le
destinataire doit être prêt à traiter les options même ne
commençant pas sur un mot.
Maximum Segment Size
Taille maximale de segment acceptable par TCP
(indiquée dans la demande de connexion initiale).
Cette option doit être envoyée uniquement dans
la demande de connexion initiale.
L’interface de programmation d’applications (API) avec TCP est constituée d’un ensemble
de sous-routines de bibliothèque fourni par l’interface Sockets.
Protocoles Internet de niveau application
Au niveau du programme d’application, TCP/IP met en œuvre des protocoles Internet de
niveau supérieur (voir figure).
Figure 14. Couche d’application de la suite de protocoles TCP/IP Cette illustration
représente les différentes couches de la suite de protocoles TCP/IP. En partant du haut, la
couche d’application comprend l’application. La couche de transport comprend UDP et TCP.
La couche réseau comprend l’interface réseau (matériel). La couche matérielle contient le
réseau physique.
PROTOCOLE
COUCHE
Application
APPLICATION
Transport
UDP
TCP
Réseau
PROTOCOLE INTERNET
Interface de réseau
INTERFACE DE RESEAU
Matériel
RESEAU PHYSIQUE
Lorsqu’une application doit envoyer des données à une application sur un hôte différent, les
informations sont envoyées aux protocoles de niveau transport pour être préparées à la
transmission.
Les protocoles Internet de niveau application officiels englobent :
• Domain Name Protocol ( Domain Name Protocol, page 4-32)
• Exterior Gateway Protoco l ( Exterior Gateway Protocol, page 4-32)
• File Transfer Protocol ( File Transfer Protocol, page 4-34)
• Protocole Name/Finger ( Protocole Name/Finger, page 4-35)
• Telnet Protocol ( Telnet Protocol, page 4-34)
• Protocole TFTP ( Protocole TFTP, page 4-35)
Protocole TCP/IP
4-31
TCP/IP met en œuvre d’autres protocoles de niveau supérieur, non officiels, mais
couramment utilisés par la communauté Internet pour les programmes d’application.
A savoir :
• Distributed Computer Network (DCN) Local–Network Protocol
( Distributed Computer Network Local–Network Protocol, page 4-36)
• Remote Command Execution Protocol
( Remote Command Execution Protocol, page 4-36)
• Remote Login Protocol ( Remote Login Protocol, page 4-36)
• Remote Shell Protocol ( Remote Shell Protocol, page 4-36)
• Wake On LAN Protocol ( Wake On LAN (WOL) Protocol, page 4-36)
• Routing Information Protocol ( Routing Information Protocol, page 4-36)
• Time Server Protocol ( Time Server Protocol, page 4-37).
TCP/IP ne fournit pas d’interface API à ces protocoles situés au niveau de l’application.
Protocole DOMAIN
Le protocole DOMAIN permet à un système hôte membre d’un domaine de jouer le rôle de
serveur de noms auprès des autres systèmes hôtes de son domaine. Il utilise comme
protocole sous-jacent le protocole UDP ou TCP et permet à un réseau local d’affecter des
noms d’hôte dans son domaine indépendamment des autres domaines. Normalement, le
protocole DOMAIN utilise UDP. Toutefois, si la réponse UDP est tronquée, DOMAIN fait
appel au protocole TCP. Le protocole DOMAIN de TCP/IP prend en charge les deux.
Pour résoudre les noms et adresses Internet, les routines de résolution locales du système
d’appellation hiérarchique DOMAIN peuvent recourir à la base de résolution de noms locale
tenue par le démon named. Si le nom demandé par l’hôte ne figure pas dans cette base, la
routine de résolution interroge un serveur de noms DOMAIN distant. Dans tous les cas, en
cas d’échec, la routine tente d’utiliser le fichier /etc/hosts.
Remarque :
TCP/IP configure les routines de résolution locales pour le protocole
DOMAIN, si le fichier local /etc/resolv.conf existe. Sinon, TCP/IP les
configure pour qu’elles utilisent la base de données /etc/hosts.
TCP/IP implémente le protocole DOMAIN dans le démon named et les routines de
résolution, mais ne lui fournit pas d’interface API.
Protocole EGP
Le protocole EGP (Exterior Gateway Protocol) est le mécanisme qui permet à la
passerelle extérieure d’un système autonome de partager les informations de routage avec
des passerelles extérieures d’autres systèmes autonomes.
Systèmes autonomes
Un système autonome est un groupe de réseaux et de passerelles sous la responsabilité
d’une autorité administrative. Les passerelles sont dites intérieures limitrophes si elles
résident sur le même système autonome et extérieures limitrophes si elles résident sur des
systèmes autonomes différents. Les passerelles qui échangent des informations de routage
via le protocole EGP sont appelées passerelles limitrophes ou homologues EGP.
Le protocole EGP permet aux passerelles de systèmes autonomes d’accéder aux
informations de leurs homologues EGP.
Via EGP, une passerelle extérieure peut demander à échanger des informations d’accès
avec une autre passerelle extérieure. EGP vérifie en permanence que ses passerelles
homologues répondent aux demandes, et les aident dans ces échanges par des messages
de mise à jour de routage.
4-32
Guide de gestion du système – Communications et réseaux
EGP limite la portée d’une passerelle extérieure aux réseaux de destination accessibles en
tous points dans le système autonome de cette passerelle. Autrement dit, une passerelle
extérieure utilisant EGP peut transmettre les informations aux passerelles EGP limitrophes,
mais ne peut fournir des informations concernant ses passerelles limitrophes hors de son
système autonome.
EGP n’interprète aucune distance métrique spécifiée dans les messages de mise à jour de
routage issus d’autres protocoles. EGP utilise la zone de distance pour indiquer si un
chemin existe (la valeur 255 signifiant qu’un réseau est inaccessible). La valeur spécifiée ne
peut pas servir à déterminer le chemin le plus court entre deux routes, sauf si ces dernières
sont situées dans un seul système autonome. C’est pourquoi EGP n’est pas utilisé comme
algorithme de routage. De ce fait, un seul chemin peut être emprunté entre la passerelle
extérieure et un réseau.
Contrairement au protocole RIP (Routing Information Protocol), qui peut être appliqué à
un système autonome de réseaux Internet qui reconfigurent dynamiquement les routes, les
routes EGP sont prédéterminées dans le fichier /etc/gated.conf. EGP considère que IP est
le protocole sous-jacent implicite.
Types de messages EGP
Neighbor Acquisition Request
Demande émise par les passerelles extérieures
pour devenir limitrophes.
Neighbor Acquisition Reply
Réponse favorable des passerelles extérieures
pour devenir limitrophes.
Neighbor Acquisition Refusal
Réponse défavorable des passerelles extérieures
pour devenir limitrophes. Les raisons du refus sont
indiquées dans le message, par exemple
out of table space.
Neighbor Cease
Demande émise par les passerelles extérieures
pour mettre fin à une relation limitrophe. Les
raisons sont indiquées dans le message, par
exemple, going down.
Neighbor Cease Acknowledgment Acceptation par les passerelles extérieures de la
demande d’interruption d’une relation limitrophe.
Neighbor Hello
Message émis par une passerelle limitrophe pour
vérifier qu’une connexion est active. Une passerelle
émet un message Hello et la passerelle
interrogée confirme la connexion en émettant la
réponse I Heard You.
I Heard You
Réponse d’une passerelle extérieure au message
Hello. Le message I Heard You
s’accompagne des informations d’accès à la
passerelle qui émet la réponse et, si la passerelle
est inaccessible, d’un message d’explication, par
exemple
You are unreachable due to problems
with my network interface.
NR Poll
Interrogation émise par les passerelles extérieures
auprès des passerelles limitrophes pour déterminer
leur capacité d’accès aux autres passerelles.
Protocole TCP/IP
4-33
Network Reachability
Réponse des passerelles extérieures au message
NR Poll. Pour chaque passerelle interrogée, le
message Network Reachability indique les
adresses auxquelles la passerelle limitrophe lui
donne accès.
EGP Error
Réponse émise par les passerelles extérieures aux
messages EGP qui présentent des totaux de
contrôle ou des valeurs de zones erronés.
TCP/IP implémente le protocole EGP dans le démon gated mais ne lui fournit pas
d’interface de programmation d’applications (API).
Protocole FTP
Le protocole FTP (File Transfer Protocol) permet le transfert des données entre hôtes
hétérogènes et le transfert indirect de fichiers entre deux hôtes étrangers. Il donne accès à
la liste des répertoires distants, permet de changer de répertoire distant courant, de créer
ou de supprimer des répertoires distants et de transférer plusieurs fichiers en une seule
demande. Un système de protection par mot de passe et numéro de compte utilisateur est
assuré au niveau de l’hôte étranger. Conçu à l’origine pour des applications, FTP est
également utilisé pour les sessions interactives orientées utilisateur.
FTP a recours au transfert fiable de flot (TCP/IP) pour l’envoi des fichiers, et à une
connexion Telnet pour le transfert des commandes et des réponses. FTP reconnaît
plusieurs formats de fichiers de base, notamment NETASCII, IMAGE et Local 8.
TCP/IP implémente FTP dans les commandes ftpet (utilisateur) et ftpd (serveur) mais ne
fournit pas d’interface de programmation d’applications (API) avec ce protocole.
Si vous créez des répertoires et utilisateurs ftp anonymes, veillez à ce que le répertoire
personnel des utilisateurs ftp et anonymes (par exemple, /u/ftp) appartienne à un utilisateur
racine mais ne soit pas accessible en écriture (par exemple, dr–xr–xr–x). Vous pouvez
utiliser le script /usr/samples/tcpip/anon.ftp pour créer ces comptes, fichiers et
répertoires.
Protocole Telnet
Le protocole TELNET fournit une méthode de communication standard pour les terminaux
et process orientés terminal. TELNET est utilisé couramment par les programmes
d’émulation de terminal pour la connexion à un hôte distant. Il sert à la communication de
terminal à terminal et inter–process, et est sollicité par d’autres protocoles (par exemple,
FTP) pour l’établissement d’un canal de contrôle de protocole.
TCP/IP implémente TELNET dans les commandes utilisateur tn, telnet, ou tn3270.
Le démon telnetd ne fournit pas d’interface API pour TELNET.
TCP/IP accepte les options Telnet négociées entre le client et le serveur :
4-34
BINARY TRANSMISSION
(pour sessions tn3270)
Transmet les caractères sous forme de
données binaires.
SUPPRESS GO_AHEAD
(Le système d’exploitation supprime
les options GO–AHEAD.)
Lors de la transmission de données, à la
demande de l’expéditeur des données, ne
transmet pas au destinataire d’option
GO_AHEAD. Si cette option n’est pas
acceptée, les interlocuteurs suppriment la
connexion dans les deux directions. Cette
action doit être exécutée de manière autonome
dans les deux directions.
TIMING MARK (Reconnue mais reçoit
une réponse négative)
Vérifie que les données transmises ont été
entièrement traitées.
Guide de gestion du système – Communications et réseaux
EXTENDED OPTIONS LIST
Fournit la possibilité de 256 options
supplémentaires à la liste des options TELNET.
Sans cette option, TELNET admet un
maximum de 256 options.
ECHO (Commande modifiable par
l’utilisateur)
Transmet les caractères d’écho déjà renvoyés
à l’expéditeur d’origine.
TERM TYPE
Permet au serveur de déterminer le type de
terminal connecté à un programme utilisateur
TELNET.
SAK (Secure Attention Key)
Sécurise la communication entre vous et le
système.
NAWS (Negotiate About Window Size)
Dans une relation client–serveur, permet aux
deux parties de négocier la taille de la fenêtre
(si les applications l’autorisent).
Remarque :
Telnet doit autoriser la transmission de caractères 8 bits en mode non
binaire pour l’implémentation de la page de code ISO 8859 Latin. Cette
condition est nécessaire pour l’internationalisation des commandes TCP/IP.
Protocole TFTP
Le protocole TFTP (Trivial File Transfer Protocol) peut lire et enregistrer des fichiers issus
de ou destinés à un hôte distant. TFTP est généralement plus rapide que FTP car, pour
acheminer les fichiers, il fait appel au protocole UDP qui ne garantit pas la livraison des
fichiers. Comme FTP, TFTP peut traiter les fichiers sous forme de données NETASCII ou
binaires 8 bits. En revanche, il ne permet pas de lister ou de modifier les répertoires d’un
hôte distant et ne prévoit pas de protection de type mot de passe. De plus, sous TFTP,
l’écriture et la recherche des données sont limitées aux répertoires publics.
TCP/IP implémente TFTP dans les commandes utilisateur tftp et utftp, et dans la
commande serveur tftpd. La commande utftp est une variante de la commande tftp
utilisable dans les chaînages (pipes). TCP/IP ne fournit pas d’interface API pour le protocole
FINGER.
Pour plus d’informations, reportez–vous à la description de la commande tftp ou utftp
ainsi qu’à la description du démon tftpd dans Références de commande AIX 5L
Version 5.3, Volume 5.
Protocole FINGER
Le Name/Finger Protocol (FINGER) est un protocole Internet de niveau application qui
joue le rôle d’interface entre la commande finger et le démon fingerd. Le démon fingerd
renvoie les informations sur les utilisateurs connectés à un hôte distant spécifique. Pour
limiter la commande à un utilisateur donné, spécifiez–le (commande finger). Le protocole
FINGER doit être disponible sur l’hôte à distance et sur l’hôte demandeur. FINGER utilise
le Protocole TCP ( Transmission Control Protocol, page 4-28) comme son protocole
sous–jacent.
Remarque :
TCP/IP ne fournit pas d’interface API pour ce protocole.
Pour plus d’informations, reportez–vous à la description de la commande finger ainsi qu’à
la description du démon fingerd dans AIX 5L Version 5.3 Commands Reference, Volume 2.
Protocole TCP/IP
4-35
Protocole HELLO
Le Local–Network Protocol (HELLO) s’applique aux passerelles intérieures et doit être
utilisé dans des systèmes autonomes. (Pour plus d’informations, reportez–vous aux
Systèmes autonomes, page 4-32.) HELLO est chargé de tenir à jour les informations de
connectivité, de routage et d’horloge. Il permet à chaque machine de trouver le chemin le
plus rapide vers la destination et met à jour dynamiquement l’information de routage vers
cette destination.
Ce protocole est fourni par le démon gated. Pour plus d’informations, reportez–vous à la
description du démon gated dans Référence de commandes AIX 5L Version 5.3, Volume 2.
Protocole d’exécution de commande à distance
Le protocole d’exécution à distance, fourni par la commande utilisateur rexec et le démon
rexecd, permet de lancer des commandes sur un hôte distant compatible. Pour plus
d’informations, reportez–vous à la description de la commande rexec ainsi qu’à la
description du démon rexecd dans AIX 5L Version 5.3 Commands Reference, Volume 4.
Protocole d’ouverture de session à distance
La commande utilisateur rlogin et le démon rlogind fournissent le protocole de
connexion à distance, permettant aux utilisateurs de se connecter à un hôte distant et
d’utiliser leur terminal comme s’ils étaient connectés directement à cet hôte. Pour plus
d’informations, reportez–vous à la description de la commande rlogin ainsi qu’à la
description du démon rlogind dans AIX 5L Version 5.3 Commands Reference, Volume 4.
Protocole SHELL
La commande utilisateur rsh et le démon rshd fournissent le protocole de commande
SHELL à distance, permettant aux utilisateurs d’ouvrir un shell sur un hôte étranger
compatible pour y exécuter des commandes. Pour plus d’informations, reportez–vous à la
description de la commande rsh ainsi qu’au démon rshd dans AIX 5L Version 5.3
Commands Reference, Volume 4.
Protocole Wake On LAN (WOL)
Wake On LAN (WOL) vous permet de réveiller un ou plusieurs hôtes connectés à un réseau
en mode suspendu en envoyant un Magic Packet à l’/aux adresse(s) indiquée(s) sur le
sous–réseau spécifié.
Pour plus d’informations sur l’utilisation du WOL, reportez–vous à la description de la
commande wol dans AIX 5L Version 5.3 Commands Reference, Volume 6.
Protocole RIP
Le protocole de routage RIP Routing Information Protocol (RIP) et les démons routed et
gated qui le mettent en œuvre, sont chargés de suivre les informations de routage en
fonction du nombre de bonds effectués et de tenir à jour les entrées de la table de routage
du noyau. Pour plus d’informations, reportez–vous aux descriptions du démon routed et
gated dans AIX 5L Version 5.3 Commands Reference.
4-36
Guide de gestion du système – Communications et réseaux
protocole TIMED
Le démon timed est chargé de la synchronisation horaire des hôtes. Il est fondé sur le
concept de client/serveur. Pour plus d’informations, reportez–vous à la description de la
commande timedc ainsi qu’à la description du démon timed dans AIX 5L Version 5.3
Commands Reference, Volume 5.
Nombres réservés
Dans un souci de compatibilité avec l’environnement de réseau général, des nombres
connus sont attribués aux versions, réseaux, ports, protocoles et options de protocoles
Internet, de même qu’aux machines, réseaux, systèmes d’exploitation, protocoles,
services et terminaux. TCP/IP applique les numéros et noms définis par la norme
RFC 1010, Nombres réservés.
Le Protocole Internet (IP)définit un champ de 4 bits dans l’en–tête IP pour identifier la
version du protocole interréseau utilisé. Le numéro de version d’IP en décimal est 4. Pour
plus d’informations sur les nombres et noms réservés de TCP/IP, reportez–vous aux fichiers
/etc/protocols et /etc/services inclus dans TCP/IP. Pour plus d’informations sur les
nombres et les noms réservés, reportez–vous à la RFC 1010 ainsi qu’au fichier
/etc/services.
Protocole TCP/IP
4-37
Cartes de réseau local (LAN) TCP/IP
Cette section traite des points suivants :
• Installation d’une carte réseau, page 4-38
•
Configuration et gestion des cartes, page 4-39
• Configuration et utilisation des réseaux locaux virtuels (VLAN), page 4-40
• Utilisation des cartes ATM, page 4-42
La carte réseau est le dispositif matériel raccordé physiquement aux câbles du réseau.
Elle est chargée de recevoir et de transmettre les données au niveau physique. Elle est
contrôlée par le pilote de carte.
Chaque machine doit être équipée d’autant de cartes réseau (ou connexions) que de
réseaux auxquels elle est connectée. Par exemple, si un hôte est raccordé à deux réseaux
en anneau à jeton, il doit être équipé de deux cartes réseau.
TCP/IP utilise les cartes réseau et connexions suivantes :
• Ethernet standard version 2
• IEEE 802.3
• Anneau à jeton
• Cartes asynchrones et ports série natifs
• Interface FDDI (Fiber Distributed Data Interface)
• Convertisseur de canal optique série (décrit dans AIX 5L Version 5.3 Kernel Extensions
and Device Support Programming Concepts)
• ATM (mode de transfert asynchrone)
• Fibre Channel
Les technologies de réseau Ethernet et 802.3 utilisent le même type de carte.
Chaque machine offre un nombre limité d’emplacements d’extension, que vous pouvez
utiliser pour les cartes de communication. En outre, chaque machine ne prend en charge
qu’un nombre limité de cartes de communication d’un type donné : Dès lors, vous pouvez
installer sur votre machine n’importe quelle combinaison de cartes en respectant les
contraintes logicielles (nombre et type de carte) et matérielles (nombre total
d’emplacements d’extension disponibles).
Une seule interface TCP/IP doit être configurée, quel que soit le nombre de convertisseurs
optiques série pris en charge par le système. Le pilote d’unité Optique série exploite les
deux convertisseurs de canal même si une seule interface logique TCP/IP est configurée.
Installation d’une carte réseau
Pour installer une carte réseau :
1. Arrêtez l’ordinateur. Pour l’arrêt système, reportez-vous à la commande shutdown.
2. Mettez la machine hors tension.
3. Déposez le capot de l’ordinateur.
4. Recherchez un connecteur libre et insérez la carte réseau.
Veillez à enclencher correctement la carte dans le connecteur.
5. Remettez le capot de l’ordinateur.
6. Relancez l’ordinateur.
4-38
Guide de gestion du système – Communications et réseaux
Configuration et gestion des cartes
Pour configurer et gérer les cartes pour réseau en anneau à jeton ou Ethernet,
suivez les procédures du tableau suivant.
Configuration et gestion des tâches relatives aux cartes
Tâche
Raccourci SMIT
Commande ou fichier
Web-based
System
Manager
Management
Environment5
Configuration
d’une carte
smit chgtok
1.Recherchez le nom de la carte :1
(anneau à jeton)
smit chgenet
lsdev –C –c adapter –t to
(Ethernet)
kenring –H
ou
lsdev –C –c adapter –t et
hernet –H
2.Redéfinissez la vitesse de
l’anneau (anneau à jeton) ou le
type de connecteur (Ethernet), si
nécessaire. Par exemple :
chdev –l tok0 –a ring_spe
ed=16 –P
ou
chdev –l ent0 –a bnc_sele
ct=dix –P
Détermination
de l’adresse
matérielle de la
carte réseau
smit chgtok
lscfg –l tok0 –v (token ring)2
(anneau à jeton) lscfg –l ent0 –v (Ethernet)2
smit chgenet
(Ethernet)
Définition d’une
adresse
matérielle
secondaire
smit chgtok
1.Définissez l’adresse matérielle
(anneau à jeton) secondaire. Par exemple, pour
smit chgenet
anneau à jeton : 2,3
(Ethernet)
chdev –l tok0 –a alt_add
r=0X10005A4F1B7F
Pour Ethernet : 2,3
chdev –l ent0 –a alt_addr
=0X10005A4F1B7F –p
2.Commencez à utiliser l’adresse
secondaire, pour anneau à jeton :
4
chdev –l tok0 –a use_alt_
addr=yes
Pour Ethernet : 4
chdev –l ent0 –a use_alt_
addr=yes
Protocole TCP/IP
4-39
Remarques :
1. Le nom de la carte réseau peut changer si vous l’installez à un autre emplacement ou
que vous la retirez du système. Dans ce cas, veillez à mettre à jour la base de données
de configuration via la commande diag –a.
2. Indiquez le nom de votre carte à la place de tok0 et ent0.
3. Remplacez par l’adresse matérielle 0X10005A4F1B7F.
4. Une interruption de communication peut se produire après cette opération jusqu’à ce
que les hôtes vident leur mémoire cache ARP et enregistrent cette nouvelle adresse
matérielle.
5. Ces tâches ne sont pas disponibles dans Web-based System Manager Management
Environment.
Configuration et utilisation des réseaux locaux virtuels (VLAN)
Les réseaux VLAN (Virtual Local Area Networks) ont une structure de type domaine de
diffusion logique. Un réseau VLAN divise les groupes d’utilisateurs d’un réseau physique
réel en segments de réseaux logiques. Cette mise en œuvre prend en charge la norme de
repérage VLAN IEEE 802.1Q, ainsi que la fonction de prise en charge de plusieurs ID VLAN
exécutés sur des cartes Ethernet. Chaque ID VLAN est associé aux couches supérieures
(IP, etc.) grâce à une interface Ethernet distincte, et crée une entité logique de carte
Ethernet par réseau VLAN, par exemple ent1, ent2 et ainsi de suite.
IEEE 802.1Q de VLAN peut être configurée pour n’importe quelle carte Ethernet prise en
charge. Les cartes doivent être connectées à un commutateur qui prend en charge la
norme IEEE 802.1Q de VLAN.
Vous pouvez configurer plusieurs unités logiques VLAN sur un seul système. Chaque unité
logique VLAN constitue une entité de carte Ethernet supplémentaire. Ces unités logiques
peuvent être utilisées pour configurer les mêmes interfaces IP Ethernet telles qu’elles sont
utilisées avec les cartes physiques Ethernet. Par conséquent, vous devez augmenter la
valeur de l’option ifsize de la commande no (dont la valeur par défaut est 8), pour inclure
les interfaces Ethernet pour chaque carte, mais également toutes les unités logiques VLAN
configurées. Reportez–vous à la documentation de la commande no.
A chaque VLAN, vous pouvez associer une valeur différente de MTU (unité de transmission
maximum) même si vous partagez une carte Ethernet physique individuelle.
La prise en charge de VLAN est gérée par SMIT. A partir de la ligne de commande, tapez le
raccourci smit vlan et sélectionnez les éléments appropriés dans le menu principal de
VLAN. Vous pouvez également recourir à l’aide en ligne.
Après la configuration de VLAN, configurez l’interface IP (par exemple, en1 pour Ethernet
standard ou et1 pour IEEE 802.3), à l’aide de Web-based System Manager, de SMIT ou
des commandes.
AIX 5.3 et les versions supérieures prennent en charge un réseau Ethernet virtuel E/S via
un commutateur E/S virtuel en tant que méthode de communication en mémoire inter
partitions au sein d’un système POWER5. Le commutateur prend également en charge le
repérage IEEE 802.1Q, ce qui permet aux cartes Ethernet virtuelles d’appartenir à différents
réseaux locaux virtuels sur le commutateur. La console HMC permet de créer et de
configurer les cartes Ethernet virtuelles. Une fois créée, la partition voit la carte Ethernet
virtuelle sur l’arborescence ouverte du micrologiciel en recherchant les périphériques. Après
sa détection, la carte Ethernet virtuelle est configurée et utilisée comme une carte physique
Ethernet. Pour plus d’informations, reportez–vous à la documentation matérielle de votre
système POWER5.
4-40
Guide de gestion du système – Communications et réseaux
Remarques :
1. Si vous tentez de configurer une valeur ID de VLAN alors qu’il est en cours d’utilisation
par la carte spécifiée, la configuration échoue et le message d’erreur suivant s’affiche :
Method error (/usr/lib/methods/chgvlan):
0514–018 The values specified for the following attributes
are not valid:
vlan_tag_id ID indicateur VLAN
2. Si un utilisateur (l’interface IP par exemple) utilise actuellement l’unité logique VLAN,
toute tentative de retirer l’unité logique VLAN échoue. Un message similaire à l’exemple
suivant s’affiche :
Method error (/usr/lib/methods/ucfgcommo):
0514–062 Cannot perform the requested function because the
specified device is busy.
Pour retirer l’unité VLAN logique, détachez d’abord l’utilisateur. Par exemple, si
l’utilisateur est l’interface IP en1, vous pouvez utiliser la commande suivante :
ifconfig en1 detach
Ensuite, retirez l’interface de réseau à l’aide des menus TCP/IP de SMIT.
3. Si un utilisateur (l’interface IP par exemple) utilise actuellement l’unité logique VLAN,
toute tentative de modifier les caractéristiques VLAN (ID indicateur VLAN ou carte de
base) échoue. Un message similaire à l’exemple suivant s’affiche :
Method error (/usr/lib/methods/chgvlan):
0514–062 Cannot perform the requested function because the
specified device is busy.
Pour modifier l’unité VLAN logique, détachez d’abord l’utilisateur. Par exemple, si
l’utilisateur est l’interface IP en1, vous pourriez utiliser la commande suivante :
ifconfig en1 detach
Ensuite, modifiez le VLAN et ajoutez de nouveau l’interface de réseau à l’aide des
menus TCP/IP de SMIT.
Identification des incidents
Pour identifier les incidents relatifs à VLAN, vous pouvez utiliser tcpdump et trace. Le
tableau suivant décrit l’ID du suivi d’erreur pour chaque type de paquet de transmission :
paquets de transmission
3FD
paquets de réception
3FE
autres événements
3FF
La commande entstat affiche les valeurs totales des statistiques de la carte physique pour
laquelle VLAN est configuré. Elle ne fournit pas les statistiques individuelles de l’unité
logique VLAN spécifique.
Restrictions
Le cliché à distance n’est pas pris en charge avec un VLAN. De plus, vous ne pouvez pas
utiliser les unités logiques VLAN pour créer un Etherchannel Cisco Systems.
Protocole TCP/IP
4-41
Utilisation de cartes ATM
La norme internationale ATM (Asynchronous Transfer Mode) définit une méthode de
transmission à grande vitesse pour le transport d’éléments mixtes composés d’audio, vidéo,
et de données informatiques ordinaires sur des réseaux locaux, métropolitains et longue
distance (LAN, MAN et WAN). Les cartes ATM offrent une connectivité en duplex intégral
pour les serveurs ESCALA ou pour les clients qui utilisent des circuits virtuels permanents
(PVC) et des circuits virtuels commutés (SVC). Les mises en œuvre PVC et SVC sont
conformes aux spécifications ATM Forum. Le nombre maximum de circuits virtuels pris en
charge varie selon la carte. La plupart des cartes prennent en charge un minimum de 1024
circuits virtuels.
Technologie ATM
ATM (Asynchronous Transfer Mode) est une technologie de commutation de cellules,
orientée connexion. Sur un réseau ATM, les terminaux sont raccordés au réseau via des
connexions en duplex intégral dédiées. Les réseaux ATM sont construits sur la base de
commutateurs interconnectés par des connexions physiques dédiées. Pour que le transfert
de données puisse avoir lieu, des connexions de bout en bout doivent être établies. Une
interface physique unique peut assurer des connexions multiples. Les stations émettrices
transmettent les données en segmentant les unités PDU (Protocol Data Unit) en cellules de
53-octets. La charge est maintenue sous forme de cellules lors du transport sur le réseau.
C’est au niveau des stations réceptrices que les cellules sont réassemblées en PDU. Les
connexions sont identifiées par un identificateur de chemin virtuel (VPI) et un identificateur
de canal virtuel (VCI). Le champ VPI occupe 1 octet dans l’en–tête de 5 octets de la cellule
ATM ; tandis que le champ VCI occupe 2 octets dans l’en–tête de 5 octets de la cellule
ATM. En d’autres termes, une paire VPI:VCI identifie la source de la cellule ATM. Le
commutateur ATM a pour fonction d’identifier l’origine de la cellule, de déterminer le saut
suivant et de diriger la cellule vers un port. La paire VPI:VCI change sur une base saut par
saut. Aussi les valeurs VPI:VCI ne sont-elles pas universelles. Un circuit virtuel est décrit
par la concaténation de valeurs VPI:VCI à travers le réseau.
4-42
Guide de gestion du système – Communications et réseaux
Connexions ATM
Dans l’architecture ATM, il existe deux types de circuits virtuels : permanent (PVC) et
commuté (SVC).
Circuits virtuels
permanents (PVC)
La configuration des PVC est statique et manuelle. Les
commutateurs composant le réseau ATM doivent être
configurés au préalable de façon à reconnaître la
combinaison VPI:VCI de chaque terminal et à acheminer
les cellules ATM de ces points via le réseau ATM. Après
l’établissement d’une liaison de réseau entre deux points
d’extrémité, les cellules ATM peuvent être transmises à
travers le réseau ATM et les commutateurs ATM. Pour
pouvoir acheminer la cellule vers sa destination, les
commutateurs de réseau doivent convertir les valeurs
VPI:VCI de manière appropriée.
Circuits virtuels
commutés (SVC)
Les SVC sont configurés dynamiquement, sur la base des
besoins. Les terminaux ATM sont affectés d’adresses de
20-octets. Deux concepts entrent en jeu : le panneau de
contrôle et le panneau de données. Le panneau de contrôle
utilise une paire de canaux de signalisation VPI:VCI 0:5.
Les SVC initient sur demande une configuration d’appel,
permettant à une station ATM d’envoyer des éléments
d’information spécifiant l’adresse ATM de destination
(et, éventuellement, l’adresse ATM source). Généralement,
la station appelante, le réseau et la station appelée
interviennent dans la négociation. Finalement, un appel est
soit accepté, soit rejeté. S’il est accepté, le réseau affecte
des valeurs VPI:VCI au panneau de données des deux
stations (appelante et appelée). Sur le panneau de contrôle,
le réseau ATM achemine (ou commute) les paquets de
signaux sur la base des adresses ATM. Pendant le routage
de ces paquets, les commutateurs définissent les tables de
routage des cellules du panneau de données. Sur le
panneau de données, les réseaux ATM commutent les
cellules sur la base des VPI:VCI, presque comme dans le
cas des PVC. A la fin du transfert, la connexion est close.
L’adresse ATM est construite par enregistrement sur le réseau ATM et acquisition des
13 octets les plus significatifs. Les 6 octets suivants correspondent à l’adresse matérielle
“gravée” dans la carte. L’octet le moins important est le sélecteur ; son utilisation est laissée
à la discrétion de l’utilisateur. Les réseaux ATM n’interprètent pas cet octet.
Protocole TCP/IP
4-43
TCP/IP sur ATM
Les normes de Internet Engineering Task Force RFC1577, Classical IP et ARP, spécifient
le mécanisme d’implémentation d’IP sur ATM. ATM étant une technologie orientée
connexion et IP une technologie orientée datagramme, le mappage IP-ATM n’est pas
évident.
Un réseau ATM est le plus souvent réparti en sous–réseaux IP logiques (LIS). Chacun est
composé d’un certain nombre de stations ATM. Les LIS présentent des analogies avec les
segments LAN classiques. Les LIS sont interconnectés par des routeurs. Une carte donnée
(sur une station ATM) peut faire partie de plusieurs LIS. Cette fonction est très utile pour la
mise en œuvre de routeurs.
RFC1577 spécifie RFC1483 qui spécifie LLC/SNAP Encapsulation comme valeur par
défaut. Dans les réseaux PVC, pour chaque station IP, tous les PVC doivent être définis
manuellement, par configuration des valeurs VPI:VCI. Si l’encapsulage LLC/SNAP n’est pas
utilisé, l’adresse IP de destination associée à chaque VPI:VCI doit être définie.
Si l’encapsulage LLC/SNAP est utilisé, la station IP peut connaître l’adresse IP distante par
le biais d’un mécanisme InARP. Pour les réseaux SVC, RFC1577 spécifie un serveur ARP
pour chaque LIS. L’objet de ce serveur est de convertir les adresses IP en adresses ATM
sans utiliser de messages de diffusion. Chaque station IP est configurée avec l’adresse
ATM du serveur ARP. Les stations IP configurent les SVC avec le serveur ARP, lequel, à
son tour, envoie les demandes InARP aux stations IP. Sur la base de la réponse InARP, un
serveur ARP configure IP en mappes d’adresses ATM. Les stations IP envoient les paquets
ARP au serveur ARP pour convertir les adresses, lequel renvoie les adresses ATM.
Les stations IP configurent ensuite un SVC vers la station de destination, et le transfert des
données démarre. Les entrées ARP dans les stations IP et le serveur ARP sont fondées sur
un mécanisme bien défini. Pour l’environnement PVC comme pour l’environnement SVC,
chaque station IP dispose d’au moins un circuit virtuel par adresse de destination.
La norme Internet Engineering Task Force RFC2225 remplace la norme RFC1577 et
s’attache principalement au support de la liste des adresses de requêtes ATM ARP. Cette
liste contient une ou plusieurs adresses ATM de serveurs ATM ARP situés au sein du LIS.
Le client RFC2225 supprime le point d’échec individuel associé aux services ATM ARP du
client 1577. Les clients 2225 ont la possibilité de commuter sur les serveurs ARP de
secours en cas d’échec du serveur actuel ATM ARP.
ESCALA définit la première entrée de la liste d’adresses des requêtes ATM ARP comme
le serveur ATM ARP principal, les autres étant définies comme des serveurs ATM ARP
secondaires.
Le client essaie toujours d’utiliser le serveur ATM ARP principal. En cas d’échec de
connexion à ce serveur, le client essaie de se connecter au premier serveur secondaire
(la position dans la liste d’adresses des requêtes ATM ARP détermine l’ordre de celui–ci).
En cas d’échec de la connexion au premier serveur ATM ARP secondaire, le client essaie
de se connecter au serveur ATM ARP secondaire suivant de la liste, et ainsi de suite. Ce
processus continue jusqu’à ce que la connexion aboutisse.
En cas d’échec de connexion au serveur ATM ARP principal, indépendamment du serveur
ATM ARP secondaire auquel il est connecté ou tente de se connecter, le client fait, toutes
les 15 minutes, une nouvelle tentative de connexion au serveur principal ATM ARP. En cas
de réussite, la connexion au serveur ATM ARP secondaire est abandonnée.
La liste d’adresses des requêtes ATM ARP est saisie manuellement à l’aide du menu SMIT
ou de la commande ifconfig. Cette liste ne peut pas être configurée avec la MIB
(Management Information Base).
Réseau PVC
Utilisez la Figure 15, page 4-45 comme exemple de configuration pour votre réseau.
Dans la figure Réseau ATM type, un sous–réseau IP logique est représenté par des lignes
de pointillés, reliant chaque hôte au commutateur. L’autre sous-réseau IP est représenté par
des traits pleins.
4-44
Guide de gestion du système – Communications et réseaux
Figure 15. Réseau ATM représentatif Cette illustration représente un réseau ATM typique
en étoile. Au centre de l’étoile se trouve le commutateur ATM. Des hôtes IP numérotés
partent du commutateur ainsi que des liaisons vers d’autres commutateurs ATM et un
boîtier de passerelle et un adaptateur ATM.
Hôte
non AIX
Vers autres
commutateurs ATM
Hôte
H6
Hôte
H1
Commutateurs
ATM
Hôte
H2
Hôte
H3
Hôte
H5
Deux adresses IP
partageant le même
câble (fibre) physique
Hôte
H4
Boîtier passerelle ATM avec
carte ATM TURBOWAYS 155
Le tableau suivant indique comment configurer les hôtes H3 et H4 pour qu’ils puissent
communiquer avec une passerelle et avec chaque hôte sur leur propre réseau IP logique.
Configuration type d’un hôte
Pilote d’interface réseau
VPI:VCI
Observations
at0
0:40
Connexion à 128.10.1.5 (passerelle)
at0
0:42
Connexion à 128.10.1.2
at0
0:43
Connexion à 128.10.1.3
at0
0:50
Connexion à 128.10.2.5 (passerelle)
at0
0:52
Connexion à 128.10.2.2
at0
0:53
Connexion à 128.10.2.3
at0
0:54
Connexion à 128.10.2.4
Hôte H3
Hôte H4
Protocole TCP/IP
4-45
Pour atteindre les hôtes d’un autre sous–réseau IP logique, il suffit de créer une connexion
VPI:VCI à la passerelle (les VPI:VCI indiqués sont de simples exemples).
Le boîtier de la passerelle ATM est équipé d’un ATM avec deux adresses IP partageant le
même câble physique.
Réseau SVC
A l’aide de la Figure 16 page 4-46 en guise d’exemple, imaginez que l’hôte H3 veut appeler
l’hôte H4. H1 est le serveur ARP du sous–réseau 1 et H6, celui du sous–réseau 2. En
supposant que le masque de sous–réseau est 255.255.255.0, les stations ayant les
adresses 128.10.1.X sont membres d’un sous–réseau, tandis que les stations ayant les
adresses 128.10.2.X sont membres d’un autre sous–réseau. Reportez–vous à la liste des
configurations hôte représentatives à l’aide des SVC.
Figure 16. Réseau ATM représentatif Cette illustration représente un réseau ATM typique
en étoile. Au centre de l’étoile se trouve le commutateur ATM. Des hôtes IP numérotés
partent du commutateur ainsi que des liaisons vers d’autres commutateurs ATM et un
boîtier de passerelle et un adaptateur ATM.
Hôte
non AIX
Vers autres
commutateurs ATM
Hôte
H6
Hôte
H1
Commutateurs
ATM
Hôte
H2
Hôte
H3
Hôte
H5
Deux adresses IP
partageant le même
câble (fibre) physique
Hôte
H4
Boîtier passerelle ATM avec
carte ATM TURBOWAYS 155
4-46
Guide de gestion du système – Communications et réseaux
Liste de configurations type d’hôte
Pilote
d’interface
réseau
Adresse IP
Serveur ARP
Adresse du
serveur ARP
128.10.1.3
Oui
128.10.1.1
Non
Adresse ATM
de H1
at0
128.10.1.5
Non
Adresse ATM
de H1
at1
128.10.2.5
Non
Adresse ATM
de H6
128.10.2.1
Non
Adresse ATM
de H6
128.10.2.3
Oui
Adresse
passerelle
Hôte H1
at0
128.10.1.5
Hôte H3
at0
128.10.1.5
Passerelle
Hôte H4
at0
128.10.2.5
Hôte H6
at0
128.10.2.5
Remarque : Chaque sous–réseau requiert un et un seul serveur ARP.
H3 identifiant que l’adresse 128.10.2.1 ne se trouve pas sur son sous-réseau, consulte H1
pour convertir l’adresse IP de la passerelle par défaut en adresse ATM. H3 lance ensuite un
appel à la passerelle. La passerelle identifie que les données sont associées au second
sous-réseau et consulte H6 pour convertir effectivement l’adresse IP de H4 en adresse
ATM. Des connexions sont ensuite établies entre H3 et la passerelle, et entre la passerelle
et H4.
Configuration d’une carte ATM
Pour configurer la carte ATM, utilisez Web-based System Manager, la commande wsm ou
le raccourci SMIT smit chg_atm. Sélectionnez un nom de carte, puis avec l’aide en ligne et
les listes à choix multiples, décidez des modifications à apporter à votre configuration.
Statistiques sur la carte ATM
La commande atmstat permet d’obtenir des statistiques sur la carte ATM. Assortie de
l’indicateur –r, elle remet les statistiques à zéro. Son format est atmstat NomUnité. Elle
renvoie les ensembles de statistiques suivants :
Statistiques de transmission
Packets :
Nombre de paquets (ou de PDU) transmis.
Bytes :
Décompte des octets transmis. Ils représentent les octets de l’utilisateur.
La charge ATM (par exemple, en-tête de cellule ATM, en-queue AAL5 PDU,
etc.) est exclue.
Interrupts :
Champ non utilisé.
Transmit Errors :
Nombre d’erreurs de transmission pour l’unité.
Packets Dropped :
Nombre de paquets de transmission abandonnés, suite, par exemple, à un
incident sur le tampon.
Protocole TCP/IP
4-47
Max Packets on S/W Transmit Queue :
Champ non applicable à ATM.
S/W Transmit Queue Overflow :
Champ non applicable à ATM.
Current S/W + H/W Transmit Queue Length :
Longueur de la file d’attente de transmission courante.
Cells Transmitted :
Nombre de cellules transmises par cette unité.
Out of Xmit Buffers :
Nombre de paquets de transmission abandonnés, suite à un incident sur
les tampons Xmit.
Current HW Transmit Queue Length :
Nombre courant de paquets de transmission sur la file d’attente matérielle.
Current SW Transmit Queue Length :
Champ non applicable à ATM.
Statistiques de réception
Packets :
Nombre de paquets (ou de PDU) reçus.
Bytes :
Décompte des octets reçus. Ils représentent les octets de l’utilisateur.
La charge ATM (par exemple, en-tête de cellule ATM, en-queue AAL5 PDU,
etc.) est exclue.
Interrupts :
Nombre d’interruptions effectuées par le système pour les indications
carte-vers-système. Parmi les événements susceptibles de provoquer ces
interruptions, citons des paquets reçus, des indications de transmission
effectuée, etc.
Receive Errors :
Nombre d’erreurs de réception pour cette unité.
Packets Dropped :
Nombre de paquets de réception abandonnés, suite par exemple à un
incident sur les tampons.
Bad Packets :
Champ non applicable à ATM.
Cells Received :
Nombre de cellules reçues par cette unité.
Out of Rcv Buffers :
Nombre de paquets abandonnés, suite à un incident sur les tampons de
réception.
CRC Errors :
Nombre de paquets reçus ayant rencontré des erreurs CRC.
Packets Too Long :
Nombre de paquets reçus, qui excédaient la taille maximale du PDU.
Incomplete Packets :
Nombre de paquets incomplets reçus.
Cells Dropped :
Nombre de cellules abandonnées. Les raisons de l’abandon des cellules
sont diverses ; incident au niveau de l’en–tête (HEC), tampon saturé, etc.
4-48
Guide de gestion du système – Communications et réseaux
Statistiques générales
No mbuf Errors :
Nombre de requêtes mbuf refusées.
Adapter Loss of Signals :
Nombre de pertes de signal rencontrées par la carte.
Adapter Reset Count :
Nombre de réinitialisations effectuées sur la carte.
Driver Flags: Up Running Simplex :
Indicateurs NDD.
Virtual Connections in use :
Nombre de VC actuellement alloués ou en cours d’utilisation.
Max Virtual Connections in use :
Nombre maximal de VC alloués depuis la dernière remise à zéro des
statistiques.
Virtual Connections Overflow :
Nombre de demandes d’allocation de VC refusées.
SVC UNI Version :
Version UNI courante du protocole de signalisation utilisé.
Statistiques ATM Micro Channel complémentaires
Pour des statistiques détaillées, lancez la commande atmstat assortie de l’indicateur –d.
Turboways ATM Adapter Specific Statistics:
Packets Dropped - No small DMA buffer :
Nombre de paquets de réception abandonnés suite à l’absence de petits
tampons système pour DMA sur la carte.
Packets Dropped - No medium DMA buffer :
Nombre de paquets de réception abandonnés suite à l’absence de
tampons système moyens pour DMA sur la carte.
Packets Dropped – No large DMA buffer :
Nombre de paquets de réception abandonnés suite à l’absence de grands
tampons système pour DMA sur la carte.
Receive Aborted – No Adapter Receive buffer :
Nombre de paquets de réception abandonnés suite à l’absence de
tampons de réception sur la carte.
Transmit Aborted – No small DMA buffer :
Nombre de paquets de transmission abandonnés suite à l’absence de
petits tampons système pour DMA.
Transmit Aborted – No medium DMA buffer :
Nombre de paquets de transmission abandonnés suite à l’absence de
tampons système moyens pour DMA.
Transmit Aborted – No large DMA buffer :
Nombre de paquets de transmission abandonnés suite à l’absence de
grands tampons système pour DMA.
Transmit Aborted – No MTB DMA buffer :
Nombre de paquets de transmission abandonnés suite à l’absence de
grands tampons système pour DMA.
Transmit Aborted – No Adapter Transmit buffer :
Nombre de paquets de transmission abandonnés suite à l’absence de
tampons de transmission sur la carte.
Protocole TCP/IP
4-49
Max Hardware Transmit Queue Length :
Nombre maximal de paquets de transmission en attente dans la file
matérielle.
Small Mbufs in Use :
Nombre de petits tampons en cours d’utilisation. Le pilote d’unité de carte
alloue ces tampons en fonction des données de configuration fournies par
les administrateurs système. Cette information peut servir à affiner les
données de configuration.
Medium Mbufs in Use :
Nombre de tampons moyens en cours d’utilisation. Le pilote d’unité de
carte alloue ces tampons en fonction des données de configuration fournies
par les administrateurs système. Cette information peut servir à affiner les
données de configuration.
Large Mbufs in Use :
Nombre de grands tampons en cours d’utilisation. Le pilote d’unité de carte
alloue ces tampons en fonction des données de configuration fournies par
les administrateurs système. Cette information peut servir à affiner les
données de configuration.
Huge Mbufs in Use :
Nombre de très grands tampons en cours d’utilisation. Le pilote d’unité de
carte alloue ces tampons en fonction des données de configuration fournies
par les administrateurs système. Cette information peut servir à affiner les
données de configuration.
MTB Mbufs in Use :
Nombre de tampons MTB en cours d’utilisation. Le pilote d’unité de carte
alloue ces tampons en fonction des données de configuration fournies par
les administrateurs système. Cette information peut servir à affiner les
données de configuration.
Max Small Mbufs in Use :
Nombre maximal de petits tampons qui ont été utilisés. Le pilote d’unité de
carte alloue ces tampons en fonction des données de configuration fournies
par les administrateurs système. Cette information peut servir à affiner les
données de configuration.
Max Medium Mbufs in Use :
Nombre maximal de tampons moyens qui ont été utilisés. Le pilote d’unité
de carte alloue ces tampons en fonction des données de configuration
fournies par les administrateurs système. Cette information peut servir à
affiner les données de configuration.
Max Large Mbufs in Use :
Nombre maximal de grands tampons qui ont été utilisés. Le pilote d’unité
de carte alloue ces tampons en fonction des données de configuration
fournies par les administrateurs système. Cette information peut servir à
affiner les données de configuration.
Max Huge Mbufs in Use :
Nombre maximal de très grands tampons qui ont été utilisés. Le pilote
d’unité de carte alloue ces tampons en fonction des données de
configuration fournies par les administrateurs système. Cette information
peut servir à affiner les données de configuration.
MTB Mbufs in Use :
Nombre maximal de tampons MTB qui ont été utilisés. Le pilote d’unité de
carte alloue ces tampons en fonction des données de configuration fournies
par les administrateurs système. Cette information peut servir à affiner les
données de configuration.
4-50
Guide de gestion du système – Communications et réseaux
Small Mbufs overflow :
Nombre de fois qu’un petit tampon n’a pu être alloué. Cette information
peut servir à affiner les données de configuration.
Medium Mbufs overflow :
Nombre de fois qu’un moyen tampon n’a pu être alloué. Cette information
peut servir à affiner les données de configuration.
Large Mbufs overflow :
Nombre de fois qu’un grand tampon n’a pu être alloué. Cette information
peut servir à affiner les données de configuration.
Huge Mbufs overflow :
Nombre de fois qu’un très grand tampon n’a pu être alloué. Cette
information peut servir à affiner les données de configuration.
MTB Mbufs overflow :
Nombre de fois qu’un tampon MTB n’a pu être alloué. Cette information
peut servir à affiner les données de configuration.
Statistiques propres à la carte ATM PCI
Total 4K byte Receive Buffers : 768
Using : 512
Nombre de tampons de réception alloués ainsi que le nombre de tampons
actuellement en cours d’utilisation.
Max 4K byte Receive Buffers limit : 1228 max_used : 514
Nombre maximum de tampons de réception pouvant âtre alloués ainsi que
le nombre de tampons qui ont été utilisés depuis la dernière configuration
ou ouverture de la carte.
Protocole TCP/IP
4-51
Interfaces de réseau TCP/IP
La couche interface de réseau TCP/IP convertit les datagrammes IP de la couche réseau
en paquets interprétables et transmissibles par les technologies de réseau. Une interface
de réseau est un logiciel spécifique d’un réseau qui permet la communication entre le pilote
d’unité du réseau et la couche IP. Ainsi, la couche IP dispose d’une interface fiable pour
communiquer avec toutes les cartes réseau en place.
La couche IP sélectionne l’interface de réseau correspondant à l’adresse de destination
du paquet à transmettre. Chaque interface est dotée d’une adresse. La couche interface de
réseau est chargée d’ajouter ou de supprimer l’en-tête appliqué par la couche liaison pour
assurer la livraison du message. Le pilote de carte réseau contrôle la carte réseau.
Une interface de réseau est généralement associée à une carte réseau, mais ce n’est pas
obligatoire (l’interface de bouclage (loopback), par exemple, ne l’est pas). Chaque machine
doit être équipée d’autant de cartes que de réseaux (et non de types de réseau) auxquels
elle est connectée. Cependant, la machine requiert seulement une copie du logiciel
d’interface de réseau et une copie du pilote d’unité de réseau. Par exemple, si un hôte est
raccordé à deux réseaux en anneau à jeton, il doit être équipé de deux cartes réseau.
Cependant, il requiert seulement une copie du logiciel d’interface de réseau et une copie
du pilote de réseaux en anneau à jeton.
TCP/IP accepte plusieurs types d’interface de réseau :
• Ethernet standard version 2 (en)
• IEEE 802.3 (et)
• Anneau à jeton (tr)
• SLIP (sl)
• Bouclage (lo)
• FDDI
• Optique série (so)
• ATM (at)
• Protocole point à point (ppp)
• Adresse IP virtuelle (vi)
Les interfaces Ethernet, 802.3 et anneau à jeton sont destinées aux réseaux locaux (LAN)
et l’interface SLIP (Serial Line Internet Protocol) aux connexions série. L’interface de
bouclage (loopback) est utilisée par les hôtes pour que les messages qu’ils envoient leur
soient réexpédiés. L’interface Optique série s’applique aux réseaux optiques point à point
exploitant le gestionnaire d’unité de liaison optique série. L’interface ATM est utilisée pour
les connexions ATM 100 Mbits/sec et 155 Mbits/sec. Le protocole PPP (Point to Point
protocol) est généralement utilisé lors de la connexion à un autre ordinateur ou réseau via
un modem. L’interface d’adresse IP virtuelle (également connue sous le nom d’interface
virtuelle) n’est pas associée à une carte réseau donnée. Plusieurs instances d’une interface
virtuelle peuvent être configurées sur un hôte. Lorsque des interfaces virtuelles sont
configurées, l’adresse de la première d’entre elles devient l’adresse source sauf si une
application a choisi une autre interface. Les processus qui utilisent une adresse IP virtuelle
comme adresse source peuvent envoyer des paquets sur toute interface de réseau qui
fournit la meilleure route vers cette destination. Les paquets entrants destinés à une
adresse IP virtuelle sont livrés au processus quelle que soit l’interface via laquelle ils
arrivent.
4-52
Guide de gestion du système – Communications et réseaux
Configuration automatique des interfaces de réseau
A l’installation d’une nouvelle carte réseau (physique), le système d’exploitation ajoute
automatiquement l’interface correspondante. Par exemple, si vous installez une carte
réseau en anneau à jeton, le système la nomme tok0 et ajoute l’interface de réseau en
anneau à jeton tr0. De même, si vous installez une carte Ethernet, le système la nomme
ent0 et ajoute une interface Ethernet version 2 et une interface IEEE 802.3
(respectivement nommées en0 et et0).
Dans la plupart des cas, il existe une correspondance unique entre un nom de carte et un
nom d’interface de réseau. Par exemple, la carte réseau en anneau à jeton tok0
correspond à l’interface tr0, la carte tok1, à l’interface tr1, etc. De même, la carte
Ethernet ent0 correspond aux interfaces en0 (Ethernet version 2) et et0 (IEEE 802.3),
la carte ent1, aux interfaces en1 (Ethernet version 2) et et1 (IEEE 802.3).
Conformément à RFC1577, une station ATM peut faire partie de plusieurs sous-réseaux IP
logiques. Dans ce cas, plusieurs interfaces sont associées à une unité, ce qui suppose
d’ajouter une interface spécifique et de lui affecter un nom d’unité.
Remarque :
En circonstances normales d’exploitation, vous n’aurez jamais à supprimer
ou ajouter manuellement une interface de réseau. Mais vous pouvez être
amené à le faire au cours d’une procédure de résolution d’incident. Dans ce
cas, utilisez wsm (Web–based System Manager) ou le raccourci SMIT
smit inet pour supprimer et réajouter l’interface appropriée.
A chaque lancement du système, l’interface de réseau est automatiquement configurée en
fonction des informations de la base de données ODM, avec des valeurs par défaut. La
communication n’est possible que si une adresse Internet lui a été attribuée. C’est le seul
attribut que vous ayez à définir. Les autres attributs peuvent conserver leur valeur par
défaut. Le détail de ces valeurs est donné dans les paragraphes qui suivent.
Configuration Ethernet par défaut
Voici les attributs de carte réseau Ethernet et leurs valeurs par défaut qui peuvent être
modifiées dans le menu SMIT Sélection d’une interface de réseau ou avec wsm
(Web–based System Manager).
Attribut
Valeur par défaut
Valeurs possibles
state
down
up, down, detach
arp
yes
yes, no
netaddr
netmask
broadcast
Voici l’attribut de pilote d’unité réseau Ethernet et sa valeur par défaut qui peut être modifiée
dans le menu SMIT Sélection d’une interface de réseau ou avec wsm (Web–based
System Manager).
Attribut
Valeur par défaut
Valeurs possibles
mtu
1500
60 à 1500
Protocole TCP/IP
4-53
Configuration 802.3 par défaut
Voici les attributs de carte réseau 802.3 et leurs valeurs par défaut qui peuvent être
modifiées dans le menu SMIT Sélection d’une interface de réseau ou avec wsm
(Web–based System Manager).
Attribut
Valeur par défaut
Valeurs possibles
state
down
up, down, detach
arp
yes
yes, no
netaddr
netmask
broadcast
Voici l’attribut de pilote d’unité réseau 802.3 et sa valeur par défaut qui peut être modifiée
dans le menu SMIT Sélection d’une interface de réseau ou avec wsm (Web–based
System Manager).
Attribut
Valeur par défaut
Valeurs possibles
mtu
1492
60 à 1492
Valeurs de configuration par défaut de l’anneau à jeton
Voici les attributs de carte réseau en anneau à jeton et leurs valeurs par défaut qui peuvent
être modifiées dans le menu SMIT Sélection d’une interface de réseau ou avec wsm
(Web–based System Manager).
Attribut
Valeur par défaut
Valeurs possibles
state
down
up, down, detach
arp
yes
yes, no
hwloop
no
yes, no
no
yes, no
netaddr
netmask
netmask
broadcast
allcast
Voici les attributs de pilote d’unité réseau en anneau à jeton et leurs valeurs par défaut qui
peuvent être modifiées dans le menu SMIT Sélection d’une interface de réseau ou avec
wsm (Web–based System Manager).
Attribut
Valeur par défaut
Valeurs possibles
mtu (4Mbps)
1500
60 à 4056
mtu (16Mbps)
1500
60 à 17960
Remarque :
Lorsque la communication transite par un pont, la valeur MTU par défaut
(de 1500 octets) doit être ramenée à 8 octets en dessous de la valeur
maximum I-frame déclarée par le pont dans le champ de contrôle de
routage. Par exemple, si la valeur de ”maximum I-frame” est 1500 dans le
champ de contrôle de routage, celle de MTU doit être fixée à 1492 (pour les
interfaces anneau à jeton seulement). Pour en savoir plus, reportez-vous à
Incidents sur un pont reliant deux réseaux en anneau à jeton, page 4-283.
Avec la carte en anneau à jeton IBM16/4PowerPC (ISA), la MTU est limitée à 2000.
4-54
Guide de gestion du système – Communications et réseaux
Configuration SLIP par défaut
Voici les attributs de carte réseau SLIP et leurs valeurs par défaut telles qu’elles s’affichent
dans le menu SMIT Sélection d’une interface de réseau ou dans wsm (Web–based
System Manager).
Attribut
Valeur par défaut
Valeurs possibles
up
up, down, detach
netaddr
dest
state
netmask
Voici l’attribut de pilote d’unité réseau SLIP et sa valeur par défaut telle qu’elle s’affiche
dans le menu SMIT Sélection d’une interface de réseau ou dans wsm (Web–based
System Manager).
Attribut
Valeur par défaut
Valeurs possibles
mtu
1006
60 à 4096
Configuration optique série par défaut
Voici les attributs du convertisseur de canal réseau optique série et leurs valeurs par défaut
telles qu’elles s’affichent dans le menu SMIT Sélection d’une interface de réseau ou dans
wsm Web–based System Manager.
Attribut
Valeur par défaut
Valeurs possibles
down
up, down, detach
netaddr
state
netmask
Voici l’attribut du gestionnaire d’unité réseau optique et sa valeur par défaut telle qu’elle
s’affiche dans le menu SMIT Sélection d’une interface de réseau ou dans wsm
(Web–based System Manager).
Attribut
Valeur par défaut
Valeurs possibles
mtu
61428
1 à 61428
Configuration ATM par défaut
Voici les attributs de carte réseau ATM et leurs valeurs par défaut telles qu’elles s’affichent
dans le menu SMIT Sélection d’une interface de réseau ou dans wsm (Web–based
System Manager).
Attribut
Valeur par défaut
Valeurs possibles
state
up
up, down, detach
Connection Type
svc_s
svc_c, svc_s, pvc
idle timer
60
1 à 60
Best Effort Bit Rate (UBR)
en kbits/sec
0
1 à 155.000
netaddr
netmask
ATM Server Address
Alternate Device
Protocole TCP/IP
4-55
Voici l’attribut de pilote d’unité réseau ATM et sa valeur par défaut telle qu’elle s’affiche dans
le menu SMIT Sélection d’une interface de réseau ou dans wsm (Web–based System
Manager).
Attribut
Valeur par défaut
Valeurs possibles
mtu
9180
1 à 64K
Remarque :
La plus grande prudence est recommandée aux administrateurs réseau
s’ils modifient la taille de MTU définie par défaut. La valeur de ce paramètre
doit être compatible avec les autres stations du réseau.
Si des PVC sont utilisés sur une interface, les VPI:VCI doivent être définis via la dernière
option du menu Sélection d’une interface de réseau, PVCs for IP over ATM Network, qui
vous permet de répertorier, d’ajouter, de modifier ou de supprimer des PVC.
Réseaux avec plusieurs interfaces
Si plusieurs interfaces réseau sont connectées à un seul réseau, chaque interface doit avoir
une adresse IP unique.
Avant AIX 5.1, si vous configuriez plusieurs interfaces réseau sur le même réseau, seule
la première interface configurée avait un routage vers le réseau dans la table de routage IP.
La totalité du trafic IP sortant passerait par conséquent uniquement par cette interface, et
pas les autres interfaces du réseau. Bien qu’il soit possible d’utiliser cette configuration pour
équilibrer le trafic entrant, il est déconseillé de l’utiliser dans les versions antérieures à
AIX 5.1.
Dans AIX 5.1 et les versions supérieures, la fonction de Routage multi–chemins permet
d’ajouter des routes à la table de routage IP pour les interfaces multi–chemins sur le même
sous–réseau. Ceci permet au trafic sortant d’alterner entre les interfaces au lieu d’être
envoyées via une seule interface.
Gestion d’interfaces de réseau
Pour gérer des interfaces de réseau, utilisez le gestionnaire système Web, WSM Network,
l’application FastPath ou les procédures du tableau suivant.
Gestion des tâches d’interfaces de réseau
Tâche
Raccourci SMIT
Commande ou
fichier
Web–based System
Manager Management
Environment
Liste de toutes les
unités de réseau
smit lsinet
lsdev –C –c if
Logiciel ––> Unités ––>
Toutes les unités.
Reportez-vous à la
commande
ifconfig et au
fichier rc.net
Logiciel ––> Réseau
––> TCPIP (IPv4 et
IPv6) ––>
Configuration de
protocole ––>
Procédez à la
configuration TCP/IP
de base.
Configuration d’une smit chinet
unité de réseau
4-56
Guide de gestion du système – Communications et réseaux
Modification des
informations
d’interface réseau
avec /usr monté à
distance
smit chdev1,2
Statistiques sur
une interface de
réseau
chgif1,2
Logiciel ––> Réseau
––> TCPIP (IPv4 et
IPv6) ––> Interfaces de
réseau ––>. Cliquez
avec le bouton droit et
sélectionnez Propriétés
––> Alias.
netstat –v
Réseau ––> Réseau
––> TCPIP (IPv4 et
IPv6) ––> Interfaces de
réseau ––>
Statistiques sur le
réseau.
Remarques :
1. Les modifications apportées depuis un /usr monté à distance n’affectent que l’ODM tant
que le réseau n’est pas réinitialisé ou tant que la commande ifconfig n’a pas été utilisée
pour valider les modifications.
2. Avec /usr monté à distance, l’administrateur système doit veiller à ne pas changer
l’interface car elle correspond à l’emplacement des bibliothèques, des commandes
et du noyau.
Options du réseau spécifiques à l’interface
Les interfaces TCP/IP doivent être spécialement définies pour atteindre une bonne
performance réseau à haut débit (au moins 100 Mo). Le fait que plusieurs interfaces de
réseau et une combinaison d’interfaces TCP/IP traditionnelles et à haut débit puissent être
utilisées sur un seul système complique cet effort. Avant AIX 4.3.3 (4330–08) et AIX 5.1,
AIX fournissait un seul ensemble de valeurs au niveau des systèmes pour les paramètres
de réglage de réseau d’interface IP principaux, ce qui rendait impossible le réglage d’un
système ayant des interfaces de cartes réseau très différentes. Depuis AIX 4.3.3 (4330–08)
et AIX 5.1, Interface Specific Network Options (ISNO) permet aux administrateurs système
de régler chaque interface TCP/IP pour obtenir la meilleure performance.
Il existe cinq paramètres ISNO par interface prise en charge : rfc1323, tcp_nodelay,
tcp_sendspace, tcp_recvspace et tcp_mssdflt. Lorsqu’elles sont définies, les valeurs de
ces paramètres remplacent les paramètres de mêmes noms définis avec la commande no
au niveau de l’ensemble du système. Lorsque les options ISNO ne sont pas définies pour
une interface particulière, les options au niveau de l’ensemble du système sont utilisées.
Lorsque des options ont été définies par une application pour un socket donné utilisant la
sous–routine setsockopt, de telles options remplacent les ISNO.
L’option de réseau use_isno, définie avec la commande no, doit être égale à 1 pour que
les ISNO soient pris en compte. La valeur par défaut de use_isno est 1.
Les paramètres ISNO de certaines cartes à haut débit sont définis par défaut dans la base
de données d’ODM.
Les interfaces Gigabit Ethernet, lorsqu’elles sont configurées pour utiliser un MTU de 9000,
utilisent les valeurs ISNO suivantes par défaut :
Nom
Valeur pour AIX
4.3.3
Valeur pour AIX
4.3.3 (4330–08)
Valeur pour AIX 5.1
(ou version
supérieure)
tcp_sendspace
131072
262144
262144
tcp_recvspace
92160
131072
131072
rfc1323
1
1
1
Protocole TCP/IP
4-57
Les interfaces Gigabit Ethernet, lorsqu’elles sont configurées pour utiliser un MTU de 1500,
utilisent les valeurs ISNO suivantes par défaut :
Nom
Valeur pour AIX
4.3.3
Valeur pour AIX
4.3.3 (4330–08)
Valeur pour AIX 5.1
(ou version
supérieure)
tcp_sendspace
65536
131072
131072
tcp_recvspace
16384
65536
65536
rfc1323
0
non définie
non définie
Les interfaces ATM, lorsqu’elles sont configurées pour utiliser un MTU de 1500, utilisent les
valeurs ISNO suivantes par défaut :
Nom
Valeur pour AIX
4.3.3
Valeur pour AIX
4.3.3 (4330–08)
Valeur pour AIX 5.1
(ou version
supérieure)
tcp_sendspace
16384
non définie
non définie
tcp_recvspace
16384
non définie
non définie
rfc1323
0
non définie
non définie
tcp_nodelay
0
non définie
non définie
tcp_mssdflt
512
non définie
non définie
Les interfaces ATM, lorsqu’elles sont configurées pour utiliser un MTU de 65527, utilisent
les valeurs ISNO suivantes par défaut :
Nom
Valeur pour AIX
4.3.3
Valeur pour AIX
4.3.3 (4330–08)
Valeur pour AIX 5.1
(ou version
supérieure)
tcp_sendspace
655360
655360
655360
tcp_recvspace
655360
655360
655360
rfc1323
0
1
1
tcp_nodelay
0
non définie
non définie
tcp_mssdflt
512
non définie
non définie
Les interfaces ATM, lorsqu’elles sont configurées pour utiliser un MTU de 9180, utilisent les
valeurs ISNO suivantes par défaut :
Nom
Valeur pour AIX
4.3.3
Valeur pour AIX
4.3.3 (4330–08)
Valeur pour AIX 5.1
(ou version
supérieure)
tcp_sendspace
65536
65536
65536
tcp_recvspace
65536
65536
65536
rfc1323
0
non définie
non définie
tcp_nodelay
0
non définie
non définie
tcp_mssdflt
512
non définie
non définie
Les interfaces FDDI, lorsqu’elles sont configurées pour utiliser un MTU de 4352, utilisent les
valeurs ISNO suivantes par défaut :
4-58
Nom
Valeur
tcp_sendspace
45046
tcp_recvspace
45046
Guide de gestion du système – Communications et réseaux
Les paramètres ISNO ne peuvent pas être affichés ou modifiés à l’aide de SMIT. Ils peuvent
être définis à l’aide des commandes chdev ou ifconfig. La commande ifconfig ne modifie
les valeurs que jusqu’au prochain redémarrage du système. La commande chdev modifie
les valeurs dans la base de données d’ODM afin qu’elles soient utilisées lors de
redémarrages ultérieurs du système. Les commandes lsattr ou ifconfig peuvent être
utilisées pour afficher les valeurs actuelles.
Exemple
Les commandes suivantes peuvent être d’abord utilisées pour vérifier la prise en charge
du système et de l’interface, puis pour définir et vérifier les nouvelles valeurs.
1. Vérifiez la prise en charge du système général et de l’interface en utilisant les
commandes no et lsattr.
– Vérifiez que l’option use_isno est activée en utilisant une commande semblable à la
suivante :
$ no –a | grep isno
use_isno=1
– Vérifiez que l’interface prend en charge les cinq nouveaux ISNO utilisant la commande
lsattr –El, comme illustré ci–dessous :
$ lsattr –E –l en0 –H
attribute
value
rfc1323
tcp_nodelay
tcp_sendspace
tcp_recvspace
tcp_mssdflt
description
N/A
N/A
N/A
N/A
N/A
2. Définissez les valeurs spécifiques à l’interface en utilisant les commandes ifconfig ou
chdev. La commande ifconfig définit temporairement des valeurs, ce qui est
recommandé pour effectuer des tests. La commande chdev modifie l’ODM, les valeurs
personnalisées conservent donc leur validité après un redémarrage du système.
– Définissez tcp_recvspace et tcp_sendspace à 64 K et activez tcp_nodelay en
utilisant l’une des solutions suivantes :
$ ifconfig en0 tcp_recvspace 65536 tcp_sendspace 65536 tcp_nodelay 1
$ chdev –l en0 –a tcp_recvspace=65536 –a tcp_sendspace=65536 –a
tcp_nodelay=1
– En supposant également que la commande no donne une valeur globale rfc1323=1,
l’utilisateur racine peut désactiver rfc1323 pour toutes les connexions sur en0 avec les
commandes suivantes :
$ ifconfig en0 rfc1323 0
$ chdev –l en0 –a rfc1323=0
3. Vérifiez les paramètres à l’aide des commandes ifconfig ou lsattr, comme illustré dans
l’exemple ci–dessous :
$ ifconfig en0 <UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,
MULTICAST,GROUPRT,64BIT>
en0: flags=e080863
inet 9.19.161.100 netmask 0xffffff00 broadcast 9.19.161.255
tcp_sendspace 65536 tcp_recvspace 65536 tcp_nodelay 1 rfc1323 0
$ lsattr –El en0
rfc1323
tcp_nodelay
tcp_sendspace
tcp_recvspace
tcp_mssdflt
0
1
65536
65536
N/A
N/A
N/A
N/A
N/A
True
True
True
True
True
Protocole TCP/IP
4-59
Adressage TCP/IP
TCP/IP contient un schéma d’adressage Internet qui permet aux utilisateurs et aux
applications d’obtenir l’identité d’un réseau ou d’un hôte pour établir une communication.
Une adresse Internet fonctionne sur le même principe qu’une adresse postale : elle permet
aux données d’être acheminées à destination. TClP/IP intègre des normes d’adressage de
réseaux, sous-réseaux, hôtes, sockets, et des normes d’utilisation des adresses de diffusion
et de bouclage.
Une adresse Internet est constituée d’une adresse réseau et d’une adresse d’hôte (locale).
Ce format permet de spécifier dans la même adresse le réseau et l’hôte cible. Une adresse
officielle unique est attribuée à chaque réseau qui se connecte à d’autres réseaux Internet.
Pour les réseaux non connectés à d’autres réseaux Internet, l’adresse peut être déterminée
selon la convenance locale.
Le schéma d’adressage Internet propose des adresses IP (Internet Protocol) et deux cas
particuliers d’adresse IP : adresses de diffusion et adresses de bouclage.
Adresses Internet
Le protocole IP (Internet Protocol) utilise une zone d’adresse de 32 bits formée de deux
parties. Les 32 bits sont répartis en groupes de quatre octets comme suit :
01111101 00001101 01001001 00001111
Ces nombres binaires correspondent à :
125 13 73 15
Les deux parties de l’adresse Internet sont respectivement l’adresse réseau et l’adresse
hôte. Ainsi, un hôte distant peut expédier des informations en précisant le réseau distant et
l’hôte destinataire sur ce réseau. Par convention, le numéro d’hôte 0 (zéro) désigne le
réseau lui-même.
TCP/IP prend en charge trois classes d’adresses Internet : A, B et C, qui se distinguent par
l’attribution des 32 bits. L’appartenance à une classe est déterminée par la taille du réseau.
Adresses de classe A
Une adresse de classe A se compose d’une adresse de réseau de 8 bits et d’une adresse
hôte local de 24 bits. Le premier bit de l’adresse de réseau sert à désigner la classe du
réseau et les 7 autres, l’adresse effective. Le nombre le plus élevé que peuvent représenter
ces 7 bits en binaire est 128 ; la classe A offre donc 128 adresses possibles. Deux sont
réservées à des cas particuliers : l’adressage de bouclage local pour l’une (code 127) et
l’adressage de diffusion pour l’autre (adresse qui couvre la totalité des réseaux).
Il en résulte 126 adresses de réseau de classe A possibles et 16 777 216 adresses d’hôte
local. Dans une adresse de classe A, le bit de poids fort est positionné à 0 (voir figure ).
Figure 17. Adresse de classe A Cette illustration représente une structure d’adresse de
classe A typique. Les 8 premiers bits contiennent l’adresse réseau (commençant toujours
par un zéro). Les 24 bits restants contiennent l’adresse hôte locale.
Adresse de réseau
(8 bits)
Adresse d’hôte local
(24 bits)
Remarque : Le bit de poids fort (le premier) est toujours positionné à 0 dans une
adresse de classe A.
Autrement dit, le premier octet d’une adresse de classe A est compris entre 1 et 126.
4-60
Guide de gestion du système – Communications et réseaux
Adresse de classe B
Une adresse de classe B se compose d’une adresse de réseau de 16 bits et d’une adresse
hôte local de 16 bits. Les 2 premiers bits de l’adresse de réseau désignent la classe de
réseau et les 14 autres, l’adresse effective. Par conséquent, il y a 16 384 adresses de
réseau possibles et 65 536 adresses hôte local. Dans une adresse de classe B, les bits de
poids fort sont positionnés à 1 et 0.
Figure 18. Adresse de classe B Cette illustration représente une structure d’adresse de
classe B typique. Les 16 premiers bits contiennent l’adresse réseau. Les deux bits d’ordre
supérieur sont toujours un 1 et un zéro. Les 16 bits restants contiennent l’adresse hôte
locale.
Adresse de réseau
(16 bits)
Adresse d’hôte local
(16 bits)
Remarque : Les 2 bits de poids fort (les deux premiers) sont toujours positionnés
à 1 et 0 dans une adresse de classe B.
Autrement dit, le premier octet d’une adresse de classe B est compris entre 128 et 191.
Adresse de classe C
Une adresse de classe C se compose d’une adresse de réseau de 24 bits et d’une adresse
hôte local de 8 bits. Les 2 premiers bits de l’adresse de réseau désignent la classe de
réseau et les 22 autres, l’adresse effective. Par conséquent, il y a 2 097 152 adresses de
réseau possibles et 256 adresses hôte local possibles. Dans une adresse de classe C, les
bits de poids fort sont positionnés à 1 et 1 (voir figure).
Figure 19. Adresse de classe C Cette illustration représente une structure d’adresse de
classe C typique. Les 24 premiers bits contiennent l’adresse réseau (les deux bits d’ordre
supérieur sont toujours un 1 et un 1). Les 8 bits restants contiennent l’adresse hôte locale.
Adresse de réseau
(24 bits)
Adresse d’hôte local
(8 bits)
Remarque : Les 2 bits de poids fort (les deux premiers) sont toujours positionnés
à 1 dans une adresse de classe C.
Autrement dit, le premier octet d’une adresse de classe C est compris entre 192 et 223.
Pour décider de la classe d’adresse, vous devez tenir compte du nombre d’hôtes locaux et
de sous-réseaux prévus. Si l’organisation est réduite et que le réseau comporte moins de
256 hôtes, une adresse de classe C est probablement suffisante. Sinon, il faut envisager
une adresse de classe A ou B.
Remarque :
Les adresses de classe D (1-1-1-0 pour les bits de poids fort), prises en
charge par UDP/IP sous ce système, sont utilisées comme adresses de
diffusion.
Les machines lisent les adresses en code binaire. Par convention, les adresses hôtes
Internet sont exprimées en notation décimale à points sur 32 bits répartis en quatre zones
de 8 bits. Par exemple, la valeur binaire :
0001010 00000010 00000000 00110100
Protocole TCP/IP
4-61
peut être exprimée comme suit :
010.002.000.052
ou
10.2.0.52
La valeur de chacune de ces zones, séparées par un point, est un nombre décimal.
Remarque :
La commande hostent reconnaît les adresses suivantes : .08, .008, .09
et .009. Les adresses introduites par des zéros sont interprétées en base
octale, laquelle exclut les chiffres 8 et 9.
TCP/IP requiert une adresse Internet unique pour chaque interface (carte) du réseau. Ces
adresses, définies par la base de données de configuration, doivent concorder avec celles
du fichier /etc/hosts ou, si un serveur de noms est utilisé, de la base de données named.
Adresses Internet avec zéros
Lorsque la zone d’adresse hôte d’une adresse Internet de classe C a la valeur 0 (par
exemple 192.9.200.0), TCP/IP envoie une adresse générique sur le réseau : toutes les
machines dotées de l’adresse de classe 192.9.200.X (où X représente une valeur comprise
entre 0 et 254) doivent répondre à la requête. Il en résulte que le réseau est inondé de
requêtes adressées à des machines inexistantes.
Le même problème se pose pour une adresse de classe B du type 129.5.0.0 : toutes les
machines dotées de l’adresse de classe 129.5.X.X. (où X représente une valeur comprise
entre 0 et 254) doivent répondre à la requête. Mais, dans ce cas, le nombre de requêtes est
bien plus important encore que sur un réseau de classe C car les adresses de classe B
couvrent des réseaux plus vastes.
Adresses de sous-réseau
Grâce au mécanisme d’adressage de sous-réseau, un système autonome regroupant
plusieurs réseaux peut disposer d’une même adresse Internet. Il est également possible de
diviser un réseau en plusieurs réseaux logiques (sous-réseaux). Par exemple, une
organisation sera dotée d’une adresse Internet unique connue par les utilisateurs extérieurs
à l’organisation mais comportera en interne plusieurs sous-réseaux de service. Quel que
soit le cas de figure, l’adressage de sous-réseau réduit le nombre d’adresses Internet
requises et optimise le routage local.
La zone d’adresse du protocole IP est formée de deux parties : une adresse réseau et une
adresse locale. Cette dernière est constituée d’un numéro de sous–réseau et d’un numéro
d’hôte, ce qui permet de définir des adresses de sous–réseau. L’identification du
sous–réseau est suffisamment précise pour assurer le routage des messages de façon
fiable.
Dans l’adresse Internet de classe A (voir figure), qui se compose d’une adresse de réseau
de 8 bits et d’une adresse hôte local de 24 bits, l’adresse locale identifie la machine hôte
spécifique sur le réseau.
Figure 20. Adresse de classe A Cette illustration représente une structure d’adresse de
classe A typique. Les 8 premiers bits contiennent l’adresse réseau (commençant toujours
par un zéro). Les 24 bits restants contiennent l’adresse hôte locale.
Adresse de réseau
(8 bits)
Adresse d’hôte local
(24 bits)
Pour créer une adresse de sous-réseau pour réseau Internet de classe A, l’adresse locale
est composée de deux éléments : le numéro d’identification du réseau physique
(ou sous-réseau) et le numéro de l’hôte sur le sous-réseau. Les messages sont renvoyés à
l’adresse de réseau indiquée et le système local se charge d’acheminer les messages vers
ses sous-réseaux et hôtes. Le partitionnement de l’adresse locale en adresses sous-réseau
et hôte s’effectue en fonction du nombre de sous-réseaux et d’hôtes correspondants.
4-62
Guide de gestion du système – Communications et réseaux
Le tableau ci–dessous décrit l’adresse locale divisée en une adresse de sous–réseau
12 bits et une adresse hôte 12 bits.
Figure 21. Adresse de classe A avec sous–réseau correspondant Adresse Cette
illustration représente une structure d’adresse de classe A typique. Les 8 premiers bits
contiennent l’adresse réseau (commençant toujours par un zéro). Les 24 derniers bits
contiennent l’adresse hôte locale avec l’adresse de sous–réseau qui occupe les 8 premiers
bits et l’adresse hôte qui occupe les 8 derniers bits.
Adresse de réseau
(8 bits)
Adresse de réseau
Adresse d’hôte local
(24 bits)
Adresse de sous-réseau
Adresse d’hôte
Remarque : Le bit de poids fort (le premier) est toujours positionné à 0 dans une
adresse de classe A.
Vous bénéficiez d’une grande souplesse d’adressage des sous-réseaux et hôtes. Les bits
de l’adresse locale peuvent être répartis en fonction de la croissance potentielle de
l’organisation et de la structure de réseau. Les règles à respecter sont les suivantes :
• adresse_réseau correspond à l’adresse Internet.
• adresse_sous–réseau est une zone de longueur constante pour un réseau donné.
• adresse_hôte est une zone de 1 bit minimum.
Si la longueur de la zone adresse de sous–réseau est 0, le réseau n’est pas organisé
en sous-réseaux, et l’adressage du réseau se fait par le biais de l’adresse de réseau
Internet.
Il n’est donc pas nécessaire que ces bits soient contigus dans l’adresse, bien que ce soit
généralement préférable. De même, il est conseillé de positionner les bits de sous-réseau
comme bits de poids fort de l’adresse locale.
Masques de sous-réseau
Lorsqu’un hôte envoie un message, le système doit déterminer si la destination du message
se trouve sur le même réseau que la source ou sur un réseau directement accessible par
une des interfaces locales. Pour ce faire, il compare l’adresse de destination à l’adresse
hôte sur la base d’un masque de sous-réseau. Lorsque la destination n’est pas locale, le
message transite par une passerelle. La passerelle détermine si la destination est
accessible localement en procédant à la même comparaison.
Le masque de sous-réseau fournit au système le schéma de partitionnement du
sous-réseau. Ce masque de bits comporte la partie adresse de réseau et la partie adresse
de sous-réseau de l’adresse Internet (voir figure). Par exemple, le masque de sous-réseau
de l’adresse de classe A répartie comme indiqué précédemment se présente comme suit :
Protocole TCP/IP
4-63
Figure 22. Adresse de classe A avec sous–réseau correspondant Adresse Cette
illustration représente une structure d’adresse de classe A typique. Les 8 premiers bits
contiennent l’adresse réseau (commençant toujours par un zéro). Les 24 derniers bits
contiennent l’adresse hôte locale avec l’adresse de sous–réseau qui occupe les 8 premiers
bits et l’adresse hôte qui occupe les 8 derniers bits.
Adresse de réseau
(8 bits)
Adresse de réseau
Adresse d’hôte local
(24 bits)
Adresse de sous-réseau
Adresse d’hôte
Adresse de classe A intégrant une adresse de sous-réseau
Adresse de réseau
(8 bits)
Adresse de réseau
Adresse d’hôte local
(24 bits)
Adresse de sous-réseau
Adresse d’hôte
Masque de sous-réseau
Adresse d’hôte
Adresse de classe A intégrant un masque de sous-réseau
Le masque de sous-réseau est un ensemble de 4 octets, comme l’adresse interréseau. Il
comporte des bits de poids fort (les 1) qui correspondent aux emplacements de bits de
l’adresse de réseau et de sous-réseau, et des bits de poids faible (les 0) correspondant aux
emplacements des bits de l’adresse hôte. Le masque de sous-réseau de l’adresse donnée
dans la figure ci-dessus se présente comme suit :
Figure 23. Exemple de masque de sous–réseau Cette illustration représente un exemple
d’une structure de masque de sous–réseau. Les 8 premiers bits contiennent l’adresse
réseau. Les 24 derniers bits contiennent l’adresse hôte locale avec l’adresse de
sous–réseau qui occupe les 8 premiers bits et l’adresse hôte qui occupe les 8 derniers bits.
Adresse de réseau
(8 bits)
Adresse de réseau
Adresse d’hôte local
(24 bits)
Adresse de sous-réseau
Adresse d’hôte
Comparaison d’adresses
L’adresse de destination est comparée à l’adresse de réseau local en appliquant l’opérateur
logique AND et l’opérateur d’exclusion OR sur le masque de sous-réseau de l’hôte source :
La procédure de comparaison se déroule comme suit :
1. Application de l’opérateur logique AND entre l’adresse de destination et le masque de
l’adresse de sous-réseau local.
2. Application de l’opérateur d’exclusion OR entre le résultat de l’opération précédente et
l’adresse de réseau local associée à l’interface locale.
Si le résultat ne fournit que des zéros, la destination est supposée directement
accessible via une des interfaces locales.
4-64
Guide de gestion du système – Communications et réseaux
3. Si un système autonome est équipé de plusieurs interfaces (et donc de plusieurs
adresses Internet), la comparaison est effectuée pour chaque interface locale.
Supposons, par exemple, que deux interfaces locales soient définies pour le réseau
hôte T125. Leur adresse Internet et la représentation binaire de ces adresses doivent se
présenter comme suit :
Adresses d’interface de réseau local
CLASS A
73.1.5.2
= 01001001 00000001 00000101 00000010
CLASS B
145.21.6.3
=
10010001 00010101 00000110 00000011
Les masques de sous-réseau correspondants des interfaces de réseau local se présentent
comme suit :
Adresses d’interface de réseau local
CLASS A
73.1.5.2
= 11111111 11111111 11100000 00000000
CLASS B
145.21.6.3
=
11111111 11111111 11111111 11000000
Si le réseau source T125 est sollicité pour envoyer un message au réseau de destination
avec 114.16.23.8 pour adresse hôte (représentée en binaire par 01110010 00010000
00010111 00001000), le système vérifie si la destination est directement accessible via une
interface locale.
Remarque: Le mot clé subnetmask doit être défini dans la base de données de
configuration de chaque hôte appelé à desservir des sous-réseaux. En effet,
les sous-réseaux ne sont utilisables que s’ils sont pris en charge par chaque
hôte du réseau. Vous devez donc déclarer le masque de sous-réseau comme
permanent dans la base de données de configuration, via le menu SMIT
Sélection d’une interface de réseau ou via l’application Web-based System
Manager Network. Vous pouvez également déclarer le masque de
sous–réseau dans le système d’exploitation via la commande ifconfig.
(si vous utilisez ifconfig, la modification n’est pas permanente).
Adresses de diffusion
TCP/IP peut transmettre des données à tous les hôtes du réseau local ou des réseaux
directement connectés. Ces transmissions sont appelées messages de diffusion. Par
exemple, le démon de routage routed fait appel à ce type de message pour lancer des
requêtes de routage ou y répondre.
Les données à diffuser aux hôtes des réseaux directement connectés sont transmises par
les protocoles UDP (User Datagram Protocol) et IP (Internet Protocol), avec, dans l’en-tête
IP, tous les bits de l’adresse de destination hôte positionnés à 1. Dans le cas de données à
diffuser aux hôtes d’un réseau spécifique, tous les bits de la partie adresse locale de
l’adresse IP sont positionnés à 0.
L’adresse de diffusion peut être modifiée temporairement via le paramètre broadcast dans
la commande ifconfig. Modifiez-la de façon permanente avec le raccourci Web-based
System Manager wsm ou avec le raccourci SMIT smit chinet. Ceci peut s’avérer utile
pour la compatibilité avec des versions antérieures de logiciels qui utilisent des adresses de
diffusion différentes (avec, par exemple, des ID hôte définies à 0).
Adresses de bouclage local
Le protocole IP déclare l’adresse de réseau spéciale 127.0.0.1 comme adresse de
bouclage local. Les hôtes utilisent cette adresse pour s’envoyer des messages à
eux-mêmes. L’adresse de bouclage local est définie par le gestionnaire de configuration lors
du démarrage du système. Le bouclage local est appliqué dans le noyau et peut également
être défini avec la commande ifconfig. Le bouclage est appelé au lancement du système.
Protocole TCP/IP
4-65
Résolution de noms sous TCP/IP
Bien que les adresses Internet 32–bits fournissent un moyen efficace d’identifier la source
et la destination des datagrammes à travers un interréseau, les utilisateurs préfèrent utiliser
des noms représentatifs et faciles à mémoriser. TCP/IP propose un système d’attribution de
noms applicable à des réseaux hiérarchiques ou plats.
Cette section traite des points suivants :
• Système d’appellation, page 4-66
• Résolution locale des noms (/etc/hosts), page 4-74
• Préparation à la résolution DNS (DOMAIN), page 4-75
• Serveur de noms : généralités, page 4-76
• Configuration des serveurs de noms, page 4-77
• Configuration d’un serveur expéditeur, page 4-80
• Configuration d’un serveur de noms exclusivement expéditeur, page 4-81
• Configuration d’un hôte avec un serveur de noms, page 4-83
• Configuration de zones dynamiques sur le serveur de noms DNS, page 4-85
• Planification et configuration pour la résolution de noms LDAP
(Schéma de répertoire SecureWay), page 4-92
• Planification et configuration pour la résolution de noms NIS_LDAP
(Schéma RFC 2307), page 4-93
Système d’appellation
Le système d’appellation des réseaux plats est très simple : les noms attribués aux hôtes
sont formés par une chaîne unique de caractères et gérés le plus souvent localement.
Chaque machine du réseau plat dispose d’un fichier /etc/hosts qui contient, pour chaque
hôte du système, l’équivalence entre le nom et l’adresse Internet. Ce fichier s’étoffe avec
l’extension du réseau et sa mise à jour représente une tâche de plus en plus lourde.
Lorsque des réseaux prennent une grande envergure comme dans le cas d’Internet, leurs
systèmes d’appellation sont hiérarchisés. Ces divisions reflètent généralement
l’organisation des réseaux. En TCP/IP, le système d’appellation est connu sous le nom de
DNS (domain name system) et utilise le protocole DOMAIN. Ce protocole DOMAIN est
lancé par le démon named dans TCP/IP.
Le système d’appellation hiérarchique DNS, comme pour les réseaux plats, attribue aux
réseaux et aux hôtes des noms symboliques à la fois représentatifs et faciles à mémoriser.
Mais au lieu de tenir un fichier d’équivalence sur chaque machine du réseau, il désigne un
ou plusieurs hôtes pour jouer le rôle de serveurs de noms. Ces serveurs sont chargés de
traduire (résoudre) les noms symboliques des réseaux et des hôtes en adresses Internet
interprétables par les machines. Chaque serveur dispose des informations complètes sur la
zone du domaine dont il a la charge.
Autorité d’appellation
Dans un réseau plat, tous les hôtes sont gérés par une autorité centrale. Cette forme de
réseau implique que tous les hôtes aient un nom unique. Transposé à un réseau étendu, ce
système représenterait, pour l’autorité centrale, une charge administrative très lourde.
Dans un réseau hiérarchique (organisé en domaines), les hôtes sont gérés par groupes
répartis dans une hiérarchie de domaines et de sous-domaines. Ainsi, l’unicité d’un nom
d’hôte n’est exigée que dans son domaine local, et l’autorité centrale n’a en charge que le
domaine racine. Cette structure, qui permet la gestion des sous-domaines en local,
décharge l’autorité centrale. Prenons l’exemple du réseau Internet : son domaine racine est
divisé en domaines com (secteur commercial), edu (secteur éducatif), gov (secteur public)
4-66
Guide de gestion du système – Communications et réseaux
et mil (secteur militaire). A ce niveau, seule l’autorité centrale est habilitée à ajouter de
nouveaux domaines. Dans chacun de ces domaines, l’appellation de deuxième niveau est
déléguée à un agent désigné. Ainsi, l’agent du domaine COM décide de l’appellation de
tous les sous-domaines situés sous com. De même, l’appellation au troisième niveau (et
ainsi de suite) est déléguée aux agents de ce niveau. Dans la figure qui suit, le domaine
Century est responsable de l’appellation de ses sous–domaines Austin, Hopkins et
Charlotte.
Figure 24 Structure de domaine Internet Cette figure illustre la structure hiérarchique
d’Internet. Elle commence par le haut avec la racine et forme de branches jusqu’au niveau
suivant contenant les domaines mil, com et edu. Sous le domaine com se trouve un autre
niveau contenant Charlotte, Austin et Hopkins. Sous Austin se trouvent Dev et Graphics.
RACINE
COM
MIL
EDU
Century
Austin
Charlotte
Dev
Hopkins
Graphics
Protocole TCP/IP
4-67
Le sous-domaine Austin pourrait aussi être divisé en zones comme Dev et Graphics. Dans
ce cas, la zone austin.century.com couvre toutes les données du domaine
austin.century.com, excepté celles dépendant de Dev et de Graphics. De même, la
zone dev.century.com contient uniquement les données confiées à Dev et n’a aucune
visibilité sur le contenu de la zone Graphics. La zone austin.century.com (par
opposition au domaine du même nom) ne contient que les données qui n’ont pas été
confiées aux autres zones.
Conventions d’appellation
Dans un système d’appellation hiérarchique, les noms sont formés par une suite de noms
sans distinction majuscules/minuscules, séparés par un point et dépourvus d’espaces.
Selon le protocole DOMAIN, la longueur du nom de domaine local doit être inférieure à
64 caractères et celle du nom d’hôte, à 32 caractères. Le nom de l’hôte vient en premier,
suivi d’un point (.), d’une série de noms de domaines locaux et enfin du domaine racine.
Au total, le nom complet d’un domaine pour un hôte ne doit pas dépasser 255 caractères
(points compris) et se présente sous la forme :
hôte.sousdomaine1.[sousdomaine2 . . . sousdomain].domaineracine
Les noms d’hôte étant uniques dans un domaine, vous pouvez utiliser des noms abrégés
(relatifs) pour envoyer des messages au sein du même domaine. Par exemple, au lieu
d’adresser un message à smith.eng.lsu.edu, un hôte du domaine eng peut indiquer
seulement smith. Par ailleurs, chaque hôte peut être assorti de plusieurs alias utilisables
par les autres hôtes.
Appellation des hôtes de votre réseau
Les noms d’hôte sont conçus pour simplifier la désignation des ordinateurs d’un réseau.
Les administrateurs d’Internet ont constaté que, en matière de nom, il existe de bons et de
mauvais choix. Il faut donc éviter certains pièges.
Voici quelques conseils pour vous aider à choisir les noms d’hôte de votre réseau :
• Préférez des noms peu usités tels que sphinx ou eclipse.
• Utilisez aussi des noms thématiques tels que des couleurs, des éléments helium,
argon ou zinc), des fleurs, des poissons, etc.
• Pensez encore à utiliser de véritables mots
(plutôt que des chaînes de caractères aléatoires).
Puisez dans le vocabulaire existant (n’inventez pas de chaînes de caractères).
Inversement, pour limiter les oublis ou les confusions (pour l’utilisateur ou la machine),
évitez :
• les termes très courants tels que up, down ou crash,
• les noms contenant uniquement des chiffres,
• les noms contenant des signes de ponctuation,
• les noms différenciés par des majuscules ou des minuscules
(par exemple, Orange et orange),
• le nom ou les initiales de l’utilisateur principal du système,
• les noms de plus de 8 caractères,
• les orthographes inhabituelles ou volontairement incorrectes
(par exemple, czek, qui peut être confondu avec “check” ou “tech”),
• les noms de domaine ou assimilables, tel que yale.edu.
4-68
Guide de gestion du système – Communications et réseaux
Serveurs de noms
Dans une structure plate, tous les noms doivent être stockés dans le fichier /etc/hosts de
chaque hôte membre du réseau. Ce système se révèle difficile à gérer lorsque le réseau est
très étendu.
Dans une structure hiérarchique, les hôtes désignés comme serveurs de noms se chargent
de résoudre le nom de chaque hôte en une adresse Internet. Ce mécanisme présente deux
avantages par rapport à la structure plate : les ressources nécessaires à la résolution des
noms ne sont pas mobilisées au niveau de chaque hôte et la tâche de l’administrateur
système, alors déchargé de la mise à jour de chaque fichier de résolution des noms, s’en
trouve allégée. L’ensemble des noms administrés par un serveur de noms est appelé
zone d’autorité de ce serveur.
Remarque :
La machine qui assure la fonction de résolution des noms pour une
zone d’autorité est appelée hôte serveur de noms mais, en réalité, c’est
le process (démon named) contrôlant cette fonction qui est le véritable
serveur de noms.
Pour optimiser l’activité du réseau, les serveurs de noms stockent en mémoire cache
(mémoire temporaire) les équivalences noms-adresses. Ainsi, lorsqu’un client demande au
serveur de résoudre un nom, ce dernier consulte d’abord la mémoire cache où se trouvent
les équivalences des derniers noms résolus. Ces équivalences sont conservées en
mémoire pour une durée limitée (définie dans le paramètre TTL “Time-To-Live” de l’article
de ressource), les noms de domaine et d’hôtes pouvant être modifiés. Les autorités
d’appellation sont donc en mesure de spécifier la durée pendant laquelle la résolution de
noms est réputée fiable.
Un système autonome peut comporter plusieurs serveurs de noms. Ces serveurs de noms
suivent généralement une structure hiérarchique qui reflète l’organisation du réseau.
Comme le montre la figure Structure en domaines d’Internet, chaque domaine peut
bénéficier d’un serveur de noms responsable de tous ses sous-domaines. Les serveurs de
noms des sous-domaines communiquent avec le serveur de noms du domaine supérieur
(ou serveur de noms père) et les serveurs des autres sous-domaines.
Figure 25. Structure de domaine Internet Cette figure illustre la structure hiérarchique
d’Internet. Elle commence par le haut avec la racine et forme de branches jusqu’au niveau
suivant contenant les domaines mil, com et edu. Sous le domaine com se trouve un autre
niveau contenant Charlotte, Austin et Hopkins. Sous Austin se trouvent Dev et Graphics.
Protocole TCP/IP
4-69
RACINE
COM
MIL
EDU
Century
Austin
Charlotte
Dev
Hopkins
Graphics
Dans la figure Structure en domaines d’Internet, Austin, Hopkins et Charlotte sont tous des
sous-domaines de Century. Si la hiérarchie du réseau est respectée, le serveur de noms
Austin communique avec Charlotte et Hopkins ainsi qu’avec le serveur de noms père
Century. Austin communique également avec les serveurs de noms chargés de ses
sous-domaines.
4-70
Guide de gestion du système – Communications et réseaux
Il existe plusieurs types de serveur de noms :
serveur de noms maître
Il charge ses données à partir d’un fichier ou d’un disque et
peut éventuellement déléguer des fonctions à d’autres
serveurs de son domaine.
serveur de noms esclave
Au lancement du système, il reçoit du serveur de noms
maître les informations sur une zone d’autorité donnée, et
interroge périodiquement ce serveur maître pour la mise à
jour des informations. Une fois le délai de rafraîchissement
écoulé (valeur de l’article SOA sur le serveur de noms
esclave), ou à réception d’une notification émise par le
serveur maître, le serveur esclave recharge la base de
données à partir du serveur maître si la sienne est devenue
obsolète (autrement dit, si sa référence est antérieure à
celle de la base du serveur maître). S’il devient nécessaire
de forcer un transfert de zones, il suffit de supprimer les
bases de données en place sur les serveurs esclaves et de
régénérer le démon named sur le serveur de noms
esclave.
Serveur de noms de
tronçon (stub)
Bien que la méthode soit similaire à celle utilisée par le
serveur de noms esclave, le serveur de noms de tronçon
(stub) reproduit uniquement les données de serveurs de
noms de la base de données maître, et non l’ensemble de
la base.
Serveur d’indices
(hint server)
Ce serveur de noms ne fonctionne que d’après les indices
accumulés suite aux requêtes antérieures auprès d’autres
serveurs. Le serveur d’indices (hint server) répond aux
requêtes en demandant les informations souhaitées auprès
des autres serveurs “experts” (serveurs ayant autorité) s’il
ne dispose pas dans sa mémoire cache de l’équivalence
demandée.
Serveur client ou
expéditeur
Envoie les requêtes qu’il ne peut satisfaire localement aux
serveurs répertoriés dans une liste prédéfinie. Les serveurs
exclusivement expéditeurs (simples transmetteurs
d’informations, qui ne sont pas à proprement parler des
serveurs) ne dialoguent pas avec les serveurs de noms
maîtres pour le domaine racine ou les autres domaines.
Les requêtes transitent d’un serveur à l’autre de façon
récursive : les serveurs expéditeurs sont contactés l’un
après l’autre jusqu’à la fin de la liste. Ce type de
configuration est généralement utilisé pour éviter que tous
les serveurs d’un site dialoguent avec les autres serveurs
Internet, ou pour constituer une mémoire cache étendue
dans un certain nombre de serveurs de noms.
Serveur distant
Lance tous les programmes réseau qui font appel au
serveur de noms, alors que le process serveur de noms
n’est pas exécuté sur l’hôte local. Les requêtes sont prises
en charge par un serveur de noms exécuté sur une autre
machine du réseau.
Un hôte serveur de noms peut exercer diverses fonctions dans des zones d’autorité
différentes. Par exemple, il peut faire fonction de serveur de noms maître dans une zone, et
de serveur de noms esclave dans une autre.
Protocole TCP/IP
4-71
Résolution de noms
La procédure d’obtention d’une adresse Internet à partir d’un nom d’hôte, appelée
“résolution de noms”, est exécutée par la sous-routine gethostbyname. Inversement, la
traduction d’une adresse Internet en nom d’hôte est appelée “résolution inverse de noms”,
et est exécutée par la sous-routine gethostbyaddr. Ces routines permettent
essentiellement d’accéder à une bibliothèque de routines de traduction de noms appelées
“routines de résolution”.
Les routines de résolution sur les hôtes TCP/IP essaient normalement de résoudre les
noms en utilisant les sources suivantes :
1. BIND/DNS (nommé),
2. NIS (Network Information Services),
3. Fichier /etc/hosts local.
Lors de l’installation de NIS+, les préférences de recherche sont définies dans le fichier
irs.conf. Pour plus d’informations, reportez–vous à AIX 5L Version 5.3 NIS/NIS+
(Network Information Services) Guide.
Pour résoudre un nom dans un réseau hiérarchique, la routine de résolution émet tout
d’abord une requête auprès de la base de données du serveur de noms de domaine,
résidant sur l’hôte local (s’il s’agit d’un hôte serveur de noms de domaine) ou sur un hôte
étranger. Les serveurs de noms transforment les noms de domaines en adresses Internet.
L’ensemble des noms administrés par un serveur de noms est appelé zone d’autorité de ce
serveur. Si la routine de résolution utilise un serveur de noms distant, elle a recours au
protocole DOMAIN (protocole de noms de domaine) pour les requêtes de mappage. Pour
résoudre un nom dans un réseau plat, la routine recherche l’entrée correspondante dans le
fichier local /etc/hosts. Si NIS ou NIS+ est utilisé, le fichier /etc/hosts du serveur maître est
également vérifié.
Par défaut, les routines de résolution essaient de résoudre les noms à l’aide des ressources
mentionnées ci–dessus. Le mécanisme BIND/DNS est lancé en premier. Si le fichier
/etc/resolv.conf n’existe pas ou si le nom est introuvable, une requête est émise auprès de
NIS si ce système est en service. NIS ayant autorité sur le fichier /etc/hosts local, la
recherche peut s’arrêter là. Si NIS n’est pas en service, la recherche s’effectue sur le fichier
local /etc/hosts. Si ce nom reste introuvable, les routines de résolution renvoient le
message HOST_NOT_FOUND. Si tous les services sont indisponibles, les routines de
résolution renvoient le message SERVICE_UNAVAILABLE.
Il est possible de modifier l’ordre de recherche présenté ci–dessus en créant le fichier de
configuration /etc/irs.conf pour y préciser l’ordre voulu. Ces deux ordres (ordre par défaut
et fichier /etc/irs.conf) peuvent encore être écrasés par la variable d’environnement
NSORDER. Si ni le fichier /etc/irs.conf ni la variable d’environnement NSORDER
ne sont définies, au moins une valeur doit être spécifiée avec l’option.
Pour définir l’ordre des hôtes avec le fichier /etc/irs.conf :
hosts value [ continue ]
Pour définir l’ordre, chaque méthode doit être indiquée sur une ligne distincte. La valeur
correspond à une des méthodes indiquées et le mot clé continue indique qu’une autre
méthode de résolution figure en ligne suivante.
Dans la variable d’environnement NSORDER :
NSORDER= value, value, value
L’ordre est spécifié sur une seule ligne avec des valeurs séparées par une virgule.
Les espaces sont admis entre les virgules et le signe égal.
Par exemple, si le réseau local est “plat”, seul le fichier /etc/hosts/ est nécessaire.
Dans cet exemple, le fichier /etc/irs.conf contient la ligne suivante :
hosts local
4-72
Guide de gestion du système – Communications et réseaux
Autrement, la variable NSORDER peut être renseignée comme suit :
NSORDER=local
Si le réseau local est “hiérarchique” et fait appel à un serveur de noms pour la résolution
des noms et à un fichier /etc/hosts pour une copie de secours, les deux services doivent
être spécifiés. Dans cet exemple, le fichier /etc/irs.conf contiendrait les lignes suivantes :
hosts dns continue
hosts local
Et la variable NSORDER est renseignée comme suit :
NSORDER=bind,local
Remarque :
les valeurs doivent être spécifiées en minuscules.
En suivant un ordre de résolution défini ou l’ordre par défaut, l’algorithme de recherche ne
passe d’une routine à la suivante que si :
• le service courant n’est pas accessible (il n’est pas actif),
• le service courant ne trouve pas le nom recherché et n’est pas un serveur “expert”.
Si le fichier /etc/resolv.conf n’existe pas, le mécanisme BIND/DNS est considéré comme
non installé, et par là–même non accessible. En cas d’échec des sous–routines
getdomainname et yp_bind, le service NIS est considéré comme non installé et par
là–même non accessible. Si le fichier /etc/hosts n’a pas pu être ouvert, il est impossible de
procéder à une recherche locale et d’accéder au fichier et au service.
Un service est dit expert si, de par les informations qu’il contient, il est jugé mieux à même
de répondre aux requêtes que les services cités après lui. Les routines de résolution
n’essaient pas les services suivants, puisque ces derniers ne peuvent contenir qu’un
sous–ensemble des informations du service expert. La résolution des noms s’arrête à la
consultation du service expert même s’il n’est pas parvenu à fournir le nom demandé
(message HOST_NOT_FOUND renvoyé). En cas d’indisponibilité d’un service expert, le
service suivant spécifié est interrogé.
La source “expert” est déclarée par la chaîne ”=auth” spécifiée à la suite de son nom.
Il est possible de spécifier également tout le mot ”authoritative”. Par exemple, si la
variable NSORDER contient :
hosts = nis=auth,dns,local
Si NIS est actif, la recherche prend fin après consultation de NIS, que le nom ait été trouvé
ou non. Si NIS n’est pas actif, elle est étendue à la source suivante (en l’occurrence, DNS).
Les serveurs de noms TCP/IP ont recours à la mémoire cache pour réduire le coût de
recherche de noms d’hôte sur réseaux distants. Ainsi, ils consultent d’abord la mémoire
cache où se trouvent les équivalences des derniers noms résolus. Ces équivalences sont
conservées en mémoire pour une durée limitée (définie dans le paramètre TTL
“Time-To-Live” de l’article de ressource), les noms de domaine et d’hôtes pouvant être
modifiés. Les serveurs de noms sont donc en mesure de spécifier la durée pendant laquelle
leurs réponses sont réputées fiables.
Risques de conflits de noms d’hôte
En environnement DNS, un nom d’hôte défini soit par la commande hostname en ligne de
commande, soit par le fichier rc.net, doit être le nom officiel de l’hôte tel qu’il est renvoyé
par le serveur de noms. Ce nom est généralement le nom complet du domaine de l’hôte
sous la forme :
host.subdomain.subdomain.rootdomain
Remarque :
pour les routines de résolution, le domaine par défaut doit être défini.
S’il n’est pas défini dans hostname, il doit l’être dans /etc/resolv.conf.
Protocole TCP/IP
4-73
Si le nom de l’hôte n’est pas configuré en nom complet du domaine, et si le système est
configuré avec serveur de noms de domaine associé au programme sendmail, le fichier de
configuration /etc/sendmail.cf doit être modifié conformément à ce nom officiel. Pour que le
programme sendmail fonctionne correctement, il faut de plus que les macros de nom de
domaine soient définies dans cette configuration.
Remarque :
pour toutes les fonctions de sendmail, le domaine spécifié dans le
fichier /etc/sendmail.cf prime sur celui défini à la commande
hostname.
Risques de conflits de noms de domaine
Dans le cas d’un hôte membre d’un réseau DOMAIN mais qui n’est pas un serveur de
noms, le nom de domaine local et le serveur de noms de domaine sont spécifiés dans le
fichier /etc/resolv.conf. Or, dans un hôte serveur de noms de domaine, le domaine local et
les autres serveurs de noms sont définis dans des fichiers que le démon named lit à son
lancement.
Protocole RARP
Le protocole RARP (Reverse Address Resolution Protocol) traduit les adresses matérielles
uniques en adresses Internet sur la carte LAN Ethernet (protocole Ethernet seulement).
Le protocole Ethernet standard est pris en charge dans les limites suivantes :
• Le serveur répond uniquement aux requêtes RARP.
• Le serveur se limite aux entrées permanentes de la table ARP
• Le serveur n’utilise pas les entrées dynamiques de la table ARP.
• Le serveur ne répond pas automatiquement pour lui–même.
L’administrateur système doit créer et tenir à jour manuellement une table des entrées
permanentes ARP à l’aide de la commande arp. Une entrée de table ARP spécifique doit
être ajoutée sur le serveur pour chaque hôte qui sollicite des réponses RARP d’une source
“expert”.
Résolution locale des noms (/etc/hosts)
Le fichier /etc/hosts doit être configuré si vous travaillez sur un réseau limité et plat.
Cette configuration peut également être utile sur un réseau hiérarchique pour identifier les
hôtes inconnus des serveurs de noms.
Vous pouvez configurer votre système en vue de la résolution locale de noms via
Web–based System Manager, SMIT ou les commandes. Si c’est à partir de la ligne de
commande, veillez à conserver le format du fichier /etc/hosts, comme indiqué à la section
”Hosts File Format for TCP/IP” du manuel AIX 5L Version 5.3 Files Reference).
Résolution locale des noms
4-74
Tâche
Raccourci SMIT
Commande ou
fichier
Web–based System
Manager Management
Environment
Afficher la liste
des hôtes
smit lshostent
affichez
/etc/hosts
Software ––> Network ––>
TCPIP (IPv4 and IPv6) ––>
TCPIP Protocol
Configuration ––> TCP/IP
––> Configure TCP/IP ––>
Advanced Methods ––>
Hosts File ––> Contents of
/etc/hosts file.
Guide de gestion du système – Communications et réseaux
Ajouter un hôte
smit mkhostent
éditez /etc/hosts
Software ––> Network ––>
TCPIP (IPv4 and IPv6) ––>
TCPIP Protocol
Configuration ––> TCP/IP
––> Configure TCP/IP ––>
Advanced Methods ––>
Hosts File. Dans la boîte de
dialogue Add/Change host
entry, complétez les champs
suivants : IP Addresses, Host
name, Alias(es) et Comment.
Cliquez sur Add/Change
Entry ––> OK.
Modifier/afficher
les
caractéristiques
d’un hôte
smit chhostent
éditez /etc/hosts
Software ––> Network ––>
TCPIP (IPv4 and IPv6) ––>
TCPIP Protocol
Configuration ––> TCP/IP
––> Configure TCP/IP ––>
Advanced Methods ––>
Hosts File. Sélectionnez un
hôte dans Contents of
/etc/hosts/file, puis changez
les données dans
Add/Change host entry.
Cliquez sur Add/Change
Entry ––> OK.
Supprimer un
hôte
smit rmhostent
éditez /etc/hosts
Software ––> Network ––>
TCPIP (IPv4 and IPv6) ––>
TCPIP Protocol
Configuration ––> TCP/IP
––> Configure TCP/IP ––>
Advanced Methods ––>
Hosts File. Sélectionnez un
hôte dans Contents of
/etc/hosts/file, puis cliquez
sur Delete Entry ––> OK.
Préparation à la résolution DNS (DOMAIN)
Si vous faites partie d’un interréseau étendu, coordonnez vos serveurs de noms et
domaines avec leur autorité centrale.
Les conseils suivants vous aideront à configurer votre système pour la résolution DSN :
• Familiarisez–vous avec TCP/IP, DNS et BIND et les nombreuses fonctionnalités de leur
architecture et de leur configuration avant d’arrêter votre choix. Avant d’utiliser un service
d’information réseau (NIS), familiarisez–vous également avec NIS. Vous disposez pour
cela de nombreux documents. Pour plus d’informations sur les caractéristiques de NIS et
de NIS+, reportez–vous au AIX 5L Version 5.3 NIS/NIS+
(Network Information Services) Guide.
• Planifiez la configuration.
Rappelez-vous qu’il est plus compliqué de changer un nom que de le définir. Avant de
configurer vos fichiers, décidez (en accord avec votre organisation) des noms des hôtes,
du réseau, de la passerelle et du serveur de noms.
• Définissez des serveurs de noms redondants.
A défaut, veillez à définir des serveurs de noms esclaves et des serveurs d’indices pour
disposer d’un système de secours.
Protocole TCP/IP
4-75
• Pour la sélection des serveurs de noms :
– choisissez les machines géographiquement les plus proches des systèmes
extérieurs ;
– vos serveurs de noms doivent être aussi indépendants que possible. Si possible,
utilisez des alimentations électriques et des câblages distincts.
– désignez un autre réseau comme réseau de secours pour votre service de résolution
des noms ; faites de même pour les autres réseaux.
• testez les serveurs :
– testez la résolution des noms normale et inverse,
– testez le transfert de zone du serveur de noms maître au serveur de noms esclave,
– testez chaque serveur de noms, après une panne et un réamorçage du système.
• Faites transiter vos requêtes de résolution de noms par des serveurs expéditeurs avant
de les envoyer vers des serveurs de noms extérieurs. Cela permet aux serveurs de noms
de partager leur mémoire cache et d’améliorer les performances en allégeant la charge
des serveurs de noms maîtres.
objectclass: container
requires
objectclass,
cn
objectclass hosts
requires
objectclass,
hname
allows
addr
halias,
comment
Serveur de noms : généralités
Dans un réseau hiérarchisé, certains hôtes sont définis comme serveurs de noms.
Ces hôtes résolvent les noms en adresses IP pour les autres hôtes. The Le démon named
contient la fonction du serveur de noms et doit donc être exécuté sur un hôte de serveur
de noms.
Avant de procéder à la configuration, déterminez les types de serveur de noms les mieux
adaptés à votre réseau. Il existe trois types :
Leurs noms, défini dans le fichier conf, peut être modifié par l’utilisateur. Par convention, ce
nom comporte celui du démon (named) avec, en extension, le type de fichier et le nom du
domaine. Serveur de noms esclave ou serveur de noms de tronçon (stub) : ceux–ci
reçoivent leurs informations d’un serveur maître au démarrage du système pour une zone
d’autorité donnée, puis l’interrogent périodiquement pour les mettre à jour. Serveur d’indices
(hint server) : ce serveur répond aux requêtes de résolution des noms en demandant les
informations souhaitées auprès d’autres serveurs experts.
Remarque :
les générations antérieures du serveur de noms named définissaient le
serveur maître comme serveur de noms primaire, le serveur esclave
comme serveur de noms secondaire, et le serveur d’indices comme serveur
de mémoire cache. Dans cette documentation, toute référence au fichier
named.conf est spécifique à version 4.3.2 ou versions ultérieures.
Rappelons qu’un serveur de noms peut exercer des fonctions différentes selon les zones
d’autorité. resolv.conf Ce fichier indique par sa présence que l’hôte doit d’abord faire appel
à un serveur de noms pour effectuer une résolution. Si NIS ou NIS+ est installé sur votre
système, ces services peuvent également vous aider à la résolution des noms. Pour plus
d’informations, reportez–vous au AIX 5L Version 5.3 Network Information Services
(NIS and NIS+) Guide.
4-76
Guide de gestion du système – Communications et réseaux
Plusieurs fichiers sont impliqués dans la configuration des serveurs de noms.
conf
Fichier lu au démarrage du démon named. Les articles du fichier conf
indiquent au démon named le type du serveur, ses zones d’autorité
(domaines) et l’implantation des données pour la configuration initiale de
sa base de données. Son nom par défaut est /etc/named.conf. Vous
pouvez lui en attribuer un autre en indiquant sur la ligne de commande le
nouveau nom complet dès le lancement du démon named. Si vous utilisez
pour l’amorçage le fichier /etc/named.conf, mais que ce dernier n’existe
pas, un message est généré dans syslog et le démon named s’arrête.
Toutefois, si un autre fichier conf a été prévu et qu’il n’existe pas, il n’y
aura pas de message d’erreur et le démon named continuera.
cache
Fichier contenant les informations sur la mémoire cache locale : nom et
adresse des serveurs de noms bénéficiant de la plus haute “autorité”.
Ce fichier respecte le format des articles de ressource standard (Standard
Resource Record Format). Son nom est défini dans le fichier conf.
domain data Il existe trois types de fichiers domain data, également nommés fichiers
de données named. Le fichier named local contient les informations de
résolution d’adresses en bouclage local. Le fichier de données named
contient les données de résolution d’adresses pour toutes les machines
de la zone d’autorité du serveur de noms. Le fichier de données inversées
named contient les informations de résolution inversée d’adresses pour
toutes les machines de la zone d’autorité du serveur de noms. Ces trois
fichiers respectent le format des articles de ressource standard (Standard
Resource Record Format). Leurs noms, défini dans le fichier conf, peut
être modifié par l’utilisateur. Par convention, ce nom comporte celui du
démon (named) avec, en extension, le type de fichier et le nom du
domaine. Par exemple, les fichiers du serveur de noms du domaine abc
peuvent être :
named.abc.data
named.abc.rev
named.abc.local
En modifiant les fichiers de données named, il est conseillé d’incrémenter
le numéro de série donné dans l’article SOA pour les serveurs de noms
esclaves afin d’effectuer correctement les modifications de zones.
resolv.conf
Ce fichier indique par sa présence que l’hôte doit d’abord faire appel à un
serveur de noms pour effectuer une résolution. En l’absence de
resolv.conf, l’hôte fait ensuite appel au fichier /etc/hosts. Obligatoire sur
un serveur de noms, le fichier resolv.conf peut contenir l’adresse de l’hôte
local, l’adresse de bouclage (127.0.0.1), ou être vide.
Remarque :
Pour les routines de résolution, le domaine par défaut doit être défini.
S’il n’est pas défini dans /etc/resolv.conf, il doit l’être dans hostname.
Le paramètre TTL (Time-To-Live) est spécifié dans les articles de ressource. A défaut, le
délai appliqué est la plus petite valeur définie dans l’article SOA (Start Of Authority) de la
zone d’autorité concernée. TTL est utilisé lorsque les données sont stockées en dehors
d’une zone (en mémoire cache) pour s’assurer qu’elles n’y sont pas maintenues
indéfiniment.
Configuration des serveurs de noms
Pour savoir comment configurer les serveurs maître, esclave et d’indices,
reportez–vous à Configurer les serveurs de noms de domaines, page 1-23.
Protocole TCP/IP
4-77
Configuration d’un serveur de courrier de domaine
En définissant un serveur de courrier de domaine, vous mettez à la disposition des
utilisateurs externes une méthode d’adressage simple leur permettant de correspondre
avec votre organisation. Sans cela, l’adresse doit obligatoirement préciser un hôte
particulier de votre organisation. Par exemple, [email protected], widget.com
étant le nom de domaine de votre organisation, et orange l’hôte utilisé par sam. Avec le
serveur de courrier de domaine, il suffit à l’utilisateur externe d’indiquer le nom de
l’utilisateur et le nom du domaine sans le nom de l’hôte, dans notre exemple,
[email protected].
Vous pouvez configurer un serveur de courrier via le raccourci Web–based System
Manager wsm ou via l’une des procédures suivantes.
Configuration d’un serveur de courrier de domaine
1. Créez un article MX et un article A pour le serveur de courrier (black.widget.com) :
widget.com
widget.com
black.widget.com
IN
IN
IN
MX
A
A
10 black.widget.com
192.10.143.9
192.10.143.9
2. Editez sendmail.cf sur le serveur de courrier (black.widget.com) pour ajouter l’alias
du domaine (classe w) :
Cw $w $?D$w.$D$. widget.com
3. Les clients de la messagerie doivent savoir où adresser leur courrier non local. Editez
sendmail.cf sur chaque client pour pointer sur le serveur de courrier (macro S) :
DRblack.widget.com
4. A l’aide de l’option NameServOpt, configurez le démon sendmail de sorte que chacun
puisse utiliser les articles MX définis dans le serveur de noms brown.widget.com.
5. Ajoutez l’alias des utilisateurs du domaine qui n’ont pas de compte sur le serveur de
courrier, en vous aidant du fichier d’alias.
sam:[email protected]
david:[email protected]
judy:[email protected]
Remarque :
les articles MB peuvent remplir la même fonction.
6. La base de données ayant été modifiée, il est conseillé d’incrémenter le numéro de série
donné dans l’article SOA.
7. Régénérez la base de données du serveur de noms via la commande
refresh –s named.
8. Sur les clients, exécutez la commande refresh –s sendmail pour prendre les
modifications en compte.
Il existe d’autres méthodes permettant de configurer un serveur de courrier de domaine.
Les procédures qui suivent utilisent les articles MB, MR et MG.
Configuration d’un serveur de courrier de domaine avec des articles MB
1. Définissez un article MB pour chaque utilisateur du domaine. Par exemple :
sam IN MB orange.widget.com.
dans le fichier /usr/named.data de l’hôte brown.widget.com. Cette instruction stipule
le serveur de courrier (black.widget.com ) destinataire pour chaque utilisateur du
domaine.
2. Configurez le démon sendmail sur le serveur de courrier (black.widget.com) pour
qu’il utilise les articles MB définis sur le serveur de noms (brown.widget.com).
Ayez recours à l’option NameServOpt.
4-78
Guide de gestion du système – Communications et réseaux
3. La base de données ayant été modifiée, il est conseillé d’incrémenter le numéro de série
donné dans l’article SOA.
4. Régénérez la base de données du serveur de noms via la commande
refresh –s named.
5. Tapez la commande refresh –s sendmail pour prendre les modifications en compte.
Définition d’un article MR (Mail Rename)
1. Editez le fichier /usr/named.data sur votre serveur de noms de domaine.
2. Ajoutez un article MR pour chaque alias. Par exemple, l’utilisateur sam dont l’alias est
sammy aura pour article MR :
sammy IN MR sam
Cet article demande que tous les messages adressés à sammy soient livrés à sam.
Il faut prévoir une ligne par article MR.
3. La base de données ayant été modifiée, il est conseillé d’incrémenter le numéro de série
donné dans l’article SOA.
4. Régénérez la base de données du serveur de noms via la commande
refresh –s named.
5. Tapez la commande refresh –s sendmail pour prendre les modifications en compte.
Définition d’un article MG (Mail Group)
1. Editez le fichier /etc/named.data sur votre serveur de noms de domaine.
2. Ajoutez des articles MG pour chaque groupe courrier. Ces articles fonctionnent comme
le fichier /usr/aliases, les alias étant tenus à jour sur le serveur de noms. Par exemple :
users IN HINFO users-request widget.com
users IN MG sam
users IN MG david
users IN MG judy
Ces articles demandent que tous les messages adressés à [email protected] soient
livrés à sam, david et judy. Il faut prévoir une ligne par article MG.
Remarque :
des articles MB doivent avoir été définis pour sam, david et judy.
3. La base de données ayant été modifiée, il est conseillé d’incrémenter le numéro de série
donné dans l’article SOA.
4. Régénérez la base de données du serveur de noms via la commande
refresh –s named.
5. Entrez la commande sendmail –bz pour recompiler le fichier sendmail.cf sur le serveur
de courrier, puis la commande refresh -s sendmail pour appliquer les modifications.
Définition d’articles MX (Mail Exchanger)
1. Editez le fichier /usr/named.data sur votre serveur de noms de domaine.
2. Ajoutez des articles MX pour chaque machine indirectement connectée à votre réseau et
avec laquelle vous souhaitez correspondre. Par exemple, si le courrier adressé aux
utilisateurs de purple.widget.com doit être transmis à post.office.widget,
ajoutez un article MX comme suit :
purple.widget.com IN MX 0 post.office.widget.
Lorsque vous utilisez les articles d’échangeur de courrier (MX), vous devez spécifier le
nom de la machine et le nom d’hôte. Il faut prévoir une ligne par article MX. L’utilisation
des caractères génériques est admise :
*.widget.com IN MX 0 post.office.widget.
Protocole TCP/IP
4-79
Ces articles demandent que les messages adressés à un hôte inconnu (sans article MX
explicite) du domaine widget.com soient expédiés à post.office.widget.
Remarque :
les caractères génériques dans les articles MX sont incompatibles avec
l’utilisation d’Internet.
3. La base de données ayant été modifiée, il est conseillé d’incrémenter le numéro de série
donné dans l’article SOA.
4. Régénérez la base de données du serveur de noms via la commande refresh –s
named.
5. Tapez la commande refresh –s sendmail pour prendre les modifications en compte.
Configuration d’un serveur expéditeur
Pour configurer un expéditeur, utilisez le raccourci Web–based System Manager wsm ou
suivez la procédure ci–dessous, qui édite une série de fichiers puis a recours à SMIT ou à
la ligne de commande pour démarrer le démon named.
1. Editez le fichier /etc/named.conf. Si le répertoire /etc ne contient pas de fichier
named.conf, copiez-y le fichier-type /usr/samples/tcpip/named.conf et éditez-le.
Pour en savoir plus et examiner un exemple de fichier de configuration, reportez-vous
à la section ”named.boot File Format for TCP/IP” dans le manuel AIX 5L Version
5.3 Files Reference.
– Insérez une ligne “forwarders” dans la strophe d’options du fichier /etc/named.conf
indiquant toutes les adresses IP des serveurs de noms auxquels des requêtes doivent
être expédiées. Par exemple :
options {
...
directory ”/usr/local/domain”;
forwarders { 192.100.61.1; 129.35.128.222; };
...
};
– Spécifiez la zone de bouclage. Par exemple :
zone ”0.0.127.in–addr.arpa” in {
type master;
file ”named.abc.local”;
};
– Spécifiez la zone d’indices. Par exemple :
zone ”.” IN {
type hint;
file ”named.ca”;
};
2. Editez le fichier /usr/local/domain/named.ca Pour en savoir plus et disposer d’un
exemple de fichier cache, reportez–vous à la section “DOMAIN Cache File Format
for TCP/IP” dans le manuel AIX 5L Version 5.3 Files Reference.
Ce fichier contient l’adresse des serveurs de noms “experts” pour le domaine racine
(root) du réseau. Par exemple :
; root name servers.
.
IN
NS
relay.century.com.
relay.century.com.
3600000
IN
A
Remarque :
129.114.1.2
toutes les lignes de ce fichier doivent respecter le format des articles
de ressource standard (Standard Resource Record Format).
3. Editez le fichier /usr/local/domain/named.abc.local. Pour en savoir plus et disposer
d’un exemple de fichier de données local, reportez–vous à la section “ DOMAIN Local
Data File Format for TCP/IP ” dans le manuel AIX 5L Version 5.3 Files Reference.
4-80
Guide de gestion du système – Communications et réseaux
a. Spécifiez pour la zone la valeur de SOA (Start Of Authority) et les délais TTL
(time–to–live) par défaut. Par exemple :
$TTL 3h
;3 hour
@ IN SOA venus.abc.aus.century.com. gail.zeus.abc.aus.century.com.
(
1
;serial
3600
;refresh
600
;retry
3600000 ;expire
86400
;negative caching TTL
)
b. Spécifiez l’article NS (serveur de noms). Par exemple :
IN
<tab>
NS
venus.abc.aus.century.com.
c. Spécifiez l’article PTR (pointeur).
1
IN
Remarque :
PTR
localhost.
toutes les lignes de ce fichier doivent respecter le format des articles
de ressource standard (Standard Resource Record Format).
4. Créez un fichier /etc/resolv.conf via la commande :
touch /etc/resolv.conf
Ce fichier indique par sa présence que l’hôte doit d’abord faire appel à un serveur de
noms pour effectuer une résolution, et non au fichier /etc/hosts.
Autrement, le fichier /etc/resolv.conf peut contenir l’entrée suivante :
nameserver 127.00.0.1
127.0.0.1 est l’adresse de bouclage qui, pour l’accès au serveur de noms, dirige l’hôte
vers lui-même. Ce fichier /etc/resolv.conf peut également comporter une ligne du type :
domain
NomDomaine
Dans cet exemple, NomDomaine serait austin.century.com.
5. Exécutez l’une des tâches suivantes :
– Activez le démon named en utilisant le raccourci SMIT smit stnamed. Cette
commande initialise le démon à chaque lancement du système. Indiquez quand vous
souhaitez lancer le démon named : immédiatement, au prochain lancement du
système ou les deux.
– Editez le fichier /etc/rc.tcpip. Activez le démon named en retirant la marque de
commentaire (#) de la ligne suivante :
#start /etc/named ”$src_running”
Cette commande initialise le démon à chaque lancement du système.
6. Si vous ne souhaitez pas initialiser le démon named via SMIT, lancez-le pour la session
en cours par la commande :
startsrc -s named
Configuration de serveur exclusivement expéditeur
Pour configurer un serveur de noms esclave, utilisez le raccourci Web–based System
Manager wsm ou suivez la procédure ci–dessous, qui édite une série de fichiers puis a
recours à SMIT ou à la ligne de commande pour démarrer le démon named.
Remarque :
vous pouvez obtenir une configuration similaire sans exécuter de serveur
de noms exclusivement expéditeur. Il suffit de créer un fichier
/etc/resolv.conf en insérant des lignes de serveur de noms qui pointent
vers les serveurs expéditeurs souhaités.
Protocole TCP/IP
4-81
1. Editez le fichier /etc/named.conf. Si le répertoire /etc ne contient pas de fichier
named.conf, copiez-y le fichier-type /usr/samples/tcpip/named.conf et éditez-le. Pour
en savoir plus et examiner un exemple de fichier de configuration, reportez-vous à la
section ”named.boot File Format for TCP/IP” dans le manuel AIX 5L Version 5.3 Files
Reference.
– Insérez les lignes “forwarders” et “forward only” dans la strophe d’options du fichier
/etc/named.conf indiquant toutes les adresses IP des serveurs de noms auxquels des
requêtes doivent être expédiées. Par exemple :
options {
...
directory ”/usr/local/domain”;
forwarders { 192.100.61.1; 129.35.128.222; };
forward only;
...
};
– Spécifiez la zone de bouclage. Par exemple :
zone ”0.0.127.in–addr.arpa” in {
type master;
file ”named.abc.local”;
};
– Spécifiez la zone d’indices. Par exemple :
zone ”.” IN {
type hint;
file ”named.ca”;
};
2. Editez le fichier /usr/local/domain/named.ca Pour en savoir plus et disposer d’un
exemple de fichier cache, reportez–vous à la section DOMAIN Cache File Format for
TCP/IP dans le manuel AIX 5L Version 5.3 Files Reference. Ce fichier contient l’adresse
des serveurs de noms “experts” pour le domaine racine (root) du réseau. Par exemple :
; root name servers.
.
IN
NS
relay.century.com.
relay.century.com.
3600000
IN
A
Remarque :
129.114.1.2
toutes les lignes de ce fichier doivent respecter le format des articles de
ressource standard (Standard Resource Record Format).
3. Editez le fichier /etc/named.local. Pour en savoir plus et disposer d’un exemple de
fichier de données local, reportez-vous à la section ”DOMAIN Local Data File Format for
TCP/IP” dans le manuel AIX 5L Version 5.3 Files Reference.
a. Spécifiez pour la zone la valeur de SOA (Start Of Authority) et les délais TTL
(time-to-live) par défaut. Par exemple :
$TTL 3h
;3 hour
@ IN SOA venus.abc.aus.century.com. gail.zeus.abc.aus.century.com.
1
3600
600
3600000
86400
;serial
;refresh
;retry
;expire
;negative caching TTL
)
b. Spécifiez l’article NS (serveur de noms). Par exemple :
<tab>
IN
NS
venus.abc.aus.century.com.
c. Spécifiez l’article PTR (pointeur).
Remarque :
4-82
toutes les lignes de ce fichier doivent respecter le format des articles
de ressource standard ( Standard Resource Record Format).
Guide de gestion du système – Communications et réseaux
(
4. Créez un fichier /etc/resolv.conf via la commande :
touch /etc/resolv.conf
Ce fichier indique par sa présence que l’hôte doit d’abord faire appel à un serveur de
noms pour effectuer une résolution, et non au fichier /etc/hosts.
Autrement, le fichier /etc/resolv.conf peut contenir l’entrée suivante :
nameserver 127.00.0.1
127.0.0.1 est l’adresse de bouclage qui, pour l’accès au serveur de noms, dirige l’hôte
vers lui-même. Ce fichier /etc/resolv.conf peut également comporter une ligne du type :
domain
NomDomaine
Dans cet exemple, NomDomaine serait austin.century.com.
5. Exécutez l’une des tâches suivantes :
– Activez le démon named en utilisant le raccourci SMIT smit stnamed. Cette
commande initialise le démon à chaque lancement du système. Indiquez quand vous
souhaitez lancer le démon named : immédiatement, au prochain lancement du
système ou les deux.
– Editez le fichier /etc/rc.tcpip. Activez le démon named en retirant la marque de
commentaire (#) de la ligne suivante :
#start /etc/named ”$src_running”
Cette commande initialise le démon à chaque lancement du système.
6. Si vous ne souhaitez pas initialiser le démon named via SMIT, lancez-le pour la session
en cours par la commande :
startsrc -s named
Configuration d’un hôte avec serveur de noms
Vous pouvez configurer un hôte pour un serveur de noms via le raccourci Web–based
System Manager, wsm ou via l’une des procédures suivantes.
1. Créez un fichier /etc/resolv.conf via la commande :
touch /etc/resolv.conf
2. Sur la première ligne du fichier /etc/resolv.conf, entrez le mot domain puis le nom
complet du domaine auquel appartient l’hôte. Par exemple :
domain abc.aus.century.com
3. Sur une ligne vierge après la ligne introduite par domain, entrez le mot nameserver
suivi d’au moins un espace et de l’adresse Internet (en notation décimale à points) du
serveur de noms à ajouter (il doit desservir le domaine indiqué dans l’instruction
domain). Vous pouvez insérer jusqu’à 3 entrées de serveur de noms. Par exemple,
votre fichier /etc/resolv.conf peut contenir les entrées :
nameserver 192.9.201.1
nameserver 192.9.201.2
Le système interroge les serveurs dans l’ordre de leur spécification.
search domainname_list
Le mot–clé de recherche peut aussi être utilisé pour indiquer l’ordre dans lequel le
programme de résolution interrogera la liste des domaines. Dans ce cas, les valeurs de
domainname_list sont abc.aus.century.com et aus.century.com.
domainname_list peut contenir au maximum six noms de domaines, chacun séparés
par un espace.
Protocole TCP/IP
4-83
4. En supposant que le serveur de noms est opérationnel, vous pouvez tester sa
communication avec l’hôte via la commande suivante :
host hostname
Indiquez un nom d’hôte que le serveur doit résoudre. Si le processus aboutit,
vous obtenez un résultat du type :
brown.abc.aus.century.com is 129.35.145.95
D’autres tâches de configuration sont présentées dans le tableau suivant.
Configuration d’un hôte avec serveur de noms
4-84
Tâche
Raccourci SMIT
Commande ou
fichier
Créer un fichier
/etc/resolv.conf.
smit stnamerslv2
créez et éditez
/etc/resolv.conf1
Web–based System Manager
Management Environment
Afficher la liste des smit lsnamerslv
serveurs utilisés
par un hôte
affichez
/etc/resolv.conf
Software ––> Network ––>
TCPIP (IPv4 and IPv6) ––>
TCPIP Protocol Configuration
––> TCP/IP ––> Configure
TCP/IP ––> Advanced
Methods ––> Hosts File ––>
Contents of /etc/hosts file.
Ajouter un serveur
de noms
smit mknamerslv
éditez
/etc/resolv.conf 2
Software ––> Network ––>
TCPIP (IPv4 and IPv6) ––>
TCPIP Protocol Configuration
––> TCP/IP ––> Configure
TCP/IP ––> Advanced
Methods ––> DNS. Dans le
champ Name Server IP
Address, tapez l’Adresse IP.
Cliquez sur Add ––> OK.
Supprimer un
serveur de noms
smit rmnamerslv
éditez
/etc/resolv.conf
Remarques :
Software ––> Network ––>
TCPIP (IPv4 and IPv6) ––>
TCPIP Protocol Configuration
––> TCP/IP ––> Configure
TCP/IP ––> Advanced
Methods ––> DNS.
Sélectionnez un serveur de nom
dans Name server to search.
Cliquez sur Delete ––> OK.
Activer/Réactiver
la résolution DNS
smit stnamerslv
Guide de gestion du système – Communications et réseaux
Software ––> Network ––>
TCPIP (IPv4 and IPv6) ––>
TCPIP Protocol Configuration
––> TCP/IP ––> Configure
TCP/IP ––> Advanced
Methods ––> DNS. Cochez la
case Enable domain name
resolution using Domain
Name Service (DNS). Cliquez
sur OK.
Tâche
Raccourci SMIT
Désactiver la
résolution DNS
smit spnamerslv
Commande ou
fichier
Web–based System Manager
Management Environment
Software ––> Network ––>
TCPIP (IPv4 and IPv6) ––>
TCPIP Protocol Configuration
––> TCP/IP ––> Configure
TCP/IP ––> Advanced
Methods ––> DNS. Décochez la
case Enable domain name
resolution using Domain
Name Service (DNS). Cliquez
sur OK.
Modifier/Afficher le smit mkdomain
domaine
éditez
/etc/resolv.conf
Remarques :
Software ––> Network ––>
TCPIP (IPv4 and IPv6) ––>
TCPIP Protocol Configuration
––> TCP/IP ––> Configure
TCP/IP ––> Advanced
Methods ––> DNS. ––>
Domain name to search.
Cliquez sur Add ––> OK.
Supprimer un
domaine
éditez
/etc/resolv.conf
Remarques :
Software ––> Network ––>
TCPIP (IPv4 and IPv6) ––>
TCPIP Protocol Configuration
––> TCP/IP ––> Configure
TCP/IP ––> Advanced
Methods ––> DNS.
Sélectionnez un domaine dans
la liste Domain search list.
Cliquez sur Delete ––> OK.
smit rmdomain
Configuration de zones dynamiques sur le serveur de noms DNS
La commande named autorise les mises à jour dynamiques. La base de données nommée
et les fichiers de configuration doivent être configurés pour permettre aux machines clientes
d’émettre des mises à jour. Une zone peut être dynamique ou statique. La zone par défaut
est statique.
Pour rendre une zone dynamique, il faut ajouter le mot clé allow–update à la strophe
correspondante du fichier /etc/named.conf file. Ce mot clé précise la liste de
correspondances d’adresses Internet définissant les hôtes autorisés à soumettre des
mises à jour. Pour en savoir plus et examiner un exemple de fichier de configuration,
reportez-vous à la section ”named.boot File Format for TCP/IP” dans le manuel AIX 5L
Version 5.3 Files Reference. Dans l’exemple ci–dessous, la mise à jour de la zone
dynamique est autorisée à tous les hôtes :
zone ”abc.aus.century.com” IN {
type master;
file ”named.abc.data”;
allow–update { any; };
};
Protocole TCP/IP
4-85
Sur une zone dynamique, trois modes de sécurité peuvent être définis :
Non sécurisé
N’importe qui peut, à tout moment, mettre à jour les
informations de la zone.
Attention : il est déconseillé d’opter pour ce mode.
Des données risquent d’être perdues ou interceptées,
et l’utilisateur frustré. Il convient au minimum de limiter
la mise à jour d’une zone non sécurisée (”unsecured”)
à des adresses Internet spécifiques.
Contrôlé
Autorise la création d’informations et le remplacement
de données existantes. C’est sans doute le mode le plus
adapté à un environnement de transition sécurisé. Ce
mode requiert également que les données entrantes
soient horodatées et munies d’une signature à clé.
Pré–securisé
Impose que les mises à jour remplacent les informations
existantes par des informations similaires. Ne permet pas
de créer de nouvelles informations. Ce mode requiert
également que les données entrantes soient horodatées
et munies d’une signature à clé.
Par défaut, une zone dynamique se trouve en mode non sécurisé. Pour utiliser l’un des
autres modes, tapez controlled ou presecured après le mot de passe update–security
dans la zone de strophe du fichier /etc/named.conf file. Cela indique au serveur named le
niveau de sécurité à utiliser pour cette zone. Par exemple :
zone ”abc.aus.century.com” IN {
type master;
file ”named.abc.data”;
allow–update { any; };
update–security controlled;
};
Une fois le mode sélectionné, les fichiers de données doivent être amenés au niveau de
sécurité choisi. En mode non sécurisé, les fichiers de données sont utilisés tels quels. En
mode contrôlé ou pré–sécurisé, vous devez créer un ensemble de paires de clés entre
noms de serveur maîtres et hôtes pour chaque nom de la zone. Utilisez pour cela la
commande nsupdate avec l’option –g. Cette commande génère la paire de clés, une privée
et une publique. Ces clés sont nécessaires pour authentifier les mises à jour. Après avoir
créé toutes les clés pour la liste de noms de zones, il faut les ajouter au fichier de données.
Le format de clé (KEY) est le suivant :
Index
ttl
Class
Type
KeyFlags
Protocol
Algorithm
KeyData
où :
4-86
Index
Nom référençant les données de la zone.
ttl
ttl (”time to live”) des données. Ce champ est facultatif.
Classe
Classe des données. Dépend de la zone, mais généralement IN.
Type
Type de l’enregistrement. Dans ce cas, le type est KEY.
IndicClé
Informations sur la clé. En général, l’enregistrement de clé pour un hôte
est sous la forme 0x0000. Le code 0x0100 définit l’enregistrement de clé
associé au nom de zone.
Protocole
Protocole à utiliser. Pour le moment, il n’y en a qu’un, 0.
Guide de gestion du système – Communications et réseaux
Algorithme
Algorithme de la clé. Pour le moment, il n’y en a qu’un, 1. Cette méthode
est celle de l’authentification privé/public.
DonnéesClé
Clé exprimée en base 64. La commande nsupdate génère les deux clés
(publique et privée) en base 64. Dans le fichier de sortie, la clé publique
apparaît en dernier.
Exemple
Pour garantir la sécurité d’un nom d’hôte dans une zone dynamique, il faut ajouter au fichier
de zone une ligne du type ci–dessous pour la zone contenant ce nom :
bears
4660
IN
KEY
0x0000
0
1
AQOtg......
Dans cet exemple, bears est doté d’un enregistrement KEY défini : toute personne
souhaitant mettre à jour bears doit signer sa mise à jour avec la clé privée correspondant à
la clé publique enregistrée dans la base de données. Pour que la commande nsupdate
agisse, cette clé privée doit figurer dans un fichier de clé chez le client (fichier /etc/keyfile
par défaut). Son format est le suivant :
hostname
mastername
base64
key
Une entrée similaire KEY doit se trouver dans la section de définition de la zone. La clé de
zone est obligatoire en mode pré–sécurisé ou contrôlé : sans clé, le mode est
considéré non sécurisé. L’exemple bears précédent montre comment procéder, mais
l’utilisation de clé privée revient à l’administrateur qui utilise la commande nsupdate en
mode administrateur.
1. Pour générer une paire de clés avec la commande nsupdate, entrez :
nsupdate –g –h
FichierCléAdmin
NomZone
–p
NomServeur
–k
Une clé est générée pour la zone. Dans cet exemple, nsupdate est lié à nsupdate4, en
tapant ce qui suit :
ln –fs /usr/sbin/nsupdate4 /usr/sbin/nsupdate
2. Placez la dernière clé de la paire au début de la section relative à la zone, comme suit :
IN
KEY
0x0100
0
1
Key
L’entrée du fichier named.abc.data est la suivante :
$TTL 3h
;3 hour
@ IN
SOA
venus.abc.aus.century.com.
gail.zeus.abc.aus.century.com. (
1
;serial
3600
;refresh
600
;retry
3600000 ;expire
86400
;negative caching TTL
)
IN
NS
venus.abc.aus.century.com.
IN
KEY
0x0100 0 1
AQPlwHmIQeZzRk6Q/nQYhs3xwnhfTgF/8YlBVzKSoKxVKPNLINnYW0mB7attTcfhHaZZcZr4u
/vDNikKnhnZwgn/
venus
IN
A
192.9.201.1
earth
IN
A
192.9.201.5
mars
IN
A
192.9.201.3
3. La zone est maintenant prête à être chargée en régénérant le serveur de noms. Placez
FichierCléAdmin sur le client ou le serveur DHCP qui met la zone à jour. La clé de zone
contenue dans FichierCléAdmin peut être utilisée pour appliquer des mises à jour et des
opérations de maintenance au serveur de noms.
Protocole TCP/IP
4-87
BIND 9
BIND 9 offre les deux mesures de sécurité suivantes pour named:
• Transaction Signatures (TSIG), page 4-88
• Signature (SIG), page 4-90
Le serveur de noms avec BIND 9, par défaut, ne permet pas les mises à jour dynamiques
dans les zones d’autorité, comme dans BIND 8.
Transaction Signatures (TSIG)
BIND 9 prend en charge TSIG pour l’administration de serveur à serveur. Ceci comprend
les messages de transfert de zones, de notification et d’interrogation récursive. TSIG est
également utile pour les mises à jour dynamiques. Un serveur principal pour une zone
dynamique doit utiliser le contrôle d’accès pour contrôler les mises à jour, mais le contrôle
d’accès IP est insuffisant.
En utilisant un chiffrement de base de clé à la place de la méthode actuelle des listes de
contrôle d’accès, TSIG permet de restreindre les utilisateurs autorisés à mettre à jour les
zones dynamiques. Contrairement à la méthode ACL (Access Control List) de mises à jour
dynamiques, la clé TSIG peut être distribués aux autres auteurs de mises à jour sans qu’il
soit nécessaire de modifier les fichiers de configuration sur le serveur de noms, ce qui
signifie qu’il n’est pas nécessaire que le serveur de noms relise les fichiers de configuration.
Il est important de noter que BIND 9 ne dispose pas de tous les mots–clés existant dans
BIND 8. Dans cet exemple, nous utilisons la configuration maître simple de BIND 8.
Remarque :
Pour utiliser named 9, vous devez relier la liaison symbolique au démon
named à named9, et nsupdate à nsupdate9 en exécutant les
commandes suivantes :
1. ln –fs /usr/sbin/named9 /usr/sbin/named
2. ln –fs /usr/sbin/nsupdate9 /usr/sbin/nsupdate
1. Générez la clé à l’aide de la commande dnssec–keygen :
dnssec–keygen –a HMAC–MD5 –b 128 –n HOST clé
– HMAC–MD5 est l’algorithme de chiffrement
– 128 est la longueur de la clé à utiliser (ou nombre de bits)
– HOST: HOST est le mot–clé TSIG utilisé pour générer une clé hôte pour un
chiffrement de clé partagé.
La commande
dnssec–keygen –a HMAC–MD5 –b 128 –n HOST venus–batman.abc.aus.century.com
génère deux fichiers de clé, comme suit :
Kvenus–batman.abc.aus.century.com.+157+35215.key
Kvenus–batman.abc.aus.century.com.+157+35215.private
– 157 est l’algorithme utilisé (HMAC–MD5)
– 35215 est l’empreinte, ce qui est utile dans DNNSEC car plusieurs clés par zone
sont autorisées
2. Ajoutez l’entrée à named.conf sur le serveur de noms maître :
// Clé TSIG
key venus–batman.abc.aus.century.com. {
algorithm hmac–md5;
secret ”+UWSvbpxHWFdNwEAdy1Ktw==”;
};
4-88
Guide de gestion du système – Communications et réseaux
En supposant que HMAC–MD5 est utilisé, les deux fichiers de clé contiennent la clé
partagée, qui est stockée en tant que dernière entrée des fichiers. Trouvez un moyen
sécurisé de copier la clé secrète partagée sur le client. Vous n’avez pas besoin de copier
le fichier de clé, uniquement la clé secrète partagée.
Ce qui suit est l’entrée du fichier
Kvenus–batman.abc.aus.century.com.+157+35215.private:
Format–clé–privée : v1.2
Algorithme : 157 (HMAC_MD5)
Clé : +UWSvbpxHWFdNwEAdy1Ktw==
Vous trouverez ci–après un exemple du fichier named.conf du serveur de noms maître.
La zone abc.aus.century.com permet le transfert de zones et les mises à jour
dynamiques uniquement sur les serveurs ayant la clé
venus–batman.abc.aus.century.com. Procédez de même dans la zone inverse,
pour laquelle les auteurs de mises à jour doivent avoir la clé partagée.
// Clé TSIG
key venus–batman.abc.aus.century.com. {
algorithm hmac–md5;
secret ”+UWSvbpxHWFdNwEAdy1Ktw==”;
};
options {
directory ”/usr/local/domain”;
};
zone ”abc.aus.century.com” in {
type master;
file ”named.abc.data”;
allow–transfer { key venus–batman.abc.aus.century.com.;};
allow–update{ key venus–batman.abc.aus.century.com.; };
};
Comme les transferts de zone sont restreints à ceux qui ont une clé, le fichier
named.conf du serveur de noms doit aussi être édité. Toutes les demande transmises à
192.9.201.1(venus.abc.aus.century.com) sont signées par une clé. Le nom de la clé
(venus–batman.abc.aus.century.com.) doit correspondre à ceux des serveurs qui les
utilisent.
Vous trouverez ci–après un exemple du fichier named.conf du serveur de noms
esclave :
// Clé TSIG
key venus–batman.abc.aus.century.com. {
algorithm hmac–md5;
secret ”+UWSvbpxHWFdNwEAdy1Ktw==”;
};
server 192.9.201.1{
keys { venus–batman.abc.aus.century.com.;};
};
options {
directory ”/usr/local/domain”;
};
zone ”abc.aus.century.com” IN {
type slave;
file ”named.abc.data.bak”;
masters { 192.9.201.1; };
};
Protocole TCP/IP
4-89
Signature (SIG)
BIND 9 prend en partie en charge les signatures de transaction DNSSEC SIG comme
indiqué dans RFC 2535. SIG utilise les clés publiques et privées pour authentifier les
messages.
Les enregistrements SIG permettent aux administrateurs de signer leurs données de zone
afin de les authentifier.
Sécurisation de la zone racine
Supposons que les autres serveurs de noms sur Internet n’utilisent pas BIND 9, et que vous
vouliez sécuriser vos données de zone et permettre aux autres serveurs de vérifier vos
données de zone. Vous souhaitez indiquer que votre zone (dans notre cas
aus.century.com ) est une racine sécurisée et valide toutes les données de zone
sécurisées sous celle–ci.
1. Générez la clé à l’aide de la commande dnssec–keygen :
dnssec–keygen –a RSA –b 512 –r /usr/sbin/named –n ZONE aus.century.com.
Remarque :
Le chiffrement RSA peut être utilisé comme l’algorithme de génération
de la clé si OpenSSL est installé, mais vous devez d’abord relier la
bibliothèque DNS à une bibliothèque DNS sécurisée en exécutant la
commande suivante :
ln –fs /usr/lib/libdns_secure.a /usr/lib/libdns.a
– ZONE: ZONE est le mot–clé DNSSEC utilisé pour générer des clés de zones
pour le chiffrement de clé privée/publique.
– L’indicateur r désigne un périphérique aléatoire.
2. Ajoutez l’entrée de clé publique comme dans le fichier named.conf.
L’entrée utilisée dans l’exemple est indiquée ci–après. Le contenu du fichier de clé
Kaus.century.com.+001+03254.key est indiqué ci–dessous.
abc.aus.century.com. IN KEY 256 3 1
AQOnfGEAg0xpzSdNRe7KePq3Dl4NqQiq7HkwKl6TygUfaw6vz6ldmauB4UQFcGKOyL68/Zv5Z
nEvyB1fMTAaDLYz
La clé publique est contenue dans le fichier Kzonename.+algor.+fingerprint.key,
ou dans notre exemple Kaus.century.com.+001+03254.key. Vous devez
supprimer la classe IN et taper KEY et mettre la clé entre guillemets. Lorsque vous
ajoutez cette entrée au fichier /etc/named.conf et régénérez le serveur de noms,
la zone aus.century.com est une racine sécurisée.
trusted–keys {
aus.century.com. 256 3 1
”AQOnfGEAg0xpzSdNRe7KePq3Dl4NqQiq7HkwKl6Tyg
Ufaw6vz6ldmauB 4UQFcGKOyL68/Zv5ZnEvyB1fMTAaDLYz”;
};
options {
directory ”/usr/local/domain”;
};
zone ”abc.aus.century.com” in {
type master;
file ”named.abc.data.signed”;
allow–update{192.9.201.1;};
};
4-90
Guide de gestion du système – Communications et réseaux
Application de la chaîne de confiance
Une fois votre racine sécurisée, vous pouvez sécuriser le reste de vos zones enfant. Dans
ce cas, nous voulons sécuriser la zone abc.aus.century.com. Procédez comme suit
pour sécuriser vos zones enfants restantes :
1. Générez les paires de clé à l’aide de la commande dnssec–keygen :
dnssec–keygen –a RSA –b 512 –r /usr/sbin/named –n ZONE
abc.aus.century.com.
– L’indicateur r désigne un fichier d’entrée aléatoire.
2. Créez un fichier de clé en exécutant la commande dnssec–makekeyset :
dnssec–makekeyset –t 172800
Kabc.aus.century.com.+001+11515.key
où Kabc.aus.century.com.+001+03254.key est votre propre clé publique.
Ceci crée un fichier de clé appelé keyset–abc.aus.century.com.
3. Envoyez ce fichier de clé à la zone parente pour le faire signer. Dans cet exemple, notre
zone parente est la zone racine sécurisée aus.century.com.
4. Le parent doit signer la clé avec sa clé privée.
dnssec–signkey keyset–abc.aus.century.com.
Kaus.century.com.+001+03254.private
Ceci génère un fichier appelé signedkey–abc.aus.century.com, et le parent doit
renvoyer ce fichier à la zone enfant.
5. Sur le serveur de noms enfant de la zone abc.aus.century.com, ajoutez $INCLUDE
Kabc.aus.century.com.+001+11515.key au fichier de zone simple
named.abc.data. Souvenez–vous de placer le fichier
signedkey–abc.aus.century.com dans le même emplacement que le fichier de zone
named.abc.data. Lorsque la zone est signée dans l’étape suivante, le programme sait
qu’il doit inclure signedkey–abc.aus.century.com, qui a été reçue du parent.
$TTL 3h
;3 hour
@ IN
SOA
venus.abc.aus.century.com.
gail.zeus.abc.aus.century.com. (
1
;serial
3600
;refresh
600
;retry
3600000 ;expire
86400
;negative caching TTL
)
$INCLUDE Kabc.aus.century.com.+001+03254.key
6. Signez la zone à l’aide de la commande dnssec–signzone :
dnssec–signzone –o abc.aus.century.com. named.abc.data
7. Modifiez le fichier named.conf dans la zone enfant abc.aus.century.com pour
utiliser le nouveau fichier de zone signé ( named.abc.data.signed). Par exemple :
options {
directory ”/usr/local/domain”;
};
zone ”abc.aus.century.com” in {
type master;
file ”named.abc.data.signed”;
allow–update{192.9.201.1;};
};
8. Régénérez le serveur de noms.
Pour plus d’informations sur la résolution des problèmes, reportez–vous à Problèmes de
résolution des noms, page 4-274.
Protocole TCP/IP
4-91
Planification et configuration pour la résolution de noms LDAP
(Schéma de répertoire SecureWay)
LDAP (Lightweight Directory Access Protocol) est un standard du marché qui définit une
méthode d’accès et de mise à jour des informations d’un répertoire. Un schéma LDAP
définit les règles de classement des données. La classe d’objet ibm–HostTable, contenue
dans le schéma de répertoire SecureWay Directory, peut être utilisée pour stocker
l’équivalence entre le nom et l’adresse Internet pour chaque hôte du système.
La classe d’objet ibm–HostTable est définit comme suit :
Nom de la classe d’objets :
ibm–HostTable
Description :
Entrée de la table des systèmes hôte regroupant
des noms hôte pour des mappages d’adresses IP.
OID :
TBD
RDN :
ipAddress
Classe d’objet supérieure : top
Attributs nécessaires :
hôte, ipAddress
Attributs optionnels :
ibm–hostAlias, ipAddressType, description
Définitions des attributs :
Attribut :
Description :
OID :
Syntaxe :
Longueur :
Valeur unique
Attribut :
Description :
OID :
Syntaxe :
Longueur :
Valeur unique
Attribut :
Description :
OID :
Syntaxe :
Longueur :
Valeur unique
Attribut :
Description :
OID :
Syntaxe :
Longueur :
Valeur unique
Attribut :
Description :
OID :
Syntaxe :
Longueur :
Valeur unique
:
:
:
:
:
ipAddress
Adresses IP des noms hôtes de la Table des systèmes hôte
TBD
caseIgnoreString
256
Yes
ibm–hostAlias
Alias de l’hôte dans la table des systèmes hôte
TBD
caseIgnoreString
256
Valeur multiple
ipAddressType
Famille d’adresses d’une adresse IP (1=IPv4, 2=IPv6)
TBD
Entier
11
Yes
host
Nom d’hôte d’un système.
1.13.18.0.2.4.486
caseIgnoreString
256
Valeur multiple
description
Commentaires sur un objet de répertoire.
2.5.4.13
caseIgnoreString
1024
Valeur multiple
Utilisez la procédure suivante pour configurer le serveur LDAP conformément au schéma
SecureWay Directory, de façon à stocker l’équivalence entre les noms et les adresses
Internet :
1. Ajoutez un suffixe au serveur LDAP. Le suffixe est le point de départ de la base de
données des hôtes. Par exemple, ”cn=hosts”. Utilisez pour cela l’utilitaire SecureWay
Directory Server Administration.
2. Créez un fichier LDIF (Data Interchange Format) LDAP : Vous pouvez le faire
manuellement ou à l’aide de la commande hosts2ldif, qui crée un fichier LDIF à partir
du fichier /etc/hosts. Reportez–vous à hosts2ldif Command dans le manuel AIX 5L
Version 5.3 Commands Reference pour plus d’informations. Voici un exemple de fichier
LDIF :
4-92
Guide de gestion du système – Communications et réseaux
dn: cn=hosts
objectclass: top
objectclass: container
cn: hosts
dn: ipAddress=1.1.1.1, cn=hosts
host: test
ipAddress: 1.1.1.1
objectclass: ibm–HostTable
ipAddressType: 1
ibm–hostAlias: e–test
ibm–hostAlias: test.austin.ibm.com
description: first ethernet interface
dn: ipAddress=fe80::dead, cn=hosts
host: test
ipAddress: fe80::dead
objectclass: ibm–HostTable
ipAddressType: 2
ibm–hostAlias: test–ll
ibm–hostAlias: test–ll.austin.ibm.com
description: v6 link level interface
3. Importez les données du répertoire d’hôtes à partir du fichier LDIF du serveur LDAP.
Pour cela, utilisez la commande ldif2db ou l’outil Web SecureWay Directory Server
Administration.
Configurez le client pour qu’il accède à la base de données des hôtes sur le serveur LDAP,
via le mécanisme LDAP, en procédant comme suit :
1. Créez le fichier /etc/resolv.ldap Pour en savoir plus et disposer d’un exemple de fichier
resolv.ldap, reportez–vous à la section resolv.ldap File Format for TCP/IP dans le
manuel AIX 5L Version 5.3 Files Reference.
2. Modifiez le nom de résolution par défaut avec la variable d’environnement NSORDER,
le fichier /etc/netsvc.conf ou le fichier /etc/irs.conf. Pour plus de détails, reportez–vous
à netsvc.conf File Format for TCP/IP, ou à irs.conf File Format for TCP/IP dans le
manuel AIX 5L Version 5.3 Files Reference.
Bien qu’il soit toujours pris en charge, il n’est plus conseillé d’utiliser le mécanisme ldap. Le
mécanisme ldap existant fonctionne avec SecureWay Directory Schema. AIX 5.2 propose
le nouveau mécanisme d’attribution des noms, nis_ldap (NIS_LDAP), qui fonctionne
avec le schéma RFC 2307. Il est conseillé d’utiliser le mécanisme nis_ldap
à la place du mécanisme ldap. Pour plus d’informations sur la résolution de noms
nis_ldap, reportez–vous à P Planification et configuration pour la résolution de noms
NIS_LDAP (Schéma de répertoire RFC 2307), page 4-93.
Planification et configuration pour la résolution
de noms NIS_LDAP (Schéma RFC 2307)
AIX 5.2 propose un nouveau mécanisme d’attribution de noms appelé NIS_LDAP. La
différence entre le mécanisme LDAP existant et ce nouveau mécanisme NIS_LDAP est lié
au schéma LDAP (le groupe des attributs et des classes d’objets qui déterminent la façon
dont les attributs sont regroupés pour décrire une entité). Le mécanisme LDAP existant
fonctionne avec le serveur LDAP compatible avec le schéma SecureWay et prend en
charge uniquement le service d’attribution de noms hôte. Le mécanisme NIS_LDAP
fonctionne avec le serveur LDAP compatible avec le schéma RFC 2307, et prend en charge
tous les services NIS : utilisateurs et groupes, hôtes, services, protocoles, réseaux et
groupe réseau. RFC 2307 définit un ensemble d’attributs et de classes d’objets qui peut
être utilisé pour décrire les services d’informations réseau, notamment les utilisateurs et les
groupes.
Protocole TCP/IP
4-93
Pour configurer le serveur LDAP, vous devez configurer le serveur LDAP et migrer les
données requises vers le serveur.
1. Pour configurer un serveur, utilisez la commande mksecldap. Le mécanisme nis_ldap
fonctionne uniquement avec le schéma RFC 2307. Lors de la configuration du serveur
LDAP, la commande mksecldap devrait être appelée avec l’option –S rfc2307 ou –S
rfc2307aix (pas l’option –S aix qui spécifie le schéma SecureWay Directory). Par
défaut, la commande mksecldap migre les utilisateurs et les groupes définis dans local
system sur le serveur LDAP. Si vous souhaitez désactiver cette migration, utilisez
l’option –u NONE.
mksecldap –s –a cn=admin –p adminpwd –S rfc2307aix
Le serveur LDAP se voit attribuer cn=admin comme DN administrateur et adminpwd
comme mot de passe. Le suffixe par défaut, cn=aixdata, est également ajouté au
fichier /etc/slapd32.conf, le fichier de configuration du serveur LDAP.
Par défaut, la commande mksecldap migre les utilisateurs et les groupes définis dans le
système local sur le serveur LDAP. Pour désactiver cette migration, utilisez l’option –u
NONE, qui empêche la migration des utilisateurs et des groupes locaux sur le serveur
LDAP. Vous ne pouvez ainsi ajouter les utilisateurs et les groupes NIS que plus tard.
mksecldap –s –a cn=admin –p adminpwd –u NONE
Pour plus de détails sur la commande mksecldap, reportez–vous à la description de la
commande dans le manuel AIX 5L Version 5.3 Commands Reference.
2. Migrez les données NIS. Utilisez la commande nistoldif du serveur NIS pour migrer les
équivalences NIS vers le serveur LDAP. La commande nistoldif peut aussi être utilisée
pour migrer les données des fichiers plats.
Exécutez la commande nistoldif sur un système contenant des données NIS qui doivent
être migrées vers le serveur LDAP.
nistoldif –h server1.ibm.com –a cn=admin –p adminpwd –d cn=aixdata
Ceci permet de faire migrer les équivalences NIS depuis le local system sur le serveur
LDAP, server1.ibm.com. Les données NIS sont placées sous le DNcn=aixdata.
Vous pouvez aussi exécuter la commande nistoldif pour migrer les données des fichiers
plats de n’importe quel système vers le serveur LDAP. Les fichiers plats seront utilisés
pour toutes les équivalences manquantes du serveur NIS.
Pour plus de détails sur la commande nistoldif, reportez–vous à la description de la
commande dans le manuel AIX 5L Version 5.3 Commands Reference.
Remarque :
Les noms sont représentés par l’attribut cn du serveur LDAP. L’attribut
cn défini par RFC 2307 ne tient pas compte de la casse. Les noms
différenciés uniquement par la casse sont fusionnés sur le serveur. Les
équivalences exactes ne tiennent pas non plus compte de la casse. Les
recherches effectuées sur TCP, tcp, ou Tcp renverraient toutes l’entrée
de protocole de TCP.
Pour configurer le client LDAP afin qu’il accède aux noms du serveur LDAP, exécutez la
commande mksecldap avec les options de configuration du client.
1. La commande mksecldap enregistre le nom de serveur LDAP, le port, admindn, le mot
de passe et basedn dans le fichier /etc/security/ldap/ldap.cfg, qui est lu par le démon
secldapclntd lors du démarrage. La commande mksecldap démarre le démon
secldapclntd automatiquement, si la configuration réussit.
Pour plus d’informations sur le fichier /etc/security/ldap/ldap.cfg, consultez le manuel
AIX 5L Version 5.3 Files Reference. Pour plus d’informations sur le démon
secldapclntd, consultez le manuel AIX 5L Version 5.3 Commands Reference.
4-94
Guide de gestion du système – Communications et réseaux
2. La commande mksecldap ajoute le mécanisme nis_ldap au fichier /etc/netsvc.conf
et /etc/irs.conf afin de diriger la résolution de noms vers LDAP. Vous pouvez aussi
définir la variable d’environnement NSORDER en tant que nis_ldap pour utiliser la
résolution de noms NIS_LDAP.
mksecldap –c –a cn=admin –p adminpwd –h server1.ibm.com
Il configure le système local afin qu’il utilise le serveur LDAP server1.ibm.com.
Le DN et le mot de passe administrateur du serveur LDAP doivent être fournis au client
pour lui permettre de s’authentifier. Les fichiers /etc/netsvc.conf et /etc/irs.conf sont
mis à jour afin que la résolution d’attribution de noms soit résolue via NIS_LDAP.
Pour plus d’informations, consultez le format de fichier /etc/netsvc.conf pour TCP/IP
ou /etc/irs.conf pour TCP/IP dans le manuel AIX 5L Version 5.3 Files Reference.
3. La résolution des noms pour les utilisateurs et les groupes n’est pas contrôlée par les
fichiers /etc/netsvc.conf ou /etc/irs.conf, mais par le fichier /etc/security/user. Pour
permettre à un utilisateur LDAP de se connecter à un système AIX, définissez les
variables SYSTEM et registry de l’utilisateur en tant que LDAP dans le fichier
/etc/security/user de ce système client. Vous pouvez effectuer cette opération avec
la commande chuser.
chuser –R LDAP SYSTEM=LDAP registry=LDAP foo
Vous pouvez configurer votre système afin d’autoriser tous les utilisateurs LDAP à
se connecter à un système. Pour ce faire, éditez le fichier /etc/security/user. Ajoutez
registry = files à la strophe racine. Ajoutez ensuite SYSTEM = LDAP et
registry = LDAP à la strophe par défaut.
Pour plus d’informations sur l’authentification utilisateur, reportez–vous à la section
relative à l’exploitation LDAP du sous–système de sécurité dans le manuel AIX 5L
Version 5.3 – Guide de sécurité.
Pour plus d’informations sur l’activation de l’authentification Netgroup RFC 2307,
reportez–vous à la section relative à la migration à partir de NIS et NIS+ vers des
services LDAP compatibles RFC 2307 dans le manuel AIX 5L Version 5.3 Network
Information Services (NIS and NIS+) Guide.
Protocole TCP/IP
4-95
Affectation des adresses et paramètres TCP/IP Protocole DHCP
Le protocole TCP/IP permet la communication entre machines disposant d’adresses
configurées. L’affectation des adresses et la distribution des paramètres pour toutes les
machines du réseau est une des tâches incombant à l’administrateur de réseau.
Généralement, ce processus consiste pour l’administrateur à imposer une configuration
à chaque utilisateur, tout en permettant à l’utilisateur de configurer sa propre machine.
Toutefois, des erreurs de configuration ou des malentendus peuvent générer des appels de
service que l’administrateur doit traiter individuellement. Le protocole DHCP (Dynamic Host
Configuration Protocol) offre à l’administrateur une alternative, permettant d’exclure
l’utilisateur final des problèmes de configuration et de gérer la configuration du réseau à
partir d’un site central.
DHCP est un protocole de couche application qui permet à une machine du réseau, le
client, d’obtenir du serveur une adresse IP ainsi que d’autres paramètres de configuration.
Les informations sont obtenues au moyen d’un échange de paquets réalisé entre un démon
sur le client et un autre sur le serveur. La plupart des systèmes d’exploitation proposent à
l’heure actuelle un client DHCP dans leur module de base.
Pour obtenir une adresse, le démon du client DHCP (dhcpcd) diffuse un message de
découverte DHCP, qui est reçu et traité par le serveur. (Il est possible de configurer à cet
effet plusieurs serveurs sur le réseau.) S’il existe une adresse disponible pour ce client,
un message DHCP de proposition est créé, contenant une adresse IP et d’autres options
client. Le client reçoit cette proposition DHCP et la stocke en attendant d’autres
propositions. Il choisit ensuite la meilleure et diffuse une demande DHCP indiquant au
serveur la proposition retenue.
Tous les serveurs DHCP configurés reçoivent la demande. Chacun d’eux vérifie qu’il n’est
pas le serveur demandé. Si ce n’est pas le cas, le serveur libère l’adresse qu’il a affecté au
client. En revanche, le serveur demandé marque que l’adresse est affectée et renvoie un
accusé de réception DHCP, qui finalise la transaction et attribue au client une adresse pour
une durée (délai) définie par le serveur.
A échéance de la moitié de ce délai, le client tente de renouveler la réservation de son
adresse en envoyant au serveur un paquet de renouvellement. Si le serveur accepte la
demande, il envoie un accusé de réception DHCP. Si le client ne parvient pas à obtenir une
réponse de son serveur attitré, il diffuse un paquet de nouvelle liaison DHCP afin de tenter
de joindre le serveur (celui–ci a pu, par exemple, être déplacé d’un réseau à un autre). Si, à
l’expiration de la totalité du délai, le client n’a pas renouvelé son adresse, l’interface est
arrêtée et le processus recommence à zéro. Ce cycle permet d’éviter que plusieurs clients
d’un réseau ne se voient affecter la même adresse.
Le serveur DHCP procède à l’attribution des adresses en fonction de clés. Les quatre clés
les plus courantes sont le réseau, la classe, le fournisseur et l’ID de client. Le serveur se
sert de ces clés pour obtenir une adresse et un jeu d’options de configuration qu’il envoie
au client.
4-96
réseau
Identifie le segment de réseau d’où est issu le paquet. La clé réseau
permet au serveur de vérifier sa base de données d’adresses et d’attribuer
une adresse correspondant au segment de réseau.
classe
Elle est entièrement configurable par le client. Elle peut comprendre une
adresse et des options. Cette clé peut être utilisée pour préciser la fonction
d’une machine du réseau ou décrire le mode de regroupement des
machines adopté à des fins administratives. Ainsi, l’administrateur du
réseau peut créer une classe netbios contenant les options destinées
aux clients NetBIOS ou une classe comptabilité représentant les
machines du service Comptabilité qui ont besoin d’accéder à une
imprimante spécifique.
Guide de gestion du système – Communications et réseaux
fournisseur
Facilite l’identification du client à l’aide de sa plate–forme
matérielle/logicielle (par exemple, un client Windows 95 ou un client OS/2
Warp).
ID client
Identifie le client, soit par le nom d’hôte de sa machine soit par son adresse
de couche MAC (medium access control). L’ID client figure dans le fichier
de configuration du démon dhcpcd. Par ailleurs, il peut être utilisé par le
serveur pour transmettre des options à un client ou pour empêcher un
client de recevoir des paramètres.
Ces clés peuvent figurer dans le fichier de configuration soit seules, soit en combinaison.
Si un client fournit plusieurs clés et que plusieurs adresses peuvent être allouées, le choix
porte sur une clé et le jeu d’options découle de la clé choisie en premier. Pour plus
d’informations sur la sélection des clés et des adresses, reportez–vous à la section
Configuration de DHCP, page 4-100.
Un agent relais est requis pour que les diffusions initiales du client puissent quitter le réseau
local. Cet agent est appelé agent relais BOOTP. Ces agents assurent le relais des paquets
DHCP et BOOTP.
Le serveur DHCP
A partir de AIX Version 4.3.1, le serveur DHCP a été divisé en trois grandes parties : une
base de données, un moteur de protocole et un ensemble de routines de service, chaque
partie disposant de ses propres informations de configuration.
La base de données DHCP
La base de données db_file.dhcpo permet d’effectuer le suivi des clients et des adresses
et de contrôler les accès (par exemple, pour autoriser certains clients exclusivement à
accéder à certains réseaux ou pour désactiver les clients BOOTP sur un réseau particulier).
Les options sont également enregistrées dans la base de données d’où elles peuvent être
extraites et distribuées aux clients. La base de données est implémentée sous la forme d’un
objet pouvant être chargé de façon dynamique, ce qui facilite les mises à niveau et la
maintenance du serveur.
A partir des informations du fichier de configuration, la base de données est amorcée et sa
cohérence est vérifiée. Un ensemble de fichiers de points de contrôle met à jour la base de
données et réduit le volume d’écritures vers le fichier de stockage principal. La base de
données contient également des pools d’adresses et d’options, mais ceux–ci sont statiques
et sont étudiés dans la section Configuration de DHCP, page 4-100.
Le fichier de stockage principal et sa copie de sauvegarde sont de simples fichiers ASCII
qui peuvent, si nécessaire, être modifiés. Leur format est le suivant :
DF01
”
ID CLIENT ” ”
0.0.0.0 ”
Etat
LeaseTimeStart
LeaseTimeDuration
LeaseTimeEnd
”
Adresse IP serveur ” ” ID classe ” ”ID fournisseur” ”Hôte ” ”Nom de
domaine ”
”
ID CLIENT ” ”
0.0.0.0 ”
Etat
LeaseTimeStart
LeaseTimeDuration
LeaseTimeEnd
”
Adresse IP serveur ” ”
ID classe ” ”
ID fournisseur ” ”
Hôte
” ”
Nom de domaine ”
...
La première ligne indique la version du fichier : DF01c. Les lignes qui suivent définissent
des enregistrements client. Le serveur procède à la lecture de la seconde ligne jusqu’à la fin
du fichier. (Les paramètres entre guillemets doivent être indiqués entre guillemets.)
”CLIENT ID” ID utilisé par le client pour se présenter au serveur.
”0.0.0.0”
est l’adresse IP actuellement attribuée au serveur DHCP. Si aucune
adresse n’a été attribuée, ”0.0.0.0” sera adopté par défaut.
State
Etat actuel du client. Le moteur de protocole DHCP contient le jeu de
valeurs attribuables et les états sont gérés dans la base de données DHCP.
Protocole TCP/IP
4-97
Le nombre en regard de State représente sa valeur. Les différents états
possibles sont :
(1) FREE
Représente les adresses qui sont disponibles. En général, les clients
n’ont pas cet état, à moins qu’aucune adresse ne leur ait encore été
attribuée. dadmin et la sortie de lssrc signalent pour cet état ”Free”.
(2) BOUND
Indique que le client et l’adresse sont liés et que l’adresse a été
attribuée au client il y a déjà un certain temps. dadmin et la sortie de
lssrc indiquent pour cet état ”Leased”.
(3) EXPIRED
Indique que le client et l’adresse sont liés, à titre d’information
uniquement, de la même manière que l’état released. Cet état
signale toutefois que le client a laissé son bail arriver à expiration.
Une adresse arrivée à expiration est disponible et est réaffectée
lorsque toutes les adresses libres sont indisponibles et avant que les
adresses libérées ne soient réattribuées. dadmin et la sortie de lssrc
indiquent pour cet état ”Expired”.
(4) RELEASED Indique que le client et l’adresse sont liés, à titre d’information
uniquement. Le protocole DHCP conseille aux serveurs DHCP de
gérer les informations concernant leurs clients précédents à des fins
de référence ultérieure (principalement pour essayer de redonner à
un client une adresse qu’il a déjà utilisée dans le passé). Cet état
signale que le client a libéré l’adresse. Cette adresse peut donc être
utilisée par d’autres clients si aucune autre adresse n’est disponible.
dadmin et la sortie de lssrc indiquent pour cet état ”Released”.
(5) RESERVED
Indique qu’une liaison lâche existe entre le client et l’adresse. Le
client a envoyé un message de découverte DHCP, auquel le serveur
DHCP a répondu, et le client n’a pas encore répondu par une
requête DHCP demandant cette adresse. dadmin et la sortie de
lssrc indiquent pour cet état ”Reserved”.
(6) BAD
Représente une adresse utilisée sur le réseau mais qui n’a pas été
distribuée par le serveur DHCP. Cet état qualifie également les
adresses qui ont été rejetées par les clients. Cet état ne s’applique
pas à des clients. dadmin et la sortie de lssrc indiquent que cet état
est ”Utilisé” (Used) et ”Mauvais” (Bad), respectivement.
LeaseTimeStart Début du bail actuel (en nombre de secondes écoulées depuis le 1er
janvier 1970).
LeaseTimeDuration
Durée du bail (en secondes).
LeaseTimeEnd Utilise le même format que LeaseTimeStart, pour indiquer la fin du bail.
Certaines options de configuration utilisent des valeurs différentes pour le
début et la fin d’un bail et il est possible de substituer à ces valeurs des
options du fichier de configuration. Reportez–vous à Syntaxe du fichier de
serveur DHCP pour la base de données db_file, page 4-121.
”Server IP Address”
Adresse IP du serveur DHCP détenteur de cet enregistrement.
”Class ID”
”Vendor ID”Host Name”
”Domain Name”
Valeurs utilisées par le serveur pour déterminer les options qui sont
envoyées au serveur (stockées sous la forme de chaînes entre guillemets).
Ces paramètres permettent d’améliorer les performances, puisque les listes
d’options peuvent être générées à l’avance pour ces clients au démarrage
du serveur DHCP.
4-98
Guide de gestion du système – Communications et réseaux
Fichiers de points de contrôle
La syntaxe des fichiers de points de contrôle n’est pas spécifiée. En cas de panne du
serveur, ou si vous devez l’arrêter sans avoir pu fermer normalement la base de données,
le serveur peut utiliser les fichiers de points de contrôle et les fichiers de sauvegarde pour
reconstruire une base de données correcte. La pire situation serait de perdre un client (si le
client était en cours d’écriture dans le fichier de point de contrôle au moment de la panne).
Les fichiers par défaut sont :
/etc/db_file.cr fonctionnement normal de la base de données
/etc/db_file.crbk
sauvegardes de la base de données
/etc/db_file.chkpt et /etc/db_file.chkpt2
fichiers de point de contrôle en alternance
Le serveur DHCP pour AIX Version 4.3.1 et ultérieures est du type enchaîné. Pour garantir
un débit élevé, les opérations sur la base de données (y compris les opérations de
sauvegarde) sont optimisées pour le type enchaîné. Lorsqu’une sauvegarde est demandée,
le fichier de points de contrôle existant est remplacé par le fichier de points de contrôle
suivant, le fichier de base de données existant est copié dans le fichier de secours et un
nouveau fichier de sauvegarde est créé. Chaque enregistrement client est consigné et un
bit est modifié afin d’indiquer que le client doit utiliser le nouveau fichier de points de
contrôle pour la journalisation. Lorsque tous les enregistrements client sont pris en compte,
la sauvegarde est fermée et les anciens fichiers de secours et de points de contrôle sont
supprimés. De cette manière, les clients peuvent toujours être traités et, si l’enregistrement
du client a été sauvegardé, les modifications s’inscrivent dans un nouveau fichier de
sauvegarde ou un nouveau fichier de points de contrôle.
Le moteur de protocole DHCP
Pour AIX Version 4.3.1 et ultérieures, le moteur de protocole DHCP a été mis au niveau de
la norme RFC 2131, mais reste compatible avec RFC 1541. (Le serveur peut également
traiter des options définies dans RFC 2132.) Le moteur de protocole utilise la base de
donnés pour déterminer quelles informations doivent être retournées au client.
La configuration des pools d’adresses fait intervenir certaines options qui affectent l’état de
la machine. Par exemple, le serveur DHCP interroge (ping) les adresses avant de les
attribuer. La durée d’attente de la réponse par le serveur peut désormais être configurée
pour chaque pool d’adresses.
Opérations DHCP enchaînées
Le dernier élément du serveur DHCP est en fait un ensemble d’opérations qui permettent
d’assurer la continuité des opérations. Comme le serveur DHCP est du type enchaîné,
ces opérations sont en fait définies sous la forme de routines qui interviennent
occasionnellement pour s’assurer du bon déroulement des opérations.
La première routine, ou routine principale, gère les requêtes SRC (par exemple startsrc,
stopsrc, lssrc, traceson et refresh). Cette routine coordonne également toutes les
opérations qui affectent toutes les routines et gère les signaux. Par exemple :
• A SIGHUP (–1) provoque un rafraîchissement de toutes les bases de données du fichier
de configuration.
• A SIGTERM (–15) entraîne l’arrêt en douceur du serveur.
La routine suivante, dadmin, interface avec le programme client dadmin et le serveur
DHCP. L’outil dadmin peut être utilisé pour obtenir des informations sur l’état de la base de
données et la modifier, et évite de modifier manuellement les différents fichiers de la base
de données. Les versions antérieures du serveur DHCP empêchaient l’attribution
d’adresses aux clients lorsqu’une requête d’état était en cours. Grâce aux routines dadmin
et src, le serveur est désormais en mesure de gérer les requêtes de services tout en
continuant à traiter les requêtes des clients.
Protocole TCP/IP
4-99
La routine suivante est garbage qui, à intervalles réguliers, nettoie la base de données,
la sauvegarde, purge les clients ne possédant pas d’adresse et supprime les adresses
réservées qui le sont depuis trop longtemps. Les intervalles peuvent être configurés
(reportez–vous à la section Configuration de DHCP, page 4-100). Les autres routines
correspondent à des processeurs de paquet. Leur nombre peut être configuré et il est de 10
par défaut. Chaque routine peut traiter une requête émise par un client DHCP. Le nombre
de processeurs de paquets requis est fonction de la charge et de la machine. Si la machine
assure d’autres services que DHCP, il n’est peut être pas très sage de lancer 500 routines.
Préparation de DHCP
Pour exploiter ce protocole, l’administrateur réseau doit configurer un serveur DHCP ainsi
que les agents relais BOOTP sur les liaisons dépourvues de serveur DHCP. Une
planification anticipée peut permettre de réduire la charge de DHCP sur le réseau. Par
exemple, si vous configurez un seul serveur pour gérer tous les clients, tous les paquets
doivent transiter par ce serveur. Si vous ne disposez que d’un routeur entre deux grands
réseaux, il est plus sage de prévoir deux serveurs, un sur chaque liaison.
Un autre aspect à considérer est le fait que DHCP implique une trame de trafic. Par
exemple, si vous définissez un délai par défaut inférieur à 2 jours et que vous arrêtez les
machines pendant le week-end, le trafic DHCP connaîtra une pointe le lundi matin. Bien que
le trafic DHCP ne constitue pas une charge supplémentaire considérable, il doit néanmoins
être pris en compte au moment de décider du nombre et de l’emplacement des serveurs
DHCP sur le réseau.
L’objectif de DHCP est de libérer le client de toute saisie une fois DHCP activé pour intégrer
le client au réseau. Le client DHCP, dhcpcd, lit un fichier de configuration, dhcpcd.ini, qui
contient des informations sur la journalisation ainsi que les paramètres requis pour
démarrer. L’installation terminée, il vous faut sélectionner la méthode de configuration de
TCP/IP : configuration minimale ou DHCP. Si vous optez pour DHCP, vous devez choisir
une interface et vous pouvez spécifier des paramètres facultatifs. Pour l’interface, vous
pouvez sélectionner le mot–clé any, qui indique à dhcpcd d’utiliser la première interface
en état de fonctionnement qu’il rencontre. Cette méthode minimise la quantité d’entrées
côté client.
Configuration de DHCP
Par défaut, la configuration du serveur DHCP est effectuée par la lecture du fichier
/etc/dhcpsd.cnf, qui spécifie la base de données initiale d’adresses et d’options du serveur.
Le serveur est lancé dans le fichier /etc/rc.tcpip, à partir de Web-based System Manager,
de SMIT, ou à l’aide de commandes SRC. Vous pouvez configurer un client DHCP via
Web-based System Manager, SMIT ou en éditant un fichier ASCII plat.
La configuration de DHCP constitue la tâche la plus délicate dans le cadre de l’utilisation de
DHCP dans votre réseau. Vous devez d’abord déterminer le nombre de réseaux qui devront
accueillir des clients DHCP. Chaque sous–réseau du réseau principal représente un pool
d’adresses que le serveur DHCP doit ajouter à sa base de données. Par exemple :
database db_file
{
subnet 9.3.149.0 255.255.255.0
{ option 3 9.3.149.1 # Passerelle par défaut que les clients de
ce réseau doivent utiliser
option 6 9.3.149.2 # Serveur de noms que les clients de ce résea
u doivent utiliser
}
... options ou autres conteneurs ajoutés ultérieurement
}
4-100
Guide de gestion du système – Communications et réseaux
L’exemple ci–dessus représente un sous–réseau, 9.3.149.0, avec un masque de
sous–réseau 255.255.255.0. Toutes les adresses de ce sous–réseau, de 9.3.149.1 à
9.3.149.254, sont contenues dans le pool. Eventuellement, il est possible de spécifier un
intervalle à la fin de la ligne, ou d’inclure un intervalle ou une instruction d’exclusion dans le
conteneur de sous–réseau. Pour plus d’informations sur les définitions et méthodes de
configuration classiques, reportez–vous à Options connues du fichier de serveur DHCP,
page 4-109.
La clause de base de données mentionnant db_file indique la méthode à utiliser pour le
traitement de cette portion du fichier de configuration. Les commentaires sont introduits par
le symbole #. Le texte placé entre le # initial et la fin de la ligne est ignoré par le serveur
DHCP. Chaque ligne option est utilisée par le serveur pour indiquer au client ce qu’il doit
faire. La section Options connues du fichier de serveur DHCP, page 4-109 décrit les options
reconnues et prises en charge à l’heure actuelle. Pour savoir comment définir des options
inconnues du serveur, reportez–vous à la section Syntaxe du fichier de serveur DHCP
pour le fonctionnement général du serveur, page 4-116.
Si le serveur ne comprend pas comment analyser une option, il utilise des méthodes
par défaut pour transmettre l’option au client. Ceci permet au serveur DHCP d’envoyer
des options spécifiques à certains sites, qui ne sont pas définies dans les normes RFC,
mais sont utilisables par certains clients ou certaines configurations de client.
Le fichier de configuration
Le fichier de configuration comprend une section d’adresses et une section de définition
d’options, basées sur le concept des conteneurs, qui renferment les options, les
modificateurs et, le cas échéant, d’autres conteneurs.
Un conteneur (qui est finalement une méthode de regroupement des options) fait appel à un
identificateur pour classer les clients en plusieurs groupes. Les types de conteneur sont le
sous–réseau, la classe, le fournisseur et le client. A l’heure actuelle, il n’existe pas de
conteneur générique définissable par l’utilisateur. L’identificateur définit le client de manière
unique, de sorte qu’il soit possible de suivre sa trace même s’il est déplacé vers un autre
sous–réseau. Il est possible d’utiliser plusieurs types de conteneur pour définir les droits
d’accès du client.
Les options sont les identificateurs qui sont retournés au client, par exemple la passerelle
par défaut et l’adresse de DNS.
Les modificateurs sont des instructions isolées qui modifient l’aspect d’un conteneur, par
exemple la valeur par défaut de la durée du bail.
Conteneurs
Lorsque le serveur DHCP reçoit une requête, le paquet est analysé et les clés
d’identification permettent de déterminer les conteneurs, les options et les adresses
à extraire.
L’exemple précédent présente un conteneur de sous–réseau. La clé d’identification est la
position du client au sein du réseau. Si le client fait partie de ce réseau, alors il est intégré
à ce conteneur.
Chaque type de conteneur utilise une option différente pour identifier les clients :
• Le conteneur sous–réseau utilise le champ giaddr ou l’adresse de l’interface réceptrice
pour déterminer le sous–réseau d’origine du client.
• Le conteneur classe utilise la valeur de l’option 77
(User Site Class Identifier – identificateur de la classe du site utilisateur).
• Le conteneur fournisseur utilise la valeur de l’option 60
(Vendor Class Identifier – identificateur de la classe du fournisseur).
• Le conteneur client utilise la valeur de l’option 61 (Client Identifier – identificateur du
client) pour les clients DHCP et le champ chaddr du paquet BOOTP pour les clients
BOOTP.
Protocole TCP/IP
4-101
Sauf pour les sous–réseaux, chaque conteneur accepte la spécification de la valeur de
correspondance à l’aide d’expressions régulières.
A ces conteneurs, il faut ajouter un conteneur implicite, le conteneur global. Sauf
spécification contraire ou refus explicite, les options et modificateurs sont placés dans le
conteneur global. La plupart des conteneurs peuvent être inclus dans d’autres conteneurs,
ce qui implique une certaine visibilité. Les conteneurs peuvent ou non être associés à des
plages d’adresses. Tel est le cas, par nature, des sous–réseaux.
Les règles de base s’appliquant aux conteneurs et sous–conteneurs sont les suivantes :
• Tous les conteneurs sont valides au niveau général.
• Les sous–réseaux ne doivent jamais être inclus dans d’autres conteneurs.
• Des conteneurs restreints ne peuvent englober des conteneurs réguliers du même type.
(Par exemple, un conteneur doté d’une option autorisant uniquement la classe
Comptabilité ne peut receler un conteneur doté d’une option autorisant toutes les
classes commençant par la lettre ”c”. Ceci n’est pas autorisé.)
• Les conteneurs client restreints ne peuvent englober de sous–conteneurs.
En tenant compte des règles ci–dessus, vous pouvez générer une hiérarchie de conteneurs
qui répartissent les options en différents groupes pour des clients ou des ensembles de
clients spécifiques.
Comment sont gérées les options et adresses lorsqu’un client correspond à plusieurs
conteneurs ? Le serveur DHCP reçoit les messages, il transmet la requête à la base de
données (fichier db_file en l’occurrence) et une liste de conteneurs est générée. La liste est
organisée par ordre de profondeur et de priorité. La priorité se définit comme une hiérarchie
implicite au sein des conteneurs. Les conteneurs stricts ont une priorité supérieure à celle
des conteneurs réguliers. Les clients, les classes, les fournisseurs et enfin, les
sous–réseaux sont triés, dans cet ordre, et à l’intérieur de chaque conteneur en fonction de
leur profondeur. Ceci aboutit à une liste allant du plus spécifique au moins spécifique. Par
exemple :
Sous–réseau 1
––Classe 1
––Client 1
Sous–réseau 2
––Classe 1
––––Fournisseur 1
––––Client 1
––Client 1
Cet exemple présente deux sous–réseaux, Sous–réseau 1 et Sous–réseau 2. Il y a un
nom de classe, Classe 1, un nom de fournisseur, Fournisseur 1 et un nom de client,
Client 1. Classe 1 et Client 1 sont définis en plusieurs endroits. Comme ils résident
dans des conteneurs différents, leurs noms peuvent être identique mais leurs valeurs,
différentes. Si Client 1 envoie un message au serveur DHCP depuis Sous–réseau 1
avec Classe 1 spécifiée dans sa liste d’options, le serveur DHCP va générer le chemin
de conteneur suivant :
Sous–réseau 1, Classe 1, Client 1
Le conteneur le plus spécifique apparaît en dernier. Pour obtenir une adresse, la liste est
étudiée dans l’ordre inverse de la hiérarchie et la première adresse disponible est retenue.
Ensuite, l’étude de la liste de poursuit en remontant dans la hiérarchie afin d’obtenir les
options. Les options peuvent remplacer des valeurs précédentes, sauf si une option deny a
été incluse dans le conteneur. Par ailleurs, puisque Classe 1 et Client 1 figurent dans
Sous–réseau 1, ils sont ordonnés en fonction de la priorité de leur conteneur. Si le même
client se trouve dans Sous–réseau 2 et envoie le même message, la liste de conteneur
générée sera :
Sous–réseau 2, Classe 1, Client 1 (au niveau de Sous–réseau 2), Client 1
(au niveau de Classe 1)
4-102
Guide de gestion du système – Communications et réseaux
Sous–réseau 2 apparaît en premier, suivi de Classe 1, puis de Client 1 au niveau de
Sous–réseau 2 (car cette instruction client ne se trouve qu’à un niveau en dessous dans
la hiérarchie). Cette hiérarchie implique qu’un client correspondant à la première instruction
client est moins spécifique que le client correspondant à Client 1 de Classe 1 au sein
de Sous–réseau 2.
La priorité sélectionnée en fonction de la profondeur dans la hiérarchie prend le pas sur la
priorité des conteneurs eux–mêmes. Par exemple, si le même client émet le même
message, en précisant cette fois un identificateur de fournisseur, la liste de conteneur
devient :
Sous–réseau 2, Classe 1, Fournisseur 1, Client 1 (au niveau de
Sous–réseau 2), Client 1 (au niveau de Classe 1)
La priorité au niveau des conteneurs améliore les performances en matière de recherche
car elle correspond à un concept général selon lequel les conteneurs client constituent le
moyen le plus spécifique de définir un ou plusieurs clients. Le conteneur client contient des
adresses plus spécifiques qu’un conteneur classe, lui–même plus spécifique qu’un
conteneur fournisseur, le conteneur sous–réseau étant le moins spécifique de tous.
Adresses et plages d’adresses
Les plages d’adresses, obligatoires pour les conteneurs sous–réseau, peuvent être
associées à tout type de conteneur. Chaque plage définie pour un conteneur doit être un
sous–ensemble de la plage du conteneur parent et ne doit pas présenter de
chevauchement avec la plage d’un autre conteneur. Par exemple, si une classe définie
dans un sous–réseau est associée à une plage d’adresses, cette plage doit constituer un
sous–ensemble des adresses de la plage du sous–réseau. En outre, le conteneur de la
classe ne doit pas recouvrir, même partiellement, d’autres plages d’adresses au même
niveau.
Les plages peuvent être définies sur la ligne du conteneur et modifiées au moyen
d’instructions de plages et d’exclusion afin que des jeux d’adresse non contigus puissent
être associés à un conteneur. Ainsi, si les dix premières adresses d’un sous–réseau sont
disponibles, ainsi que les dix suivantes, le sous–réseau peut spécifier ces adresses par
plage dans la clause de sous–réseau afin de réduire l’utilisation de la mémoire et les
risques de collision d’adresses avec d’autres clients ne se trouvant pas dans les plages
spécifiées.
Dès qu’une adresse est sélectionnée, tout conteneur suivant dans la liste contenant les
plages d’adresses est retiré de la liste, avec ses enfants. Les options spécifiques au réseau
dans les conteneurs supprimés ne sont pas valides si l’adresse n’est pas utilisée à partir de
ce conteneur.
Options
Une fois la liste ponctionnée pour déterminer les adresses, un ensemble d’options est
généré pour le client. Lors de ce processus de sélection, les nouvelles options remplacent
les options précédemment sélectionnées, sauf si une clause deny est rencontrée, auquel
cas l’option refusée est retirée de la liste envoyée au client. Cette méthode autorise les
héritages à partir des conteneurs parents afin de réduire la quantité de données à spécifier.
Modificateurs
Les modificateurs sont des éléments qui modifient l’aspect de certains conteneurs, par
exemple le type d’accès ou la durée du bail. Après avoir défini les pools d’options et
d’adresses, réfléchissez aux modificateurs à ajouter aux conteneurs. Les plus courants sont
leasetimedefault, supportBootp et supportUnlistedclients.
leasetimedefault
Définit la durée pendant laquelle une adresse est louée à un client.
supportBootp Détermine si le serveur doit répondre aux clients BOOTP.
Protocole TCP/IP
4-103
supportUnlistedclients
Indique si un client doit être explicitement défini par une instruction de client
pour recevoir une adresse. La valeur de supportUnlistedClients peut être
none (aucun), dhcp, bootp ou both (les deux). Vous pouvez ainsi
restreindre l’accès des clients bootp et autoriser tous les clients DHCP à
obtenir des adresses.
Pour connaître les autres modificateurs, reportez–vous à Syntaxe du fichier de serveur
DHCP pour la base de données db_file, page 4-121.
Journalisation
Une fois les modificateurs sélectionnés, configurez la fonction de journalisation. Les
paramètres de journalisation sont précisés dans un conteneur tel que la base de données,
mais le mot de passe du conteneur est : logging_info. Au démarrage, il est conseillé
d’activer le niveau de journalisation le plus élevé. En outre, il est préférable de configurer
cette fonction préalablement à toute autre afin que les erreurs de configuration puissent être
consignées après initialisation du sous–système de journalisation. Le mot–clé logitem
active le niveau de journalisation ; si vous supprimez logitem, le niveau de journalisation
sera désactivé. Les autres mots–clé concernant la journalisation permettent d’indiquer le
nom du fichier journal, sa taille et le nombre de journaux utilisés en alternance.
Options spécifiques au serveur
Le dernier groupe de paramètres concerne les options spécifiques au serveur, et permet à
l’utilisateur de contrôler le nombre de processeurs de paquets, la fréquence d’exécution des
routines de nettoyage, etc.
Voici deux exemples d’options spécifiques au serveur :
reservedTime Indique pendant combien de temps une adresse doit rester à l’état réservé
après l’envoi d’une OFFRE au client DHCP
reservedTimeInterval
Indique à quelle fréquence le serveur DHCP analyse les adresses
pour vérifier si certaines ne sont pas à l’état réservé depuis une durée
supérieure à celle définie par reservedTime.
Ces options sont pratiques si vous avez plusieurs clients qui diffusent des messages
DISCOVER, mais qui n’envoient pas de message REQUEST ou que leur message
REQUEST se perd sur le réseau. Ces paramètres permettent d’éviter la réservation
indéfinie des adresses pour un client non conforme.
Une autre option particulièrement importante, SaveInterval, permet de définir la fréquence
de sauvegarde. Toutes les options spécifiques au serveur sont répertoriées dans Syntaxe
du fichier de serveur DHCP pour le fonctionnement général du serveur, page 4-116 avec les
mots–clés de journalisation.
Considérations de performance
Vous n’êtes pas sans savoir que certains mots–clé de configuration ainsi que la structure du
fichier de configuration ont une incidence sur l’utilisation de la mémoire et les performances
du serveur DHCP.
Premièrement, il est possible d’éviter toute sollicitation excessive de la mémoire en
appréhendant le modèle d’héritage des options des conteneurs parents vers les conteneurs
enfants. Dans un environnement qui ne prend pas en charge les clients non répertoriés,
l’administrateur doit expressément lister chaque client du fichier. Lorsque des options sont
répertoriées pour chaque client en particulier, le serveur sollicite plus de capacité mémoire
pour stocker cette structure de configuration arborescente que lorsque des options sont
héritées d’un conteneur parent (conteneurs de sous–réseau, de réseau ou conteneurs
globaux, par exemple). Par conséquent, l’administrateur doit vérifier la répétition ou non des
options relatives au client au sein du fichier de configuration. Si tel est le cas, il doit décider
si ces options peuvent ou non être définies dans le conteneur parent et partagées par
l’ensemble des clients.
4-104
Guide de gestion du système – Communications et réseaux
Deuxièmement, l’utilisation des entrées logItem INFO et TRACE entraîne la consignation
de nombreux messages au cours du traitement de chaque message du client DHCP. L’ajout
d’une ligne au journal peut s’avérer une opération onéreuse. C’est pourquoi, la limitation du
volume de journalisation améliore les performances du serveur DHCP. En cas de
présomption d’erreur sur le serveur DHCP, la journalisation peut être dynamiquement
réactivée à l’aide des commandes SRC traceson ou dadmin.
Troisièmement, la sélection d’une valeur numprocessors doit dépendre de la taille du
réseau DHCP, du paramètre de configuration pingTime db_file et du délai de propagation
type sur le réseau. Etant donné que chaque routine de processeur de paquet émet une
requête d’écho ICMP pour vérifier l’état de l’adresse serveur avant de l’attribuer à un client,
le délai de réponse affecte directement la durée de traitement d’un message DISCOVER.
La routine de processeur de paquet se borne essentiellement à attendre une réponse ou le
pingTime. Par conséquent, la réduction de la valeur numprocessors améliore le temps de
réponse du serveur, et réduit par là–même le nombre de retransmissions par clients, sans
pour autant sacrifier les avantages que présentent le ping inhérent à la conception du
serveur.
Pour optimiser les performances, sélectionnez une valeur pingTime basée sur le délai de
propagation des réseaux distants pris en charge par le serveur DHCP. Sélectionnez
également numprocessors en fonction de la valeur pingTime et de la taille du réseau.
La sélection d’une valeur trop basse peut entraîner l’arrêt de toutes les routines de
traitement de paquet dans l’attente des réponses d’écho tandis que les messages client
DHCP entrants sont mis en attente sur le port du serveur. Celui–ci traite alors les messages
client par lots au lieu de les traiter en continu.
Une valeur sélectionnée trop petite peut causer l’arrêt du traitement de tous les paquets
dans l’attente de Echo Responses, ce qui provoquerait le.
Afin d’éviter ce cas de figure, la valeur de numprocessors doit être supérieure au nombre
prévu de messages DISCOVER pouvant être reçus dans un intervalle pingTime au cours
d’une période de forte activité client sur le DHCP. Toutefois, ne définissez pas une valeur
trop élevée pour numprocessors car la gestion de routines risquerait d’encombrer le
noyau.
A titre d’exemple, les valeurs numprocessors 5 et pingTime 300 offrent de faibles
performances dans un environnement pouvoir recevoir 10 messages DISCOVER par
seconde. En effet, en cas de forte sollicitation, 5 messages seulement peuvent être traités
toutes les 3 secondes. Cet environnement doit être configuré avec des valeurs se
rapprochant de numprocessors 20 et de pingTime 80.
Personnalisation d’un fichier de configuration
De nombreux administrateurs réseau ont à gérer des réseaux comprenant plusieurs types
de clients : ainsi, on peut trouver dans le même réseau des ordinateurs exécutant différents
systèmes d’exploitation, tels que Windows, OS/2, Java OS et UNIX. Chaque type de
machine requiert des identificateurs de fournisseurs uniques (c’est ce champ qui permet
d’indiquer le type de machine au serveur DHCP). Les clients Java et les machines Thin
Client peuvent exiger des paramètres qui leur sont propres, par exemple bootfiles, et il est
possible que vous deviez adapter les options de configuration en conséquence. En
revanche, les ordinateurs Windows 95 ne vont pas gérer correctement les options
spécifiques à Java. Il est donc possible d’encapsuler les options spécifiques à chaque
machine au sein de son conteneur fournisseur.
Pour reprendre notre exemple, imaginez une tâche principale dédiée à certaines machines
en fonction de leurs utilisateurs. Par exemple, le personnel de développement peut travailler
sur des clients de ce système d’exploitation pour effectuer des travaux de programmation,
le personnel du service marketing peut utiliser des clients OS/2, les membres du service
des ventes peuvent préférer les clients Java et les machines Thin Client, tandis que la
comptabilité a adopté des machines Windows 95. Chacune de ces familles d’utilisateurs
peut avoir besoin d’options de configuration différentes (imprimantes, serveurs de noms ou
serveurs Web par défaut, etc.). Dans un tel cas, il est possible d’inclure ces options dans le
Protocole TCP/IP
4-105
conteneur fournisseur, puisque chaque groupe utilise un type de machine différent. Si le
même type de machine était utilisé par plusieurs groupes, il serait possible de placer les
options au sein d’un identificateur de classe subordonné, ce qui permettrait, par exemple,
aux directeurs du marketing d’utiliser un groupe d’imprimantes non accessible au reste du
personnel.
Remarque : L’exemple suivant représente une portion d’un fichier de configuration. Les
commentaires sont précédés d’un symbole # et indiquent l’effet de chaque ligne sur
l’installation.
vendor ”AIX_CLIENT”
{
# Pas d’option spécifique, les différents éléments sont traités
en fonction de leur classe
}
vendor ”OS/2 Client”
{
# Pas d’option spécifique, les différents éléments sont traités
en fonction de leur classe
}
vendor ”Windows 95”
{ option 44 9.3.150.3
# Serveur de noms NetBIOS par
défaut
}
vendor ”Java OS”
{ bootstrapserver 9.3.150.4
# Serveur TFTP par défaut pour
les boîtes Java
option 67 ”javaos.bin”
# Fichier de démarrage de la boîte
Java OS
}
vendor ”IBM Thin Client”
{ bootstrapserver 9.3.150.5
# Serveur TFTP par défaut pour
les boîtes Thin Client
option 67 ”thinos.bin”
# Fichier de démarrage par défaut
pour les boîtes Thin Client
}
subnet 9.3.149.0 255.255.255.0
{ option 3 9.3.149.1
# Passerelle par défaut pour le
sous–réseau
option 6 9.3.150.2
# Serveur de noms pour le
sous–réseau
class accounting 9.3.149.5–9.3.149.20
{
# La classe de facturation est limitée à la plage
d’adresses 9.3.149.5–9.3.149.20
# L’imprimante destinée à ce groupe fait également
partie de cette plage, elle est donc exclue.
exclude 9.3.149.15
option 9 9.3.149.15
# Serveur LPR (serveur
d’impression)
vendor ”Windows 95”
{
option 9 deny
# Cette installation de Windows
95 ne prend pas en charge
# cette imprimante, l’option est
donc refusée.
}
}
. . .
}
4-106
Guide de gestion du système – Communications et réseaux
DHCP et DDNS (Dynamic Domain Name System –
Système de noms de domaine dynamique)
Le serveur DHCP fournit des options permettant le fonctionnement en environnement
DDNS. Pour utiliser DHCP dans l’environnement DDNS, vous devez définir et utiliser une
zone dynamique sur un serveur DNS.
Une fois le serveur DDNS configuré, vous devez décider si le serveur DHCP doit effectuer
des mises à jour d’enregistrement A, des mises à jour d’enregistrement PTR, des mises à
jour pour les deux types d’enregistrement ou aucune mise à jour. Cette décision dépendra
de la part de travail que peut prendre en charge la machine client.
• Si le client peut assumer une partie de la mise à jour, vous pouvez confier les mises à
jour d’enregistrement PTR au serveur et les mises à jour d’enregistrement A au client.
• Si le client peut tout assumer, configurez le serveur de sorte qu’il n’effectue aucune mise
à jour.
• Si le client ne peut se charger de rien, configurez le serveur de sorte qu’il effectue les
deux types de mise à jour.
Le serveur DHCP dispose d’un jeu de mots–clés de configuration qui vous permettent de
déclencher l’exécution d’une commande lorsqu’une mise à jour est requise. Ce sont les
suivants :
updatedns
(déconseillé) Représente la commande à exécuter pour effectuer n’importe
quel type de mise à jour. Elle sera appelée pour les enregistrements A et
les enregistrements PTR.
updatednsA
Spécifie la commande de mise à jour de l’enregistrement A.
updatednsP
Spécifie la commande de mise à jour de l’enregistrement PTR.
Ces mots–clés définissent des chaînes exécutables que le serveur DHCP exécute
lorsqu’une mise à jour est nécessaire. Les chaînes de mot–clé doivent contenir quatre %s
(symbole de pourcentage, lettre s). Le premier %s correspond au nom d’hôte ; le second,
au nom de domaine ; le troisième, à l’adresse IP et le quatrième, à la durée du bail. Ils sont
utilisés comme quatre premiers paramètres de la commande dhcpaction. Les deux autres
paramètres de la commande dhcpaction indiquent l’enregistrement à mettre à jour
(A, PTR, NONE ou BOTH) et si NIM doit être actualisé (NIM ou NONIM). Pour plus
d’informations sur les interactions NIM et DHCP, reportez–vous à DHCP et gestion NIM
(Network Installation Management), page 4-142. Par exemple :
updatednsA ”/usr/sbin/dhcpaction ’%s’ ’%s’ ’%s’ ’%s’ ’%s’ A NONIM”
# Ceci applique la commande dhcpaction uniquement à
l’enregistrement A
updatednsP ”/usr/sbin/dhcpaction ’%s’ ’%s’ ’%s’ ’%s’ ’%s’ PTR NONIM”
# Ceci applique la commande uniquement à
l’enregistrement PTR
updatedns ”/usr/sbin/dhcpaction ’%s’ ’%s’ ’%s’ ’%s’ ’%s’ BOTH NIM”
# Ceci applique la commande aux deux enregistrements
et actualise NIM
Le serveur DHCP dispose également d’un jeu de mots–clés pour supprimer les entrées
DNS lorsqu’un bail est libéré ou arrive à expiration. Ce sont les suivants :
releasednsA
Supprime l’enregistrement A.
releasednsP
Supprime l’enregistrement PTR.
removedns
Supprime les deux types d’enregistrement.
Ces mots–clés définissent des chaînes exécutables que le serveur DHCP exécute
lorsqu’une adresse est libérée ou périmée. La commande dhcpremove fonctionne de la
même manière que dhcpaction, mais n’accepte que trois paramètres :
1. L’adresse IP, spécifiée sous la forme d’un %s dans la chaîne de commande.
2. L’enregistrement à supprimer (A, PTR, NONE ou BOTH).
Protocole TCP/IP
4-107
3. L’actualisation éventuelle de NIM (NIM ou NONIM).
releasednsA ”/usr/sbin/dhcpremove ’%s’ A NONIM”
# Ceci applique la commande dhcpremove uniquement à
l’enregistrement A
releasednsP ”/usr/sbin/dhcpremove ’%s’ PTR NONIM”
# Ceci applique la commande uniquement à
l’enregistrement PTR
removedns ”/usr/sbin/dhcpremove ’%s’ BOTH NIM”
# Ceci applique la commande aux deux enregistrements
et actualise NIM
Les scripts dhcpaction et dhcpremove effectuent quelques vérifications sur les
paramètres, puis définissent un appel vers nsupdate, qui a été adapté pour fonctionner
avec les serveurs de ce système d’exploitation et les serveurs DDNS OS/2. Pour plus
d’informations, reportez–vous à la description de la commande nsupdate.
Si l’interaction NIM n’est PAS requise par la mise à jour des noms, le serveur DHCP peut
être configuré afin d’utiliser un transfert de sockets entre le démon DHCP et la commande
nsupdate afin d’améliorer les performances et de permettre la reprise des mises à jour
DNS à la suite d’une défaillance. Pour configurer cette option, le premier mot cité dans le
mot–clé updateDNSA, updateDNSP, releaseDNSA ou releaseDNSP doit être
”nsupdate_daemon”. Les paramètres et les indicateurs de mise à jour sont identiques à
ceux qui sont acceptés par la commande nsupdate. De plus, les noms de variables
suivants peuvent être utilisés en remplacement :
$hostname
Remplacé par le nom d’hôte du client lors de la mise à jour
DNS ou par le nom d’hôte préalablement associé au client
pour le retrait DNS.
$domain
Remplacé par le domaine DNS relatif à la mise à jour ou
par le domaine préalablement utilisé pour le nom d’hôte du
client dans le cas de retrait DNS.
$ipadress
Remplacé par l’adresse IP associée ou dissociée du nom
du client DHCP.
$leasetime
Remplacé par la durée du bail (en secondes).
$clientid
Remplacé par la représentation en chaîne de l’identificateur
du client DHCP ou par l’association du type de matériel et
de l’adresse matérielle pour les clients BOOTP.
Par exemple :
updateDNSA ”nsupdate_daemon –p 9.3.149.2 –h $hostname –d $domain
updateDNSP ”nsupdate_daemon –p 9.3.149.2 –r $ipaddress
releaseDNSA ”nsupdate_daemon –p 9.3.149.2 –h $hostname –d $domain –
s”d;a;*;s;1;3110400””
releaseDNSP ”nsupdate_daemon –p 9.3.149.2 –r $ipaddress –s”d;ptr;*;
s;1;3110400””
Pour plus d’informations, reportez–vous à la description de la commande nsupdate.
Des dispositifs définis par l’administrateur ont également été ajoutés pour les échanges
de noms d’hôte entre le serveur et les clients. Par défaut, le nom d’hôte retourné au client
et utilisé pour une mise à jour DDNS correspond à l’option 12 (définie dans le fichier de
configuration du serveur ). Toutefois, ce nom d’hôte par défaut peut également être un nom
d’hôte suggéré par le client, par le biais de l’option 81 (option DHCPDDNS) ou de l’option
12 (option HOSTNAME). L’administrateur a la possibilité de remplacer ce nom d’hôte
par défaut en utilisant les mots–clés de configuration hostnamepolicy, proxyarec et
4-108
Guide de gestion du système – Communications et réseaux
appenddomain. Ces options et leurs paramètres sont définis dans Syntaxe du fichier
de serveur DHCP pour la base de données db_file, page 4-121.
Compatibilité DHCP avec les versions antérieures
Le serveur DHCP pour AIX Version 4.3.1 et ultérieures reconnaît les fichiers de
configuration et de base de données des versions antérieures, dhcps.ar et dhcps.cr.
Il analyse les anciens fichiers de configuration et génère de nouveaux fichiers de base
de données aux anciens emplacements. Les anciennes bases de données sont
automatiquement converties au nouveau format. Le fichier de configuration lui–même n’est
pas converti.
Le module de base de données du serveur DHCP, db_file, est capable de lire l’ancien
format. Le serveur DHCP est en mesure de détecter si un conteneur de base de données
est absent du fichier de configuration et considère dans ce cas que le fichier contient tous
les paramètres de serveur, les paramètres de journalisation et les paramètres de base de
données db_file.
Remarques :
1. Une partie de la syntaxe de l’ancien fichier de configuration est déconseillée mais
toujours prise en charge. Les autres éléments obsolètes sont les suivants :
2. Le conteneur réseau est totalement obsolète. Pour obtenir une spécification correcte,
convertissez la clause réseau en une plage au sein d’un conteneur de sous–réseau
correct mentionnant une adresse de sous–réseau, un masque de sous–réseau et la
plage d’adresses. Si le conteneur réseau renferme des conteneurs de sous–réseau,
supprimez le mot–clé du conteneur réseau et ses accolades, puis placez le masque de
sous–réseau à l’endroit approprié sur la ligne. Pour démarrer à l’aide du conteneur base
de données, regroupez tous les éléments ayant trait au réseau et aux accès client dans
un seul conteneur de base de données de type db_file.
3. Les mots–clés updatedns et removedns sont obsolètes et seront remplacés de
préférence par la spécification des actions à appliquer individuellement aux
enregistrements A et PTR.
4. Les mots–clés clientrecorddb et addressrecorddb ont été supplantés respectivement
par clientrecorddb et backupfile.
5. Les mots–clés option sa et option ga ont été remplacés respectivement par
bootstrapserver et giaddrfield. Pour plus d’informations, reportez–vous à la section
Syntaxe du fichier de serveur DHCP pour le fonctionnement général du serveur,
page 4-116 et à Syntaxe du fichier de serveur DHCP pour la base de données db_file,
page 4-121.
Options connues du fichier de serveur DHCP
Remarque :
Les options du tableau suivant qui sont marquées non autorisées peuvent
être spécifiées (Non dans la colonne Autorisée ?) dans le fichier de
configuration mais seront remplacées par la valeur réelle. Pour une
définition plus complète de chaque option, reportez–vous à la norme
RFC 2132.
Numéro Type de données par
de
défaut
l’option
Autorisée
?
Description/Emploi
0
Non
Complète le champ d’option, si
nécessaire. Le serveur ajoute des
caractères de remplissage le cas
échéant.
Aucune
Protocole TCP/IP
4-109
4-110
1
Dotted quad (quatre
numéros séparés par
points )
Non
Masque du sous–réseau d’où est tiré
l’adresse.
2
Entier 32 bits
Oui
Indique le décalage du sous–réseau
du client, en secondes du système
UTC (Coordinated Universal Time).
3
Un ou plusieurs ”dotted
quad”
Oui
Liste des adresses IP de la passerelle
par défaut.
4
Un ou plusieurs ”dotted
quad”
Oui
Liste des adresses IP des serveurs
horaires.
5
Un ou plusieurs ”dotted
quad”
Oui
Liste des adresses IP des serveurs de
noms.
6
Un ou plusieurs ”dotted
quad”
Oui
Liste des adresses IP des DNS.
7
Un ou plusieurs ”dotted
quad”
Oui
Liste des adresses IP des serveurs de
journaux.
8
Un ou plusieurs ”dotted
quad”
Oui
Liste des adresses IP des serveurs de
”cookies”.
9
Un ou plusieurs ”dotted
quad”
Oui
Liste des adresses IP des serveurs
LPR.
10
Un ou plusieurs ”dotted
quad”
Oui
Liste des adresses IP des serveurs
Impress.
11
Un ou plusieurs ”dotted
quad”
Oui
Liste des adresses IP des serveurs de
localisation des ressources.
12
Chaîne ASCII
Oui
Nom d’hôte du client à utiliser.
13
Entier 16 bits non signé
Oui
Taille du fichier de démarrage.
14
Chaîne ASCII
Oui
Chemin d’accès du fichier Merit Dump.
15
Chaîne ASCII
Oui
Nom de domaine DNS par défaut.
16
Adresse IP
Oui
Adresse du serveur Swap.
17
Chaîne ASCII
Oui
Chemin d’accès racine par défaut.
18
Chaîne ASCII
Oui
Chemin d’accès aux extensions pour
le client.
19
Yes, No, True, False, 1, 0
Oui
Indique si le réacheminement IP doit
être activé ou non.
20
Yes, No, True, False, 1, 0
Oui
Indique si le routage source non local
doit être utilisé.
21
Une ou plusieurs paires de Oui
”dotted quad”, sous la
forme
DottedQuad:DottedQuad
Dispositifs de filtre pour les adresses
IP.
22
Entier 16 bits non signé
Oui
Taille maximale autorisée pour les
fragments de datagrammes.
23
Entier 8 bits non signé
Oui
TTL (time–to–live) IP.
24
Entier 32 bits non signé
Oui
Nombre de secondes à utiliser dans le
délai de vieillissement du MTU
d’accès.
25
Liste d’un ou plusieurs
entiers 16 bits non signés
Oui
Table des valeurs MTU d’accès.
Spécifie un ensemble de valeurs
représentant les tailles MTU à utiliser
lors de la recherche de MTU d’accès.
Guide de gestion du système – Communications et réseaux
26
Entier 16 bits non signé
Oui
Taille MTU pour l’interface réceptrice.
27
Yes, No, True, False, 1, 0
Oui
Indique si tous les sous–réseaux sont
locaux.
28
Une adresse IP (”dotted
quad”)
Oui
Diffuse une adresse pour l’interface.
29
Yes, No, True, False, 1, 0
Oui
Indique si la recherche de masque de
réseau ICMP doit être utilisée.
30
Yes, No, True, False, 1, 0
Oui
Indique si le client doit devenir un
fournisseur de masque de réseau
ICMP.
31
Yes, No, True, False, 1, 0
Oui
Indique si les messages de recherche
de routeur ICMP doivent être utilisés.
32
Une adresse IP (”dotted
quad”)
Oui
Adresse à utiliser pour la sollicitation
du routeur.
33
Une ou plusieurs paires
d’adresses IP, sous la
forme
DottedQuad:DottedQuad
Oui
Chaque paire d’adresses représente
une route statique.
34
Yes/No, True/False, 1/0
Oui
Indique si l’encapsulation de fin doit
être utilisée.
35
Entier 32 bits non signé
Oui
Valeur du délai de cache ARP.
36
Yes/No, True/False, 1/0
Oui
Indique si l’encapsulation
Ethernet doit être utilisée.
37
Entier 8 bits non signé
Oui
TTL (time–to–live) TCP.
38
Entier 32 bits non signé
Oui
Intervalle de garde en vie
(keep alive) TCP.
39
Yes/No, True/False, 1/0
Oui
Indique si la garde en vie
(keep alive) TCP doit être utilisée.
40
Chaîne ASCII
Oui
Domaine NIS par défaut.
41
Un ou plusieurs ”dotted
quad”
Oui
Adresses IP des serveurs NIS.
42
Un ou plusieurs ”dotted
quad”
Oui
Adresses IP des serveurs NTP.
43
Chaînes hexadécimales
de chiffres, sous la forme
hex ”digits”, hex ”digits” ou
0xdigits
Oui, mais Conteneur en option encapsulé
spécifiée pour le conteneur fournisseur.
en fait
uniqueme
nt pour le
conteneur
fournisse
ur
44
Un ou plusieurs ”dotted
quad”
Oui
Adresses IP des serveurs de noms
NetBIOS.
45
Un ou plusieurs ”dotted
quad”
Oui
Adresses IP des serveurs de
distribution de datagramme NetBIOS.
46
Entier 8 bits non signé
Oui
Type de nœud NetBIOS.
47
Oui
Chaînes hexadécimales
de chiffres, sous la forme
hex ”digits”, hex ”digits” ou
0xdigits
Portée NetBIOS.
Protocole TCP/IP
4-111
4-112
48
Un ou plusieurs ”dotted
quad”
Oui
Adresses IP des serveurs
de polices X Windows.
49
Un ou plusieurs ”dotted
quad”
Oui
Gestionnaire d’affichage X Windows.
50
Aucune
Non
Adresse IP demandée, utilisée
par le client pour indiquer l’adresse
souhaitée.
51
Entier 32 bits non signé
Oui
Durée du bail pour l’adresse
retournée. Par défaut, le serveur
DHCP utilise le mot–clé
leasetimedefault, mais la
spécification directe de l’option 51
prend le pas sur la valeur.
52
Aucune
Non
Options éventuelles. Le client utilise
ce paramètre pour indiquer que les
champs sname et file du paquet
BOOTP peuvent avoir des options.
53
Aucune
Non
Le serveur ou le client DHCP utilise
cette option pour indiquer le type de
message DHCP.
54
Aucune
Non
Le serveur ou le client DHCP utilise
cette option pour indiquer l’adresse
du serveur ou le serveur auquel le
message est envoyé.
55
Aucune
Non
Le client DHCP utilise ce paramètre
pour indiquer les options souhaitées.
56
Chaîne ASCII
Oui
Chaîne que le serveur DHCP envoie
au client. En général, elle peut être
utilisée par le client et le serveur
DHCP pour signaler des problèmes.
57
Non
Non
Le client DHCP utilise cette option
pour indiquer au serveur DHCP la
taille de paquet DHCP maximale
que le client peut recevoir.
58
Entier 32 bits non signé
Oui
Nombre de secondes pendant
lesquelles le client doit attendre
avant d’envoyer un paquet
de renouvellement.
59
Entier 32 bits non signé
Oui
Nombre de secondes pendant
lesquelles le client doit attendre
avant d’envoyer un paquet
de nouvelle liaison.
60
Aucune
Non
Le client DHCP utilise cette option
pour indiquer son type de fournisseur.
Le client DHCP utilise ce champ pour
la correspondance avec les
conteneurs fournisseur.
61
Aucune
Non
Le client DHCP utilise ce paramètre
pour s’identifier de manière unique.
Le serveur DHCP utilise ce champ
pour la correspondance avec les
conteneurs client.
64
Chaîne ASCII
Oui
Spécifie le domaine NIS+.
Guide de gestion du système – Communications et réseaux
65
Un ou plusieurs ”dotted
quad”
Oui
Adresses IP des serveurs NIS+.
66
Chaîne ASCII
Oui
Spécifie le nom du serveur TFTP.
Ce nom d’hôte est utilisé à la place
du champ siaddr si le client comprend
cette option.
67
Chaîne ASCII
Oui
Spécifie le nom du fichier de
démarrage. Ce paramètre peut être
utilisé à la place du mot–clé bootfile,
qui insère le nom du fichier dans le
champ nom de fichier du paquet.
68
Un ou plusieurs ”dotted
quad” ou NONE
Oui
Adresses des agents personnels.
69
Un ou plusieurs ”dotted
quad”
Oui
Serveurs SMTP par défaut à utiliser.
70
Un ou plusieurs ”dotted
quad”
Oui
Serveurs POP3 par défaut à utiliser.
71
Un ou plusieurs ”dotted
quad”
Oui
Serveurs NNTP par défaut à utiliser.
72
Un ou plusieurs ”dotted
quad”
Oui
Serveurs WWW par défaut à utiliser.
73
Un ou plusieurs ”dotted
quad”
Oui
Serveurs Finger par défaut à utiliser.
74
Un ou plusieurs ”dotted
quad”
Oui
Serveurs IRC par défaut à utiliser.
75
Un ou plusieurs ”dotted
quad”
Oui
Serveurs Street Talk par défaut à
utiliser.
76
Un ou plusieurs ”dotted
quad”
Oui
Serveurs de renseignements Street
Talk par défaut à utiliser.
77
Chaîne ASCII
Oui
Identificateur de la classe du site
utilisateur. Le serveur DHCP utilise
ce champ pour la correspondance
avec les conteneurs classe.
78
Octet obligatoire, un ou
Oui
plusieurs « dotted quads »
L’option SLP directory Agent indique
la liste des adresses IP des agents
de répertoire
79
Octet obligatoire et chaîne
ASCII
Oui
La chaîne ASCII est une liste de
portées, c’est–à–dire une liste
délimitée par des virgules qui indique
les portées qu’un agent SLP est
configuré pour utiliser.
81
Chaîne ASCII plus
d’autres éléments
Non
Le client DHCP utilise cette option
pour définir la politique que doit suivre
le serveur DHCP vis à vis de DDNS.
85
Un ou plusieurs ”dotted
quad”
Oui
L’option de serveur NDS indique un
ou plusieurs serveurs que le client doit
contacter pour accéder à la base de
données DNS. Les serveurs doivent
être répertoriés dans l’ordre de
préférence.
Protocole TCP/IP
4-113
86
Chaîne ASCII
Oui
L’option d’arborescence NDS indique
le nom de l’arborescence NDS que le
client va contacter.
87
Chaîne ASCII
Oui
L’option de contexte NDS indique le
contexte NDS initial que le client doit
utiliser.
93
Aucune
Non
Le client DHCP utilise cette option
pour définir l’architecture du système
client.
94
Aucune
Non
Le client DHCP utilise cette option
pour définir l’identifiant de l’interface
du réseau client.
117
Liste d’un ou plusieurs
entiers 16 bits non signés
Oui
L’option Name Service Search Option
indique l’ordre de préférence du code
d’option des entiers pour les services
de noms. Par exemple :
Services de nom
valeur
Option de serveur de noms
de domaine 6
Option NIS
41
Option NIS+
65
118
Un ”dotted quad”
Non
Subnet Selection Option est une
option envoyée par le client
demandant au serveur dhcp d’allouer
l’adresse IP à partir du sous–réseau
indiqué.
255
Aucune
Non
Le serveur et le client DHCP utilisent
cette option pour signaler la fin d’une
liste d’options.
Sous–option de conteneur fournisseur de l’environnement PXE
(Preboot Execution Environment)
Dans le cadre de la prise en charge d’un environnement PXE client, le serveur DHCP
transmet l’option suivante au serveur BINLD, qui l’utilise pour sa configuration :
4-114
Opt Num
Type de données
par défaut
Autorisée ?
Description
7
Un ”dotted quad”
Oui
Adresse IP de multi–diffusion.
Adresse IP de multi–diffusion de
découverte du serveur de
démarrage.
Guide de gestion du système – Communications et réseaux
L’exemple ci–dessous montre comment cette option peut être utilisée :
pxeservertype
proxy_on_dhcp_server
Vendor pxeserver
{
option
7
9.3.4.68
}
Dans cet exemple, le serveur DHCP informe le client que le serveur proxy est exécuté sur
la même machine mais est à l’écoute des requêtes sur le port 4011. Le conteneur
fournisseur est requis ici car le serveur BINLD diffuse un message INFORM/REQUEST
sur le port 67, l’option 60 étant définie sur ”PXEServer”. En retour, le serveur DHCP envoie
l’adresse IP de multi–diffusion sur laquelle le serveur BINLD doit écouter les requêtes du
client PXE.
Exemple de fichier de configuration prenant en charge les clients PXE
Dans l’exemple ci–dessous, le serveur dhcpsd donne le nom du fichier de démarrage
au PXEClient ou dirige celui–ci sur le serveur BINLD en envoyant des sous–options.
Le mot–clé pxeboofile est utilisé pour créer une liste de fichiers de démarrage pour
l’architecture d’un client donné et des versions majeures et mineures du système client.
pxeservertype
dhcp_pxe_binld
subnet default
{
vendor pxe
{
option 6 2
# Désactiver la multidiffusion
option 8 5 4 10.10.10.1 12.1.1.15 12.5.5.5 12.6.6.6\
2 2 10.1.1.10 9.3.4.5 1 1 10.5.5.9\
1 1 9.3.149.15\
4 0
option 9 5 ”WorkSpace On Demand” 2 ”Intel”\
1 ”Microsoft WindowsNT” 4 ”NEC ESMPRO”
option 10 2 ”Press F8 to View Menu”
}
vendor pxeserver
{
option 7 239.0.0.239
}
}
subnet 9.3.149.0 255.255.255.0
{
option 3
9.3.149.1
option 6
9.3.149.15
vendor pxe
{
option
6
4
# bootfile est présent dans le paquet propos
é
pxebootfile
pxebootfile
}
1
2
2
2
1
1
os2.one
aix.one
}
Chaque ligne d’option du conteneur pxe est utilisée par le serveur pour indiquer au client ce
qu’il doit faire. La section Sous–options du conteneur fournisseur PXE, page 4-175 décrit
les sous–options du conteneur fournisseur PXE reconnues et prises en charge à l’heure
actuelle.
Protocole TCP/IP
4-115
Syntaxe du fichier de serveur DHCP pour le fonctionnement
général du serveur
Remarque :
Les unités de temps (time_units) indiquées dans le tableau suivant sont
facultatives et correspondent à un modificateur du temps réel. L’unité de
temps par défaut est exprimée en minutes. Les valeurs autorisées sont
les secondes (1), les minutes (60), les heures (3600), les jours (86400),
les semaines (604800), les mois (2392000) et les années (31536000).
Le nombre entre parenthèses est un multiplicateur appliqué à la valeur n
spécifiée pour exprimer cette valeur en secondes.
Mot–clé
Forme
Sous– Valeur
conte– par
neurs défaut
Signification
database
database db type
Oui
Aucune
Conteneur principal renfermant les
définitions des pools d’adresses,
options et instructions d’accès
client. db type est le nom du
module chargé pour traiter cette
portion du fichier. La seule valeur
actuellement disponible est
db_file.
logging_info
logging_info
Oui
Aucune
Conteneur de journalisation
principal définissant les
paramètres de journalisation.
logitem
logitem NONE
Non
Non
activé
ti é
pour tous
par
défaut.
Active le niveau de journalisation.
Pl i
Plusieurs
lignes
li
sontt autorisées.
t i é
logitem SYSERR
logitem OBJERR
logitem PROTOCOL
logitem PROTERR
logitem WARN
logitem WARNING
logitem CONFIG
logitem EVENT
logitem PARSEERR
logitem ACTION
logitem ACNTING
logitem STAT
logitem TRACE
logitem RTRACE
logitem START
4-116
numLogFiles
numLogFiles n
Non
0
Indique le nombre de fichiers
journaux à créer. Les journaux
alternent lorsque le premier journal
est rempli. n est le nombre de
journaux à créer.
logFileSize
logFileSize n
Non
0
Indique la taille de chaque fichier
journal, exprimée en unités de
1024 octets.
Guide de gestion du système – Communications et réseaux
Mot–clé
Forme
Sous– Valeur
conte– par
neurs défaut
Signification
logFileName
logFileName path
Non
Aucune
Indique le chemin d’accès au
premier fichier journal. Le nom
d’origine du fichier journal est
nomfichier ou
nomfichier.extension. Lorsque
la permutation des fichiers est
effectuée, le premier fichier est
renommé en conservant la base
du nom, nomfichier, et en lui
ajoutant un numéro, ou en
remplaçant l’extension par un
numéro. Par exemple, si le nom
original du fichier est file, le nom
du fichier après permutation
devient file01. Si le nom du
fichier d’origine est file.log, il
devient file.01.
CharFlag
charflag yes
Non
true
Non applicable au serveur DHCP
d ce système
de
tè
d’
d’exploitation,
l it ti
mais
i
utilisé par le serveur DHCP OS/2
pour générer des fenêtres de
débogage.
charflag true
charflag false
charflag no
StatisticSnapS
hot
StatisticSnapShot n
Non
–1, jamais Indique, en secondes, à quelle
fréquence les statistiques sont
écrites dans le fichier journal.
UsedIpAddres
s
ExpireInterval
UsedIpAddressExpire
Interval n time_units
Non
–1, jamais Indique à quelle fréquence les
adresses présentant l’état BAD
sont recoupées et testées afin de
vérifier leur validité.
leaseExpireInt
erval
leaseExpireInterval n
time_units
Non
900
secondes
reservedTime
reservedTime n
time_units
Non
–1, jamais Indique pendant combien de
temps les adresses peuvent rester
à l’état RESERVED avant de
reprendre l’état FREE.
reservedTime
Interval
reservedTimeInterval
n time_units
Non
900
secondes
Indique à quelle fréquence les
adresses à l’état BOUND sont
vérifiées pour voir si elles sont
arrivées à expiration. Si l’adresse
est arrivée à expiration, l’état
devient EXPIRED.
Indique à quelle fréquence les
adresses à l’état RESERVE sont
vérifiées pour voir si elles peuvent
reprendre l’état FREE.
Protocole TCP/IP
4-117
4-118
Mot–clé
Forme
Sous– Valeur
conte– par
neurs défaut
Signification
saveInterval
saveInterval n
time_units
Non
3600
secondes
Indique à quelle fréquence le
serveur DHCP doit déclencher une
sauvegarde des bases de
données ouvertes. Pour les
serveurs très chargés, cette valeur
doit tourner autour de 60 ou 120
secondes.
clientpruneintv
clientpruneintv n
time_units
Non
3600
secondes
Indique à quelle fréquence le
serveur DHCP supprime des
bases de données les clients non
associés à une adresse (état
UNKNOWN). Ceci permet
d’économiser la mémoire du
serveur DHCP.
num
processors
numprocessors n
Non
10
Indique le nombre de processeurs
de paquets à créer. Le minimum
est de un.
userObject
userObject obj_name
Oui
Aucune
Indique que le serveur doit charger
un objet partagé défini par
l’utilisateur et appeler des routines
au sein de cet objet par le biais de
chaque interaction avec les clients
DHCP. L’objet à charger est situé
dans le répertoire /usr/sbin
sous le nom de
obj_name.dhcpo. Pour plus
d’informations, reportez–vous au
DHCP Server User–Defined
Extension API.
Guide de gestion du système – Communications et réseaux
Mot–clé
Forme
Sous–
conte–
neurs
Valeur par
défaut
Signification
pxeservertype
pxeservertype
server_type
No
dhcp_only
Indique le type du
serveur dhcpd.
server_type peut
avoir l’une des
valeurs suivantes :
dhcp_pxe_binld
DHCP exécute
les fonctions
dhcpsd, pxed et
bindl.
proxy_on_dhcp_server
DHCP renvoie le
client PXE au
port du serveur
proxy sur la
même machine.
La valeur par
défaut est
dhcp_only, ce qui
signifie que
dhcpsd ne prend
pas en charge les
clients PXE en
mode par défaut.
Protocole TCP/IP
4-119
Mot–clé
Forme
Sous–
conte–
neurs
supportsubnetselec
No
tion
supportsubnetselec
tion global
supportsubnetselec
tion subnetlevel
supportsubnetselec
tion no
Valeur par
défaut
Signification
Aucune
Indique si le
serveur dhcp prend
en charge l’option
118 (option de
sélection du
sous–réseau) dans
le paquet
DISCOVER ou
REQUEST des
clients.
global: tous les
sous–réseaux du
fichier de
configuration
prennent en charge
l’option 118.
subnetlevel: les
sous–réseaux
configurés pour
prendre en charge
cette option via le
mot–clé support
option 118
acceptent cette
option.
no: ne prend pas
en charge l’option
118.
4-120
Guide de gestion du système – Communications et réseaux
Remarques sur la syntaxe du fichier de serveur DHCP
pour la base de données db_file :
Remarques :
1. Les unités de temps (time_units) indiquées dans le tableau suivant sont facultatives et
correspondent à un modificateur du temps réel. L’unité de temps par défaut est exprimée
en minutes. Les valeurs autorisées sont les secondes (1), les minutes (60), les heures
(3600), les jours (86400), les semaines (604800), les mois (2392000) et les années
(31536000). Le nombre entre parenthèses est un multiplicateur appliqué à la valeur n
spécifiée pour exprimer cette valeur en secondes.
2. Par ailleurs, les éléments spécifiés dans un conteneur peuvent être remplacés par ceux
d’un sous–conteneur. Vous pouvez par exemple définir les clients BOOTP de manière
globale, et, au sein d’un sous–réseau particulier, autoriser les clients BOOTP en
indiquant le mot–clé supportBootp dans les deux conteneurs.
3. Les conteneurs client, classe et fournisseur acceptent les expressions régulières.
Pour la classe et le vendeur, une chaîne entre guillemets dont le premier caractère à
l’intérieur des guillemets est un point d’exclamation (!) indique que le reste de la chaîne
doit être considéré comme une expression régulière. Le conteneur client accepte les
expressions régulières dans les champs hwtype et hwaddr. Une chaîne unique est
utilisée pour représenter les deux champs, selon la syntaxe suivante :
nombre_décimal–données
Si nombre_décimal est égal à zéro, les données constituent
une chaîne ASCII. Pour tout autre nombre, les données sont des
chiffres hexadécimaux.
Mot–clé
Forme
Sous–
conte–
neurs
Valeur par
défaut
Signification
subnet
subnet default
Oui
Aucune
Spécifie un
sous–réseau sans
plage associée.
Ce sous–réseau est
utilisé par le serveur
uniquement pour
répondre à un paquet
INFORM/REQUEST
du client et si aucun
conteneur de
sous–réseau ne
correspond à
l’adresse de ce
dernier.
Protocole TCP/IP
4-121
subnet
subnet subnet id
netmask
Oui
Aucune
Spécifie un
sous–réseau et un
pool d’adresses.
Toutes les adresses
sont supposées faire
partie du pool, sauf si
une plage est
spécifiée sur la ligne
ou si les adresses
sont modifiées
ultérieurement dans le
conteneur par une
instruction de plage
ou d’exclusion. La
plage facultative est
une paire d’adresses
IP en format de
”dotted quad”
séparées par un tiret.
Il est possible de
préciser un label et
une priorité. Ceux–ci
sont utilisés dans les
sous–réseaux virtuels
pour identifier et
classer les
sous réseaux du
sous–réseaux
sous–réseau virtuel.
Le label et la priorité
sont séparés par un
signe deux–points.
Ces conteneurs ne
sont autorisés qu’au
niveau global ou au
niveau du conteneur
base de données.
Oui
Aucune
Spécifie un
sous–réseau qui
s’inscrit dans un
conteneur réseau.
Il définit une plage
d’adresses formant la
totalité du
sous–réseau, sauf si
la plage facultative est
indiquée. Le masque
de réseau associé au
sous–réseau est issu
du conteneur réseau
environnant.
subnet subnet id
netmask range
subnet subnet id
netmask label:priority
subnet subnet id
netmask range
label:priority
subnet
subnet subnet id
range
Remarque : Cette
méthode est
déconseillée au profit
des autres formes de
sous–réseaux.
4-122
Guide de gestion du système – Communications et réseaux
option
option number data ...
Non
Aucune
exclude an IP address Non
Aucune
option numberdeny
option * deny
exclude
exclude
dotted_quad–dotted_
quad
Spécifie une option à
envoyer à un client
ou, dans le cas d’un
refus (deny), une
option qui ne doit pas
être envoyée à un
client. La clause
option * deny
signifie que toutes les
options non spécifiées
dans le conteneur en
cours ne d
doivent
i
t pas
être retournées au
client. L’option
numberdeny ne
refuse que l’option
spécifiée. number est
un entier 8 bits non
signé. data est
spécifique à l’option
(voir ci–dessus) ou
peut être définie sous
d’une
la forme d
une chaîne
entre guillemets (texte
ASCII) ou 0xhexdigits
ou hex”hexdigits” ou
encore hex
”hexdigits”. Si l’option
correspond à un
conteneur fournisseur,
elle sera encapsulée
avec les autres
options dans une
option 43.
Modifie la plage sur le
conteneur qui
comporte l’instruction
exclude. L’instruction
exclude n’est pas
valide au niveau des
conteneurs de base
de données ou au
général
niveau général.
L’instruction exclude
supprime l’adresse ou
la plage spécifiée de
la plage actuelle sur le
conteneur. Elle
permet de créer des
plages non contiguës
pour sous
sous–réseaux ou
d’autres conteneurs.
Protocole TCP/IP
4-123
range
range IP_address
Non
range
dotted_quad–dotted_
quad
4-124
Guide de gestion du système – Communications et réseaux
Aucune
Modifie la plage sur le
conteneur qui
comporte l’instruction
range. L’instruction
range n’est pas valide
au niveau des
conteneurs de base
de données ou au
niveau général. S’il
s’agit de la première
plage du conteneur
qui ne spécifie pas
une plage sur la ligne
de définition du
conteneur, la plage du
conteneur devient
alors la plage
spécifiée
par
p
p
l’instruction range.
Toute instruction
range suivante, ou
toutes les instructions
range dans le cas
d’un conteneur
spécifiant des plages
dans sa définition sont
ajoutées à la page
actuelle. Avec
l’instruction range, il
est possible d’ajouter
à la plage existante
une adresse unique
ou un jeu d’adresses.
La plage doit être
incorporée dans la
définition du
conteneur de
sous–réseau.
client
client hwtype hwaddr
NONE
Oui
Aucune
Spécifie un conteneur
client qui empêche le
client indiqué par
hwaddr et hwtype
d’obtenir une adresse.
Si hwtype est 0, alors
hwaddr est une
chaîne ASCII. Sinon,
hwtype correspond au
type de matériel du
client et hwaddr à
l’adresse du matériel
du client. Si hwaddr
est une chaîne, des
guillemets peuvent
encadrer la chaîne.
chaîne
Si hwaddr est une
chaîne hexadécimale,
l’adresse peut être
spécifiée sous la
forme 0xhexdigits ou
hex digits. range
permet au client
spécifié par hwaddr et
hwtype d’obtenir une
adresse faisant partie
de cette plage. Pour
faire référence à
plusieurs clients,
il faut utiliser une
expression régulière.
Oui
Aucune
Spécifie un conteneur
classe portant le nom
string. La chaîne peut
ou non être placée
entre guillemets. Si
oui, les guillemets
sont supprimés avant
la comparaison.
Les guillemets sont
obligatoires si la
chaîne contient des
espaces ou des
tabulations. Ce
conteneur est autorisé
à tous les niveaux. Il
est possible d’indiquer
une plage pour
spécifier le jeu
d’adresses à proposer
au client avec cette
classe. La plage est
soit une adresse IP en
format de ”dotted
quad”, soit deux
adresses IP en format
de ”dotted quad”
séparées par un tiret.
client hwtype hwaddr
ANY
client hwtype hwaddr
dotted_quad
client hwtype hwaddr
range
class
class string
class string range
Protocole TCP/IP
4-125
réseau
network network id
netmask
Oui
network network id
network network id
range
Aucune
Spécifie un ID de
réseau à l’aide des
informations de classe
(par exemple
9.3.149.0 avec un
masque de réseau de
255.255.255.0
correspond au réseau
9.0.0.0
255.255.255.0).
Cette version du
conteneur de réseau
est utilisée pour
englober les
sous–réseaux
partageant le même
masque et le même
ID de réseau.
Lorsqu’une plage est
fournie, toutes les
adresses de la plage
font partie du pool.
La plage doit être
comprise dans le
réseau de ll’ID
ID de
réseau. Elle fait appel
à l’adresse intégrale
de la classe. Elle n’est
valide qu’au niveau
général ou au niveau
du conteneur de base
de données.
Remarque :
Le mot–clé network
est déconseillé au
profit du conteneur
de sous–réseau.
4-126
Guide de gestion du système – Communications et réseaux
vendor
vendor vendor_id
vendor vendor_id
hex””
vendor vendor_id hex
””
vendor vendor_id
0xdata
vendor vendor_id ””
vendor vendor_id
range
vendor vendor_id
range hex””
vendor vendor_id
range hex ””
vendor vendor_id
range 0xdata
vendor vendor_id
range ””
Oui
Aucune
Spécifie un conteneur
de fournisseur.
Les conteneurs
fournisseur sont
utilisés pour retourner
l’option 43 au client.
L’id de fournisseur
peut être spécifié
sous la forme d
d’une
une
chaîne entre
guillemets ou d’un
chaîne binaire du type
0xhexdigits ou
hex”digits” Il est
hex”digits”.
possible d’ajouter à
l’id de fournisseur une
plage facultative, en
utilisant deux ”dotted
quad” séparés par un
tiret. A la suite de la
plage facultative, une
chaîne hexadécimale
ou ASCII également
facultative peut être
indiquée comme
première partie de
l’option 43. Si des
options figurent dans
le conteneur, elles
sont annexées aux
données de l’option
43. Une fois toutes les
options
ti
ttraitées,
ité
une
option End Of Option
List (fin de la liste
d’options) est ajoutée
aux données. Pour
retourner lles options
i
en dehors d’une
option 43, utilisez une
expression régulière
correspondant
à tous
p
les clients pour
spécifier les options
normales à renvoyer
en fonction de l’ID
fournisseur.
Protocole TCP/IP
4-127
inoption
inoption number
option_data
Oui
inoption number
option_data range
4-128
Guide de gestion du système – Communications et réseaux
Aucune
Indique un conteneur
à rapprocher d’une
option entrante
arbitraire définie par le
client. number indique
le numéro de l’option.
option_data définit la
clé correspondant au
conteneur à
sélectionner lors du
choix de l’adresse et
de l’option pour ce
client. La clé
option_data se
présente sous forme
de chaîne entre
guillemets, d’adresse
IP ou de nombre
entier pour les options
connues mais peut
également se
présenter sous forme
de chaîne
hexadécimale d’octets
si elle est précédée
des caractères 0x.
Pour les options que
le serveur connaît
mal, il est possible de
définir une chaîne
hexadécimale d’octets
sur le même schéma.
En outre, la valeur
option_data peut faire
référence à une
expression régulière à
rapprocher de la
représentation en
chaîne des données
d’option du client. Ces
expressions
régulières se
présentent sous la
forme d’une chaîne
entre guillemets (dont
le premier caractère
est un point
d’exclamation ”!).
Les options peu
connues du serveur
se présentent sous
forme de chaîne
hexadécimale d’octets
NON précédée des
caractères 0x.
virtual
virtual fill id id ...
virtual sfill id id ...
virtual rotate id id ...
virtual srotate id id ...
Non
Aucune
Spécifie un
sous–réseau virtuel
avec une politique.
fill signifie utiliser
toutes les adresses
de ce conteneur avant
de passer au suivant.
rotate signifie
sélectionner une
adresse du pool
suivant de la liste sur
chaque requête.
sfill et srotate
sont identiques à
fill et rotate,
mais une recherche
est effectuée pour
savoir si le client
correspond aux
conteneurs, aux
fournisseurs ou aux
classes du
sous–réseau. Si une
correspondance
permet d’obtenir une
adresse, cette
adresse est adoptée à
partir du conteneur au
lieu de suivre la
politique indiquée. Il
peut y avoir autant
d’ID que nécessaire.
id est soit l’ID de
sous–réseau de la
définition de
sous–réseau, soit le
label de cette même
définition. Le label est
nécessaire si
plusieurs
sous–réseaux
partagent le même ID
de sous–réseau.
Protocole TCP/IP
4-129
inorder:
inorder: id id ...
Non
Aucune
Spécifie un
sous–réseau virtuel
avec une politique de
remplissage, ce qui
signifie utiliser toutes
les adresses de ce
conteneur avant de
passer au conteneur
suivant. Il peut y avoir
autant d’ID que
nécessaire. id est soit
l’ID de sous–réseau
de la définition de
sous–réseau, soit le
label de cette même
définition. Le label est
nécessaire si
plusieurs
sous–réseaux
partagent le même ID
de sous–réseau.
balance:
balance: id id ...
Non
Aucune
Spécifie un
sous–réseau virtuel
avec une politique de
rotation, ce qui signifie
utiliser l’adresse
suivante du conteneur
suivant. Il peut y avoir
autant d’ID que
nécessaire. id est soit
l’ID de sous–réseau
de la définition de
sous–réseau, soit le
label de cette même
définition. Le label est
nécessaire si
plusieurs
sous–réseaux
partagent le même ID
de sous–réseau.
support
Bootp
supportBootp true
Non
Oui
Indique si le
conteneur en cours et
tous ceux qui en
dé
découlent
l t (j
(jusqu’à
’à
mention contraire)
doivent accepter les
clients BOOTP
BOOTP.
supportBootp 1
supportBootp yes
supportBootp false
supportBootp 0
supportBootp no
4-130
Guide de gestion du système – Communications et réseaux
support
Unlisted
clients
supportUnlistedclients Non
BOTH
Both
supportUnlistedclients
DHCP
supportUnlistedclients
BOOTP
supportUnlistedclients
NONE
supportUnlistedclients
true
supportUnlistedclients
yes
supportUnlistedclients
1
supportUnlistedclients
false
supportUnlistedclients
no
supportUnlistedclients
0
address
recorddb
addressrecrddb path
Non
Aucune
Indique si le
conteneur en cours et
tous ceux qui en
découlent (jusqu’à
mention contraire)
doivent accepter les
clients non
répertoriés. La valeur
indique
q si tous les
clients bénéficient
d’un accès sans
instructions client
particulières, si seuls
les clients DHCP ont
un accès, si seuls les
clients
li
BOOTP sont
autorisés ou aucun
des deux.
Remarque : Les
valeurs true et false
ont été conservées
par souci de
compatibilité avec les
versions antérieures
mais sont
déconseillées. La
valeur true est
équivalente à BOTH
et la valeur false à
NONE.
Lorsqu’elle est
spécifiée, cette option
fonctionne comme le
mot–clé backupfile.
L’option n’est valide
qu’au niveau général
ou au niveau du
conteneur de base de
données.
Remarque : Cette
méthode est
déconseillée.
backup
file
backupfile path
Non
/etc/db_file.
crbk
Indique le fichier à
utiliser pour les
sauvegardes de la
base de données.
L’option n’est valide
qu’au niveau général
ou au niveau du
conteneur de base de
données.
Protocole TCP/IP
4-131
4-132
check
pointfile
checkpointfile path
Non
/etc/db_file.
crbk
Indique le fichier de
points de contrôle de
la base de données.
Le premier fichier de
points de contrôle
correspond à path. Le
second est path, avec
le dernier caractère
remplacé par un 2. Le
nom du fichier de
contrôle ne doit donc
pas se terminer à
l’origine par un 2.
Cette option n’est
valable qu’au niveau
général ou au niveau
du conteneur de base
de données.
client
recorddb
clientrecorddb path
Non
/etc/db_file.
crbk
Indique le fichier de
sauvegarde de la
base de données. Le
fichier contient tous
les enregistrements
client que le serveur
DHCP a traités.
L’option n’est valide
qu’au niveau général
ou au niveau du
conteneur de base de
données.
boot
strapserver
bootstrapserver IP
address
Non
Aucune
Indique le serveur que
les clients doivent
utiliser comme point
de départ vers les
fichiers TFTP à l’issue
de la réception de
paquets BOOTP ou
DHCP. Cette valeur
complète le champ
siaddr du paquet.
Cette option est valide
à tous les niveaux de
conteneur.
Guide de gestion du système – Communications et réseaux
giaddr
field
giaddrfield IP address
Non
Aucune
Définit le champ
giaddrfield pour les
paquets de réponse.
Remarque : Cette
spécification n’est
pas autorisée pour
les protocoles
BOOTP et DHCP,
mais certains clients
exigent le champ
giaddr comme
passerelle par défaut
pour le réseau. En
raison de ce risque
de conflit, il est
conseillé de n’utiliser
giaddrfield qu’au sein
d’un conteneur client,
bien que l’option
fonctionne à tous les
niveaux.
pingTime
pingTime n time_unit
Non
3 secondes
Indique la durée
pendant laquelle la
réponse ping doit être
attendue avant qu’une
adresse ne soit
suspendue. L’unité de
temps par défaut est
de l’ordre des
centièmes de
seconde. La valeur de
l’unité de temps est
définie dans la
remarque qui précède
ce tableau. Cette
option est valide à
tous les niveaux de
conteneur. Le
paramètre time_unit
est facultatif.
bootptime
bootptime n time_unit
Non
–1, illimité
Indique la durée
pendant laquelle louer
une adresse à un
client BOOTP. La
valeur par défaut est
–1, ce qui signifie
durée illimitée. Les
valeurs classiques
d’unités de temps
sont acceptées. Le
paramètre time unit
est facultatif. Cette
option est valide à
tous les niveaux de
conteneur.
Protocole TCP/IP
4-133
AllRoutesBro
adcast
allroutesbroadcast no
Non
0
Si un réponse de
diffusion est requise,
indique si cette
réponse doit être
diffusée sur toutes les
routes. Cette option
est valide à tous les
niveaux de conteneur.
Elle est ignorée
par
g
p
les serveurs DHCP du
système d’exploitation
car l’adresse MAC
réelle du client, y
compris les RIF, est
stockée pour le
paquet en retour.
Cette option est valide
à tous les niveaux de
conteneur.
allroutesbroadcast
false
allroutesbroadcast 0
allroutesbroadcast
yes
allroutesbroadcast
true
allroutesbroadcast 1
4-134
address
assigned
addressassigned
”string”
Non
Aucune
Indique une chaîne
entre guillemets à
exécuter lorsqu’une
adresse est attribuée
à un client. La chaîne
doit comporter deux
%s. Le premier %s
correspond à l’ID
client, sous la forme
type–string. Le second
%s est une adresse
IP en format de
”dotted quad”. Cette
option est valide à
tous les niveaux de
conteneur.
addressrelea
sed
addressreleased
”string”
Non
Aucune
Indique une chaîne
entre guillemets à
exécuter lorsqu’une
adresse est libérée
par un client. La
chaîne ne doit
comporter qu’un %s,
correspondant à
l’adresse IP libérée en
format de ”dotted
quad”. Cette option
est valide à tous les
niveaux de conteneur.
Guide de gestion du système – Communications et réseaux
appenddomai appenddomain 0
n
appenddomain no
Non
Non
Indique s’il convient
d’ajouter
d ajouter le nom de
domaine défini par
ll’option
option 15 au nom
d’hôte suggéré par le
client lorsque ce
dernier ne propose
pas de nom de
domaine. Cette option
est valide à tous les
niveaux de conteneur.
Non
0
Indique que l’ID du
client est en format
canonique. Cette
option n’est valide
qu’au
’ niveau
i
d
du
conteneur client.
Non
86400
secondes
Indique la durée du
bail par défaut pour
les clients. Cette
option est valide à
tous les niveaux de
conteneur. Le
paramètre time_unit
est facultatif.
appenddomain false
appenddomain 1
appenddomain yes
appenddomain true
canonical
canonical 0
canonical no
canonical false
canonical 1
canonical yes
canonical true
leaseTimeDef leaseTimeDefault n
ault
time_unit
Protocole TCP/IP
4-135
proxyarec
proxyarec never
Non
proxyarec
usedhcpddns
proxyarec
usedhcpddnsplus
proxyarec always
proxyarec
usedhcpddnsprotecte
d
proxyarec
usedhcpddnsplusprot
ected
proxyarec
alwaysprotected
proxyarec standard
proxyarec protected
4-136
releasednsA
releasednsA ”string”
Non
releasednsP
releasednsP ”string”
Non
Guide de gestion du système – Communications et réseaux
usedhcpddns Indique les options et
plus
méthodes qui doivent
être utilisées pour la
mise à jour des
enregistrements A
dans DNS. never
signifie
que
g
q
l’enregistrement A ne
doit jamais être
actualisé.
usedhcpddns
signifie
i ifi utiliser
tili
l’l’option
ti
81 si le client l’a
définie.
dh dd
l
usedhcpddnsplus
signifie utiliser l’option
81, ou les options 12
et 15, si spécifié.
always signifie que
l’enregistrement A doit
être actualisé pour
tous les clients.
XXXXprotected
modifie la commande
nsupdate pour
s’assurer que le client
est autorisé.
standard est
synonyme de
always. protected
est synonyme de
alwaysprotected.
Cette option est valide
à tous les niveaux de
conteneur.
Aucune
Indique la chaîne
d’exécution à utiliser
lors de la libération
d’une adresse. La
chaîne est utilisée
pour supprimer
l’enregistrement A
associé à l’adresse
libérée. Cette option
est valide à tous les
niveaux de conteneur.
Aucune
Indique la chaîne
d’exécution à utiliser
lors de la libération
d’une adresse. La
chaîne est utilisée
pour supprimer
l’enregistrement PTR
associé à l’adresse
libérée. Cette option
est valide à tous les
niveaux de conteneur.
removedns
removedns ”string”
Non
Aucune
Indique la chaîne
d’exécution à utiliser
lors de la libération
d’une adresse. La
chaîne est utilisée
pour supprimer les
enregistrements A et
PTR associés à
l’adresse libérée.
Cette option est valide
à tous les niveaux de
conteneur.
Remarque : Cette
option est
déconseillée au profit
des mots–clés
releasednsA et
releasednsP.
updatedns
updatedns
”string”
Non
Aucune
Indique la chaîne
d’exécution à utiliser
lors de la liaison d’une
adresse. La chaîne
est utilisée pour
mettre à jour les
enregistrements A et
PTR associés à
l’adresse. Cette option
est valide à tous les
niveaux de conteneur.
Remarque : Cette
option est
déconseillée au profit
des mots–clés
updatednsA et
updatednsP.
updatednsA
updatednsA ”string”
Non
Aucune
Indique la chaîne
d’exécution à utiliser
lors de la liaison d’une
adresse. La chaîne
est utilisée pour
mettre à jour
l’enregistrement A
associé à l’adresse.
Cette option est valide
à tous les niveaux de
conteneur.
Protocole TCP/IP
4-137
updatednsP
updatednsP ”string”
hostnamepoli hostnamepolicy
cy
suggested
Non
Aucune
Indique la chaîne
d’exécution à utiliser
lors de la liaison d’une
adresse. La chaîne
est utilisée pour
mettre à jour
l’enregistrement PTR
associé à l’adresse.
Cette option est valide
à tous les niveaux de
conteneur.
Non
par défaut
Spécifie le nom d’hôte
à retourner au client.
La politique par défaut
préfère le nom d’hôte
et le nom de domaine
explicitement définis
par rapport aux noms
suggérés. Les autres
politiques respectent
strictement les
consignes (par
exemple : defined
retourne le nom défini
ou rien si aucun nom
n’est défini dans la
configuration). En
outre, les politiques
utilisant le
modificateur always
d
d
demandent
au
serveur de toujours
retourner l’option nom
d’hôte même si le
client ne l’a pas
demandé au moyen
de l’option liste des
paramètres. A noter
que suggérer un nom
d’hôte implique
également de le
demander, et que les
d’hôte
noms d
hôte peuvent
être suggérés à l’aide
de l’option 81 ou des
options 12 et 15. Ce
mot–clé est valide à
tous les niveaux de
conteneur.
hostnamepolicy
resolved
hostnamepolicy
always_resolved
hostnamepolicy
defined
hostnamepolicy
always_defined
hostnamepolicy
default
4-138
Guide de gestion du système – Communications et réseaux
bootfilepolicy
bootfilepolicy
suggested
Non
suggested
Définit une préférence
pour retourner le nom
du fichier de
démarrage à un client.
suggested préfère le
nom du fichier de
démarrage suggéré
par le client à
n’importe quel autre
nom configuré par le
serveur. merge ajoute
le nom suggéré par le
client au répertoire
personnel configuré
par le serveur.
defined préfère le
nom défini à n’importe
quel autre nom
suggéré always
suggéré.
retourne le nom défini
même si le client ne
l’a pas demandé à
l’aide de l’option liste
des paramètres.
Non
Non
Indique si le
conteneur parent est
autorisé à “voler” des
adresses dans ses
conteneurs enfants
lorsqu’il est à court
d’adresses. Cela
signifie
que si vous
g
q
avez un sous–réseau
avec une classe
définie à l’aide d’une
p
g d’adresses, ces
plage
adresses
d
sont
réservées aux clients
qui mentionnent cette
classe. Si
stealfromchildre
l valeur
l
t
l
n a la
true,
les
adresses seront
récupérées chez un
enfant afin de tenter
de satisfaire la
requête. La valeur par
défaut n’autorise pas
les vols d’adresses.
bootfilepolicy merge
bootfilepolicy defined
bootfilepolicy always
stealfromchil
dren
stealfromchildren true
stealfromchildren 1
stealfromchildren yes
stealfromchildren
false
stealfromchildren 0
stealfromchildren no
Protocole TCP/IP
4-139
4-140
home
directory
homedirectory path
Non
Aucune
Indique le répertoire
personnel à utiliser
dans la section fichier
du paquet de
réponse. Cette option
peut être définie à
tous les niveaux de
conteneur. La
politique bootfile
définit comment les
éléments spécifiés
dans la section fichier
du paquet entrant se
conjuguent avec les
instructions du fichier
de démarrage et du
répertoire personnel.
bootfile
bootfile
path
Non
Aucune
Indique le fichier de
démarrage à utiliser
dans la section fichier
du paquet de
réponse. Cette option
peut être définie à
tous les niveaux de
conteneur. La
politique bootfile
définit comment les
éléments spécifiés
dans la section fichier
du paquet entrant se
conjuguent avec les
instructions du fichier
de démarrage et du
répertoire personnel.
Guide de gestion du système – Communications et réseaux
pxebootfile
pxebootfile
system_architecture
major_version
minor_version
boofilename
Non
Aucune
Indique le fichier de
démarrage à donner
pour un client. Il n’est
utilisé que lorsque
dhcpsd prend en
charge les clients PXE
(pxeservertype a la
valeur
dhcp_pxe_binld).
L’analyseur du fichier
de configuration
génère une erreur si
le nombre de
paramètres après
pxebootfile est
inférieur à quatre, et il
ignore les paramètres
supplémentaires.
pxebootfile ne
peut être utilisé que
dans un conteneur.
suppor
toption118
supportoption118 no /
yes
Non. Peut Aucune
être défini
unique–
ment
dans le
conteneur
du sous–
réseau.
Ce mot–clé indique si
ce conteneur prend
en charge l’option
118. Yes signifie
qu’elle est prise en
charge, No qu’elle ne
l’est pas. Pour que
cette option soit prise
en compte, vous
devez aussi utiliser le
mot–clé
supportsubnetselect
ion.
Protocole TCP/IP
4-141
DHCP et gestion NIM (Network Installation Management)
Le concept d’affectation dynamique d’adresses IP est relativement nouveau. Voici quelques
suggestions relatives à l’interaction entre DHCP et NIM.
1. Lorsque vous configurez des objets dans l’environnement NIM, utilisez des noms d’hôte
chaque fois que possible : vous pouvez ainsi exploiter un serveur de noms dynamique
qui met à jour les adresses IP lorsque le nom d’hôte est converti en adresse IP dans
l’environnement NIM.
2. Placez le maître NIM et le serveur DHCP sur le même système. Le serveur DHCP est
doté, dans la chaîne DNS de mise à jour, d’une option qui, affectée de la valeur NIM,
tente de conserver les objets NIM hors des états qui requièrent des adresses IP
statiques quand ces adresses changent.
3. Pour les clients NIM, définissez un délai dédié double du temps requis pour installer un
client. Cela permet à une adresse IP dédiée de rester valide pendant l’installation. Après
l’installation, redémarrez le client. Selon le type d’installation, DHCP devra être démarré
ou configuré.
4. Le serveur dhcpsd doit être responsable des enregistrements système DNS PTR et A.
Lorsque NIM réinstalle la machine, le fichier contenant le RSA est supprimé et le client
ne peut mettre ses enregistrements à jour. Le serveur met à jour les enregistrements
système. Pour ce faire, modifiez la ligne updatedns du fichier /etc/dhcpcd.ini :
updatedns ”/usr/sbin/dhcpaction ’%s’ ’%s’ ’%s’ ’%s’ ’%s’ NONE NONIM”
Dans le fichier /etc/dhcpsd.cnf, changez la ligne updatedns en :
updatedns ”/usr/sbin/dhcpaction ’%s’ ’%s’ ’%s’ ’%s’ ’%s’ BOTH NIM”
Remarque :
Lorsqu’un objet NIM est placé en état d’attente de l’installation BOS,
le serveur dhcpsd peut transmettre des arguments différents de ceux
prévus à l’origine. Réduisez le temps pendant lequel le client est placé
en état d’attente pour éviter cette situation.
Ces suggestions permettent aux clients dynamiques d’exploiter l’environnement NIM.
Pour plus d’informations sur la gestion NIM (Network Installation Management),
reportez–vous au manuel AIX 5L Version 5.3 Network Installation Management Guide and
Reference.
4-142
Guide de gestion du système – Communications et réseaux
Dynamic Host Configuration Protocol version 6 (DHCPv6)
Le Dynamic Host Configuration Protocol (DHCP) fournit une méthode permettant de gérer
les configurations réseau dans un emplacement centralisé. Cet article est spécifique au
DHCPv6 ; toutes les références à des ”adresses IP” renvoient à des adresses IPv6 et toutes
les références au ”DHCP” renvoient au DHCPv6 (sauf indication contraire).Le serveur 6 A
DHCPv4 peut cohabiter sur la même liaison qu’un serveur DHCPv6. Pour une explication
approfondie du protocole, reportez–vous à la RFC 3315.
Le DHCP est un protocole de couche application qui permet à une machine cliente du
réseau d’obtenir du serveur des adresses IP ainsi que d’autres paramètres de configuration.
Ces paramètres sont définis dans options. Les options sont obtenues en échangeant des
paquets entre un démon du client et celui du serveur. Ces échanges de messages se
présentent sous la forme de paquets UDP. Un client utilise une adresse locale via la
commande autoconf6 ou via d’autres méthodes pour identifier son adresse source auprès
du serveur. Le serveur écoute sous une adresse multidiffusion réservée dans le cadre du
lien. Un agent relais permet la communication entre le client et le serveur s’ils ne sont pas
situés sur la même liaison.
Cet article explique la procédure d’échange à quatre messages pour une interface unique
avec un IA_NA ainsi qu’une adresse pour ce IA_NA. Pour obtenir une adresse IP, le démon
client DHCP (dhcpcd6) envoie un message SOLICIT à l’adresse
All_DHCP_Relay_Agents_and_Servers que le serveur reçoit puis traite. (Il est possible de
configurer à cet effet plusieurs serveurs sur le réseau.) Si une adresse libre est disponible
pour ce client, un message ADVERTISE est créé et renvoyé au client. Ce message contient
une adresse IP ainsi que d’autres options adéquates pour ce client. Le client reçoit le
message serveur DHCP ADVERTISE et le stocke en attendant d’autres annonces. Lorsque
le client a choisi la meilleure annonce, il envoie un message DHCP REQUEST à l’adresse
All_DHCP_Relay_Agents_and_Servers en indiquant l’annonce de serveur souhaitée.
Tous les serveurs DHCP configurés reçoivent le message REQUEST. Chacun d’eux vérifie
qu’il n’est pas le serveur demandé. Le serveur ne traite aucun paquet avec un serveur
DUID ne correspondant pas au sien. Le serveur demandé signale que l’adresse est affectée
et renvoie un message DHCP REPLY au moment où la transaction est complète. Le client a
une adresse pour la durée ( durée de vie valide) désignée par le serveur.
Lorsque la durée de vie favorite de l’adresse expire, le client envoie au serveur un paquet
avec le message RENEW afin de prolonger le bail. Si le serveur est disposé à renouveler
l’adresse, il envoie un DHCP REPLY. Si le client n’obtient pas de réponse de la part du
serveur hébergeant son adresse actuelle, il multidiffuse un paquet comportant le message
DHCP REBIND, si le serveur a par exemple changé de réseau. Si, à l’expiration de la durée
de vie valide, le client n’a pas renouvelé son adresse, l’adresse est supprimée de l’interface
et le processus recommence. Ce cycle permet d’éviter que plusieurs clients d’un réseau ne
se voient affecter la même adresse.
Un client dispose de plusieurs options IA_NA et chaque IA_NA peut avoir plusieurs
adresses. Un client dispose également de plusieurs options IA_TA et chaque IA_TA peut
aussi avoir plusieurs adresses :
• Association d’identité (IA) pour adresses non temporaires (IA_NA) : Une IA gère
des adresses affectées qui ne sont pas des adresses temporaires
• Association d’identité (IA) pour adresses temporaires (IA_TA): Une IA gère des
adresses temporaires (reportez–vous à la RFC 3041).
• DUID : Un identificateur DHCP unique pour un participant DHCP ; chaque client et
serveur DHCP possède un DUID unique ne changeant pas au fil des redémarrages.
Le serveur DHCP procède à l’attribution des adresses en fonction de clés. Les quatre clés
communes sont classe, fournisseur, ID client et en option. Le serveur utilise ces clés
pour attribuer une adresse et l’ensemble des options de configuration pour effectuer un
retour client.
Protocole TCP/IP
4-143
classe
La clé de classe peut être complètement configurée par le client. Elle peut
comprendre une adresse et des options. Cette clé peut être utilisée pour
préciser la fonction d’une machine du réseau ou pour décrire le mode de
regroupement des machines adopté à des fins administratives. Par
exemple, l’administrateur du réseau peut vouloir créer une classe NetBIOS
contenant des options pour des clients NetBIOS ou une classe comptabilité
représentant les machines du service comptabilité qui ont besoin d’accéder
à une imprimante spécifique.
fournisseur
La clé fournisseur permet d’identifier le client par sa plate–forme matérielle
et logicielle.
ID client
La clé ID client identifie le client via le DUID. L’ID client est indiqué dans le
fichier duid du démon dhcpcd. Par ailleurs, il peut être utilisé par le
serveur pour transmettre des options à un client ou pour empêcher un client
de recevoir des paramètres.
En option
La clé en option identifie le client par l’opération qu’il demande.
Ces clés peuvent êtres utilisées seules ou combinées. Si un client fournit plusieurs clés et
que plusieurs adresses peuvent être allouées, le choix porte sur une clé et le jeu d’options
découle de la clé choisie en premier.
Un agent relais est requis pour que les multidiffusions initiales du client puissent quitter le
réseau local. Ces agents relais assurent l’acheminement des paquets DHCP.
Le serveur DHCPv6
Le serveur DHCP a été segmenté en trois composantes principales : une base de données,
un moteur de protocole et un ensemble de routines de service. Chaque composant possède
ses propres informations de configuration.
La base de données DHCPv6
La base de données db_filev6.dhcpo est utilisée pour suivre les clients et les adresses
ainsi que pour contrôler les accès. Les options sont également enregistrées dans la base
de données d’où elles peuvent être extraites et distribuées aux clients. La base de données
est implémentée en tant qu’objet pouvant être chargé dynamiquement.
A partir des informations du fichier de configuration, la base de données est amorcée et sa
cohérence est vérifiée. La base de données contient également les pools d’adresses et
d’options
Le fichier de stockage principal et sa sauvegarde sont des fichiers ASCII.
Le format des fichiers de stockage principaux de la base de données est le suivant :
Remarque :
4-144
Ne modifiez pas ces fichiers manuellement.
Guide de gestion du système – Communications et réseaux
DB6–1.0
Info client {
duid 1–0006085b68e20004ace491d3
état 7
Interface 0 {
en options {
id interface ”en1”
règles 2
maxopcode 16
numiana 1
Ianalist {
option 3 40
00000001000000320000005000050018deaddeadaaaaaaaa000000000000000600000064000
000c8
}
numiata 0
Table d’options {
option 6 10 00030004001700180237
option 8 2 e659
option 15 14 000369626d000373756e00026870
option 16 18 000004d2000730783131313131000369626d
}
}
Ianarec {
ID IA 1
t1 50
t2 80
Addrec {
Adresse dead:dead:aaaa:aaaa::6
état 3
heure de lancement 1087592918
durée de vie favorite 100
durée de vie valide 200
}
}
}
}
La première ligne indique la version du fichier : DB6–1.0. Les lignes qui suivent définissent
des enregistrements client. Le serveur procède à la lecture de la seconde ligne jusqu’à la fin
du fichier. (Les paramètres entre guillemets doivent être indiqués entre guillemets.)
duid
Il s’agit de l’ID utilisé par le client pour se présenter au serveur.
Interface
Un client peut avoir plusieurs interfaces. Si un client ayant une seule
interface crée des messages SOLICIT individuels pour chaque IA_NA
ou IA_TA, le fichier contient plusieurs interfaces pour ce client.
En option
Les options entrantes du client
règles
Indicateur permettant la diffusion individuelle, l’option de reconfiguration
et la validation rapide
maxopcode
Le code d’option le plus important
numiana
Nombre d’ IA_NA de cette interface
Ianalist
La liste des options IA_NA entrantes du client
numiana
Nombre d’ IA_NA de cette interface
Table d’options La liste des options demandées par le client à l’exception des options
IA_NA et IA_TA
Ianarec
Le conteneur d’enregistrements IA_NA sauvegardé de la base de données
du serveur
IAID
L’ID du IA_NA
t1
Le pourcentage de durée de vie favorite de ce IA_NA
t2
Le pourcentage de durée de vie valide de ce IA_NA
Protocole TCP/IP
4-145
Addrec
Le conteneur d’enregistrements d’adresses de la base de données du
serveur
Adresse
Adresse donnée au client pour l’enregistrement de cette adresse
état
L’état actuel du client. Le moteur de protocole DHCP contient le jeu de
valeurs attribuables et les états sont gérés dans la base de données DHCP.
Le nombre en regard de state représente sa valeur. Les différents états
possibles sont :
(1) FREE
Représente les adresses qui sont disponibles. En principe, les clients
n’ont pas cet état sauf s’ils n’ont pas d’adresse attribuée. Les
commandes dadmin et lssrc indiquent que cet état est Free.
(2) BOUND
indique que le client et l’adresse sont liés et que l’adresse a été
attribuée au client il y a déjà un certain temps. dadmin et les
commandes lssrc indiquent pour cet état Leased.
(3) EXPIRED
Indique que le client et l’adresse sont liés, à titre d’information
uniquement, de la même manière que l’état released. Cet état
signale toutefois que le client a laissé son bail arriver à expiration.
Une adresse arrivée à expiration est disponible et est réaffectée
lorsque toutes les adresses libres sont indisponibles et avant que les
adresses libérées ne soient réattribuées. dadmin et le programme
de commandes lssrc indiquent que cet état est Expired.
(4) RELEASED Indique que le client et l’adresse sont liés, à titre d’information
uniquement. Le protocole DHCP conseille aux serveurs DHCP de
gérer les informations concernant leurs clients précédents à des fins
de référence ultérieure (principalement pour essayer de redonner à
un client une adresse qu’il a déjà utilisée dans le passé). Cet état
signale que le client a libéré l’adresse. Cette adresse peut donc être
utilisée par d’autres clients si aucune autre adresse n’est disponible.
dadmin et le programme de commandes Issrc indiquent que cet état
est Released.
(5) RESERVED
Indique qu’une liaison lâche existe entre le client et l’adresse.
Le client a envoyé un message de découverte DHCP, auquel le
serveur DHCP a répondu, et le client n’a pas encore répondu par une
requête DHCP demandant cette adresse. dadmin et les commandes
lssrc indiquent cet état comme Reserved.
(6) BAD
Représente une adresse utilisée sur le réseau mais qui n’a pas été
distribuée par le serveur DHCP. Cet état qualifie également les
adresses qui ont été rejetées par les clients. Cet état ne s’applique
pas aux clients. Le dadmin indique que cet état est Used, les
commandes lssrc indiquent que cet état est Bad.
Heure de lancement
L’heure à laquelle cette adresse a été distribuée est représentée en
secondes depuis le 1er janvier 2000
durée de vie favorite
Nombre de secondes avant le renouvellement nécessaire de cette adresse
durée de vie favorite
Nombre de secondes avant que cette adresse devienne non valide et
inutilisable
4-146
Guide de gestion du système – Communications et réseaux
La syntaxe des fichiers de points de contrôle n’est pas spécifiée. En cas de panne du
serveur ou si vous devez l’arrêter sans avoir pu fermer normalement la base de données,
le serveur peut utiliser les fichiers de points de contrôle et les fichiers de sauvegarde pour
reconstruire une base de données correcte. Un client n’étant pas inscrit dans le fichier des
points de contrôle est perdu en cas de panne du serveur. Actuellement, aucune sauvegarde
intermittente n’est effectuée lors du traitement d’un client. Les fichiers par défaut sont :
/etc/dhcpv6/db_file6.cr
Fonctionnement normal de la base de données
/etc/dhcpv6/db_file6.crbk
Cartes de secours pour la base de données
Opérations DHCP enchaînées
Le dernier élément du serveur DHCP est en fait un ensemble d’opérations qui permettent
d’assurer la continuité des opérations. Comme le serveur DHCP est du type enchaîné, ces
opérations sont en fait définies sous la forme de routines qui interviennent
occasionnellement pour s’assurer du bon déroulement des opérations.
routine principale
Cette routine gère les signaux. Par exemple :
• A SIGHUP (–1) entraîne un rafraîchissement de toutes les bases de données du fichier
de configuration.
• A SIGTERM (–15) entraîne l’arrêt en douceur du serveur.
• A SIGUSR1 (–30) entraîne le vidage de la base de données de la configuration
du serveur
routine src
Cette routine gère les requêtes SRC (telles que startsrc, stopsrc, lssrc, traceson,
et refresh).
routine dadmin
Cette routine sert d’interface au programme client dadmin et au serveur DHCP. L’outil
dadmin peut être utilisé pour obtenir des informations sur l’état de la base de données et la
modifier, évitant ainsi d’avoir à modifier manuellement les différents fichiers de la base de
données. Grâce aux routines dadmin et src, le serveur est désormais en mesure de gérer
les requêtes de services tout en continuant à traiter les requêtes des clients.
routine de nettoyage
Cette routine exécute les horloges déclenchant le nettoyage périodique de la base de
données, la sauvegarde de la base de données, l’effacement des clients n’ayant pas
d’adresse et la suppression d’adresses réservées restées trop longtemps à l’état réserve.
Toutes ces horloges peuvent être configurées.
processeurs de paquets
Chacun d’entre eux peut gérer la demande d’un client DHCPv6. Le nombre de processeurs
de paquets requis dépend de la charge et de la machine. Le nombre de processeurs de
paquets peut être configuré ; la valeur par défaut est 1. Le nombre maximal de routines de
paquets est 50.
routines de journalisation
Dans un système où une quantité de données significative a été consignée dans des
fichiers journaux, le nombre de routines de journalisation peut dépasser la valeur par défaut
(1) pour atteindre la valeur maximale (50).
routine de gestion des tables
Cette routine empêche le démon dhcpsdv6 de traiter des paquets en double.
Protocole TCP/IP
4-147
routines de traitement
Ces routines traitent les paquets de clients DHCPv6 définis dans la RFC 3315.
Configuration du serveur DHCP
Par défaut, la configuration du serveur DHCP est effectuée par la lecture du fichier
/etc/dhcpv6/dhcpsdv6.cnf, qui indique la base de données initiale d’adresses et d’options.
Le serveur est lancé depuis les commandes SRC. Si dhcpsdv6 est sur le point d’être lancé
via des redémarrages, effectuez l’ajout et l’entrée dans le fichier /etc/rc.tcpip.
La configuration du serveur DHCP constitue la tâche la plus délicate dans le cadre de
l’utilisation de DHCP dans votre réseau. Vous devez d’abord déterminer les réseaux qui
devront accueillir des clients DHCP. Chaque sous–réseau du réseau principal représente un
pool d’adresses que le serveur DHCP doit ajouter à sa base de données. Par exemple :
subnet dead:dead:aaaa:: 48 {
option 23 dead::beef beef:aaaa::bbbb:c aaaa:bbbb::cccc
#nameserver list
option 24 austin.ibm.com ibm.com
list
}
# domain
L’exemple ci–dessus montre un sous–réseau dead:dead:aaaa:: ayant un préfixe de
48 bits. Toutes les adresses de ce sous–réseau, dead:dead:aaaa::1 à
dead:dead:aaaa:ffff:ffff:ffff:ffff:ff7f, sont dans le pool. Eventuellement,
il est possible de spécifier un intervalle à la fin de la ligne avant le ’{’, ou d’inclure un
intervalle ou une instruction d’exclusion dans le conteneur de sous–réseau.
Les commentaires sont introduits par le symbole #. Le texte placé entre le # initial et la fin
de la ligne est ignoré par le serveur DHCP. Le serveur utilise chaque ligne option pour
indiquer au client ce qu’il doit faire.
Si le serveur ne comprend pas comment analyser une option, il utilise des méthodes par
défaut pour transmettre l’option au client. Ceci permet au serveur DHCP d’envoyer des
options spécifiques à certains sites, elles ne sont pas définies dans les normes RFC,
mais sont utilisables par certains clients ou certaines configurations de client.
Le fichier de configuration
Le fichier de configuration a une section d’adresse et une section de définition d’option.
Ces sections utilisent des conteneurs pour conserver des options, des modificateurs et,
potentiellement, d’autres conteneurs.
Un conteneur (qui est une méthode de regroupement des options) fait appel à un
identificateur pour classer les clients en plusieurs groupes. Les types de conteneurs sont
les suivants : sous–réseau, classe, fournisseur, en option et client. A l’heure actuelle, il
n’existe pas de conteneur générique définissable par l’utilisateur. L’Identificateur définit le
client de manière unique, de sorte qu’il soit possible de suivre sa trace même s’il est
déplacé vers un autre sous–réseau. Il est possible d’utiliser plusieurs types de conteneur
pour définir les droits d’accès du client.
Les options sont des identificateurs retournés au client tels qu’une adresse DNS ou des
noms de domaine.
Conteneurs
Lorsque le serveur DHCP reçoit une demande, le paquet est analysé et les clés
d’identification permettent de déterminer les conteneurs, les options et les adresses à
extraire.
Chaque type de conteneur utilise une option différente pour identifier les clients :
• Le conteneur sous–réseau utilise le champ hintlist ou l’adresse de l’interface réceptrice
pour déterminer le sous–réseau d’origine du client.
• Le conteneur classe utilise la valeur en option 15 (Identificateur
OPTION_USER_CLASS).
4-148
Guide de gestion du système – Communications et réseaux
• Le fournisseur utilise la valeur en option 16 (OPTION_VENDOR_CLASS).
• Le conteneur client utilise l’option 1 (OPTION_CLIENTID) depuis le DUID du client
DHCP.
• Le conteneur en option correspond à l’option demandée par le client.
Excepté pour les sous–réseaux, chaque conteneur accepte la spécification de la valeur
lui correspondant, y compris la mise en concordance d’expressions régulières.
A ces conteneurs, il faut ajouter un conteneur implicite, le conteneur global. Sauf
spécification contraire ou refus explicite, les options et modificateurs sont placés dans le
conteneur global. La plupart des conteneurs peuvent être inclus dans d’autres conteneurs,
ce qui implique une certaine visibilité. Les conteneurs peuvent ou non être associés à des
plages d’adresses. Tel est le cas, par nature, des sous–réseaux.
Les règles de base s’appliquant aux conteneurs et sous–conteneurs sont les suivantes :
• Seuls les conteneurs de sous–réseau sont valides au niveau général.
• Les sous–réseaux ne doivent pas être inclus dans d’autres conteneurs, eux y compris.
• Des conteneurs restreints ne peuvent pas englober des conteneurs réguliers du même
type. (Par exemple, un conteneur doté d’une option autorisant uniquement la classe
Comptabilité ne peut receler un conteneur doté d’une option autorisant toutes les
classes commençant par la lettre a.)
• Les conteneurs client restreints ne peuvent englober de sous–conteneurs.
• Les conteneurs en option ne peuvent pas englober de sous–conteneurs
En tenant compte des règles ci–dessus, vous pouvez générer une hiérarchie de conteneurs
qui répartissent les options en différents groupes pour des clients ou des ensembles de
clients spécifiques.
Si un client correspond à plusieurs conteneurs, le serveur DHCP transmet la demande à la
base de données et une liste de conteneurs est générée. La liste est organisée par ordre de
profondeur et de priorité. La priorité se définit comme une hiérarchie implicite au sein des
conteneurs. Les conteneurs stricts ont une priorité supérieure à celle des conteneurs
réguliers. Les clients, les classes, les fournisseurs et les sous–réseaux sont triés, dans cet
ordre, et à l’intérieur de chaque conteneur, en fonction de leur profondeur. Ceci aboutit à
une liste allant du plus spécifique au moins spécifique. Par exemple :
Sous–réseau 1
––Classe 1
––Client 1
Sous–réseau 2
––Classe 1
––––Fournisseur 1
––––Client 1
––Client 1
Cet exemple présente deux sous–réseaux, Sous–réseau 1 et Sous–réseau 2. Il existe
un nom de classe, Classe 1, un nom de fournisseur, Fournisseur 1 et un nom de
client, Client 1. Classe 1 et Client 1 sont définis en plusieurs endroits. Comme ils
résident dans des conteneurs différents, leurs noms peuvent être identiques mais leurs
valeurs, différentes. Si Client 1 envoie un message au serveur DHCP depuis
Sous–réseau 1 avec Classe 1 spécifiée dans sa liste d’options, le serveur DHCP va
générer le chemin de conteneur suivant :
Sous–réseau 1, Classe 1, Client 1
Protocole TCP/IP
4-149
Le conteneur le plus spécifique apparaît en dernier. Pour obtenir une adresse, la liste est
étudiée dans l’ordre inverse de la hiérarchie et la première adresse disponible est retenue.
Ensuite, l’étude de la liste de poursuit en remontant dans la hiérarchie afin d’obtenir les
options. Les options peuvent remplacer des valeurs précédentes, sauf si une option Refus
a été incluse dans le conteneur. Par ailleurs, puisque Classe 1 et Client 1 figurent dans
Sous–réseau 1, ils sont ordonnés en fonction de la priorité de leur conteneur. Si le même
client se trouve dans Sous–réseau 2 et envoie le même message, la liste de conteneur
générée sera :
Sous–réseau 2, classe 1, client 1 (au niveau du sous–réseau 2), client 1
(au niveau de la classe 1)
Sous–réseau 2 apparaît en premier, suivi de Classe 1, puis de Client 1 au niveau
de Sous–réseau 2 (car cette instruction client ne se trouve qu’à un niveau en dessous
dans la hiérarchie). Cette hiérarchie implique qu’un client correspondant à la première
instruction client est moins spécifique que le client correspondant à Client 1
de Classe 1 au sein de Sous–réseau 2.
La priorité sélectionnée en fonction de la profondeur dans la hiérarchie prend le pas sur la
priorité des conteneurs eux–mêmes. Par exemple, si le même client émet le même
message, en précisant cette fois un identificateur de fournisseur, la liste de conteneur
devient :
Sous–réseau 2, classe 1, fournisseur 1 (au niveau du sous–réseau 2),
client 1 (au niveau de la classe 1)
La priorité au niveau des conteneurs améliore les performances en matière de recherche
car elle correspond à un concept général selon lequel les conteneurs client constituent le
moyen le plus spécifique de définir un ou plusieurs clients. Le conteneur client contient des
adresses plus spécifiques qu’un conteneur classe, lui–même plus spécifique qu’un
conteneur fournisseur, le conteneur sous–réseau étant le moins spécifique de tous.
Adresses et plages d’adresses
Les plages d’adresses, obligatoires pour les conteneurs sous–réseau, peuvent être
associées à tout type de conteneur. Chaque plage définie pour un conteneur doit être un
sous–ensemble de la plage et ne doit pas chevaucher les plages d’autres conteneurs. Par
exemple, si une classe définie dans un sous–réseau est associée à une plage d’adresses,
cette plage doit constituer un sous–ensemble des adresses de la plage du sous–réseau.
En outre, le conteneur de la classe ne doit pas recouvrir, même partiellement, d’autres
plages d’adresses au même niveau.
Les plages peuvent être définies sur la ligne du conteneur et modifiées au moyen
d’instructions de plages et d’exclusion afin que des jeux d’adresse non contigus puissent
être associés à un conteneur. Si les dix premières adresses d’un sous–réseau sont
disponibles, ainsi que les dix suivantes, le sous–réseau peut spécifier ces adresses par
plage dans la clause de sous–réseau afin de réduire l’utilisation de la mémoire et les
risques de collision d’adresses avec d’autres clients ne se trouvant pas dans les plages
spécifiées.
Dès qu’une adresse est sélectionnée, tout conteneur suivant dans la liste contenant les
plages d’adresses est retiré de la liste, avec ses enfants. Les options spécifiques au réseau
dans les conteneurs supprimés ne sont pas valides si l’adresse n’est pas utilisée à partir de
ce conteneur.
Options
Une fois la liste ponctionnée pour déterminer les adresses, un ensemble d’options est
généré pour le client. Lors de ce processus de sélection, les nouvelles options remplacent
les options précédemment sélectionnées, sauf si une clause Refus est rencontrée, auquel
cas l’option refusée est retirée de la liste envoyée au client. Cette méthode autorise les
héritages à partir des conteneurs parents afin de réduire la quantité de données à spécifier.
4-150
Guide de gestion du système – Communications et réseaux
Une fois les modificateurs sélectionnés, configurez la fonction de journalisation. Les
paramètres de journalisation sont précisés dans un conteneur tel que la base de données,
mais le mot de passe du conteneur est : logging_info. Pour apprendre à configurer DHCP,
il est conseillé d’activer le niveau de journalisation le plus élevé. En outre, il est préférable
de configurer cette fonction avant toute autre afin que les erreurs de configuration puissent
être consignées après initialisation du sous–système de journalisation. Le mot–clé logitem
active le niveau de journalisation ; si vous supprimez logitem, le niveau de journalisation
sera désactivé. Les autres mots–clé concernant la journalisation permettent d’indiquer le
nom du fichier journal, sa taille et le nombre de journaux utilisés en alternance.
Options spécifiques au serveur
Le dernier groupe de paramètres concerne les options spécifiques au serveur permettant à
l’utilisateur de contrôler le nombre de processeurs de paquets, la fréquence d’exécution des
routines de nettoyage, et ainsi de suite.
Voici deux exemples d’options spécifiques au serveur :
reservedTime
Indique pendant combien de temps une adresse reste à l’état réservé après
l’envoi d’une ANNONCE au client DHCP
reservedTimeInterval
Indique la fréquence à laquelle le serveur DHCP analyse les adresses pour
vérifier si certaines ne sont pas à l’état réservé depuis une durée
supérieure à celle définie par reservedTime.
Ces options sont pratiques si vous avez plusieurs clients qui multidiffusent des messages
SOLICIT, mais qui ne multidiffusent pas de message REQUEST ou que leur message
REQUEST se perd sur le réseau. Ces paramètres permettent d’éviter la réservation
indéfinie des adresses pour un client non conforme.
Une autre option particulièrement importante, SaveInterval, permet de définir la fréquence
de sauvegarde.
Fichier /etc/dhcpv6/dhcpsdv6.cnf
Cette section présente la configuration du serveur DHCPv6. Le serveur est configuré en
éditant le fichier /etc/dhcpv6/dhcpsdv6.cnf. Les mots–clés sont sensibles à la casse.
Lorsqu’un ’{’ est répertorié, il doit se trouver à la même ligne que le mot–clé. Vous pouvez
trouver un fichier d’exemple de configuration sous /usr/samples/tcpip/dhcpv6.
La description du fichier /etc/dhcpv6/dhcpsdv6.cnf est la suivante.
Les strophes suivantes sont autorisées dans ce fichier :
•
Journalisation, page 4-151
•
Mots–clés généraux, page 4-152
•
Instructions de conteneur non imbriquées, page 4-155
•
Instructions de conteneur imbriquées, page 4-155
•
Options, page 4-156
•
Options courantes, page 4-157
Journalisation
Cette strophe ne doit pas obligatoirement exister mais si c’est le cas,
elle doit figurer en tête du fichier de configuration. Elle a le format suivant :
logging_info {
log_options
}
Les valeurs log_options peuvent être les suivantes :
Protocole TCP/IP
4-151
Tableau 3. Mots–clés, valeurs et descriptions pour des entrées dans la strophe de
journalisation.
Mot–clé
Valeur
Description
logFileSize
num
Indique la taille du fichier journal. La valeur
num correspond à la taille maximale du fichier
journal en kilo–octets. Le fichier journal est
permuté une fois que cette taille est atteinte.
Une taille infinie est supposée si
logFileSize n’est pas renseignée.
logFileName
” nom du
fichier ”
Indique le nom du fichier journal. La valeur
nom du fichier correspond au nom du
fichier journal. Le nom et l’emplacement du
fichier par défaut est /var/tmp/dhcpsdv6.log
numLogFiles
num
Indique le nombre de fichiers journaux pour la
permutation des fichiers. La valeur par défaut
est 0.
logItem
type
Indique les types de journalisation désirés.
Les types suivants sont valides :
ERR_SYS
Erreur système au niveau de l’interface
menant à la plate–forme.
ERR_OBJ
Erreur d’objet entre des objets du
processus.
ERR_PROT
Erreur de protocole entre le client et le
serveur.
AVERTISSEMENT
Avertissement méritant l’attention de
l’utilisateur.
EVENEMENT
Evénement survenu dans le cadre du
processus.
ACTION
Action entreprise dans le cadre du
processus.
INFO
Information pouvant être utile.
COMPTA
Qui a été servi et quand.
TRACE
Flux de code pour le débogage.
Mots–clés généraux
Les mots–clés généraux sont valides uniquement hors conteneur.
Les valeurs suivantes sont autorisées :
4-152
Guide de gestion du système – Communications et réseaux
Tableau 4. Mots–clés, valeurs et descriptions pour des entrées dans la strophe de
mots–clés.
Mot–clé
Valeur
Description
UsedIpAddressExpired num [ unités ] Indique la fréquence à laquelle les
Interval
adresses présentant l’état BAD sont
recoupées et testées afin de vérifier
leur validité. Si une unité n’est pas
définie, la valeur par défaut du système
est définie en secondes. La valeur par
défaut est –1.
leaseExpiredInterval num [ unités ] Indique la fréquence à laquelle les
adresses présentant l’état BOUND sont
vérifiées pour voir si elles sont arrivées
à expiration. Si l’adresse est arrivée à
expiration, l’état devient EXPIRED. Si
une unité n’est pas définie, la valeur par
défaut du système est définie en
secondes. La valeur par défaut est 900
secondes.
reservedTime
num [ unités ] Indique pendant combien de temps les
adresses peuvent rester à l’état
RESERVED avant de reprendre l’état
FREE. Si une unité n’est pas définie, la
valeur par défaut du système est
définie en secondes. La valeur par
défaut est –1.
reservedTime
num [ unités ] Indique la fréquence à laquelle les
adresses présentant l’état RESERVE
sont vérifiées pour voir si elles peuvent
reprendre l’état FREE. Si une unité n’est
pas définie, la valeur par défaut du
système est définie en secondes. La
valeur par défaut est 900 secondes.
saveInterval
num [ unités ] Indique à quelle fréquence le serveur
DHCP doit déclencher une sauvegarde
des bases de données ouvertes. Pour
les serveurs très chargés, cette valeur
doit tourner autour de 60 ou 120
secondes. Si une unité n’est pas
définie, la valeur par défaut du système
est définie en secondes. La valeur par
défaut est 3600 secondes.
clientpruneintv
num [ unités ] Indique la fréquence à laquelle le
serveur DHCP supprime des bases de
données les clients non associés à une
adresse (état UNKNOWN ). Ceci permet
d’économiser la mémoire du serveur
DHCP. Si une unité n’est pas définie, la
valeur par défaut du système est
définie en secondes. La valeur par
défaut est 3600 secondes.
Protocole TCP/IP
4-153
numprocessthreads
num
Indique le nombre de routines de
processeurs de paquets à créer. Le
minimum est de un. Chaque routine de
processus gère un client. La valeur par
défaut est 30.
numpacketthreads
num
Indique le nombre de routines de
paquets à créer. 1 est la valeur
minimale mais elle est définie à 5 par
défaut.
numloggingthreads
num
Indique le nombre de routines de
journalisation. La valeur par défaut est
1.
numduidbuckets
num
Ceci est utilisé pour le gestionnaire de
tables et est en corrélation directe avec
les numprocessthreads. La valeur est
définie à 53 par défaut.
numclientbuckets
num
Nombre de compartiments à utiliser
pour stocker les enregistrements client.
La valeur par défaut est 1021.
ignoreinterfacelist
interface [
interface ]
Liste d’interfaces à ignorer. Il peut s’agir
d’une ou de plusieurs interfaces.
backupfile
”nom de
fichier”
Le fichier à utiliser pour les
sauvegardes de la base de données.
Le fichier par défaut est
/etc/dhcpv6/db_file6.crbk
checkpointfile
”nom de
fichier”
Indique le fichier de points de contrôle
de la base de données. Le premier
fichier des points de contrôle est le
chemin d’accès. Le second fichier des
points de contrôle est le chemin
d’accès avec un 2 en guise de dernier
caractère. Le fichier des points de
contrôle ne doit donc pas se terminer
par 2.
clientrecorddb
”nom de
fichier”
Indique le fichier de sauvegarde de la
base de données. Le fichier contient
tous les enregistrements client que le
serveur DHCP a traités. Le fichier par
défaut est /etc/dhcpv6/db_file6.cr
duid
idtype value
[valeur]
Utilisée pour l’identification du serveur.
Les valeurs suivantes sont autorisées :
• duid 1 interface
• duid 2 interface
• duid 3 enterprise number
identifier
• duid number 0x hexdigit
preference–number
4-154
num
Guide de gestion du système – Communications et réseaux
Permet aux clients d’identifier le
serveur dont il préfère obtenir les
informations. Plus la valeur est élevée,
plus les chances de voir le client utiliser
les services de ce serveur sont
élevées. La valeur par défaut maximale
est 255.
activation de la
diffusion
individuelle
policy
La règle de diffusion individuelle pour le
serveur permet au serveur de
communiquer en utilisant la diffusion
individuelle. Elle est activée par défaut.
tablemgr–policy
police
Permet au serveur d’avoir un
gestionnaire de tables pour améliorer la
gestion des clients entrants. Il est activé
par défaut.
Instructions de conteneur non imbriqué
Des instructions de conteneur non imbriqué peuvent uniquement exister en tant que partie
de mots–clés généraux.
Tableau 5. Mots–clés, valeurs et descriptions pour des entrées dans les instructions de
conteneur non imbriqué.
subnetid
prefix–le
ngth [
range ]
{OPTIONS}
subnet
Spécifie le sous–réseau à utiliser. L’ id de
sous–réseau doit être une adresse IPv6. La
longueur du préfixe doit être un entier positif
inférieur à 128.
Instructions de conteneur imbriqué
Des instructions de conteneur imbriqué peuvent exister uniquement en tant qu’option au
sein d’un sous–réseau. Tous les conteneurs peuvent englober d’autres conteneurs
imbriqués sauf indication contraire. La profondeur maximale de l’imbrication s’élève à sept,
en incluant le sous–réseau et le conteneur global (seuls cinq conteneurs imbriqués peuvent
exister sous un conteneur de sous–réseau).
Le fournisseur et les conteneurs en option ne peuvent pas englober d’autres conteneurs
imbriqués.
Tableau 6. Mots–clés, valeurs et descriptions pour des entrées dans les instructions
de conteneur imbriqué.
Mot–clé
Valeur
Description
class
name [ range
]{OPTIONS|COMMON
OPTIONS }
Conteneur de classe. La valeur nom
correspond à une chaîne, des chaînes
séparées par un espace, des expressions
régulières, hex 0x hexdigit, 0x hexdigit
vendor
nom [ intervalle
]{OPTIONS|COMMON
OPTIONS }
Conteneur fournisseur. La valeur nom est
une chaîne, des chaînes séparées par un
espace, des expressions régulières, hex 0x
hexdigit, 0x hexdigit
Protocole TCP/IP
4-155
client
<id | 0 0xhexdigit |
regularexpression>
<ip | range | none |
any> {OPTIONA|COMMON
OPTIONS }
Conteneur client.
<id>– 1–hexdigit, 2–hexdigit,
3–hexdigit<ip|range|none|any> – adresse ip
à donner à des clients correspondant à l’ID
inoption
icode keytomatch [
range ] {
OPTIONS|COMMON
OPTIONS }
Conteneur en option
icode – code d’option entrant ou numéro
devant être spécifié par le client
keytomatch – les données d’option devant
être comparées.
Options
Ces mots–clés peuvent exister uniquement au sein d’un conteneur.
Tableau 7. Mots–clés, valeurs et descriptions pour des entrées dans la strophe d’options.
4-156
Mot–clé
Valeur
Description
exclude
range
Intervalle IP à exclure de l’intervalle
actuel, souvent utilisé lorsqu’un
intervalle n’est pas spécifié en tant que
partie des instructions du conteneur
exclude
ip
Adresse IP à exclure de l’intervalle
actuel
range
range
Intervalle IP utilisé pour augmenter
l’intervalle actuel, souvent utilisé
lorsqu’un intervalle n’est pas spécifié en
tant que partie des instructions du
conteneur
range
ip
Adresse IP à ajouter, utilisée pour
augmenter l’intervalle
stealfromchildren
policy
Prenez l’adresse des conteneurs
d’enfants si toutes les adresses sont
épuisées. Cette fonction est désactivée
par défaut.
stealfrompeer
policy
Prenez l’adresse des conteneurs de
pairs si toutes les adresses sont
épuisées. Cette fonction est désactivée
par défaut.
steafromparent
policy
Prenez l’adresse des conteneurs de
parents si toutes les adresses sont
épuisées. Cette fonction est désactivée
par défaut.
balance–option
{
balance–policy
| <option
|option option
...> }
Conteneur d’options d’équilibrage, les
options spécifiées au sein de ce
conteneur sont fournies à la base client
sur les règles. Ce mot–clé peut exister
uniquement sous le conteneur de
sous–réseau.
balance–policy
b_policy
La valeur b_policy peut être fill ou
rotate. La valeur par défaut est
rotate .
Guide de gestion du système – Communications et réseaux
fill–count
num
Le nombre de périodes d’une option est
épuisé avant la distribution de la
prochaine instance de la même option
interface–id
” interface ”
Ceci peut être répertorié uniquement
sous un sous–réseau. Les demandes
client reçues sur cette interface sont
autorisées pour l’obtention d’adresses.
Options courantes
Ceci peut exister au sein de conteneurs ou dans la section générale :
Tableau 8. Mots–clés, valeurs et descriptions pour options courantes.
Mot–clé
Valeur
Description
reconfig–policy
policy
Permet au serveur d’envoyer un
message de reconfiguration au client.
Ceci n’est pas activé et ignoré par
défaut.
rapid–commit
policy
Permet au serveur d’effectuer une
validation rapide pour le conteneur ou le
jeu global. Ceci n’est par défaut pas
activé et ignoré.
prefered–lifetime
num [ unités ]
La durée de vie favorite de l’ IANA ou
IATA. La valeur par défaut est de
43200 secondes.
valid–lifetime
num [ unités ]
La durée de vie valide de l’ IANA ou
IATA. La valeur par défaut est de
86400 secondes.
rebind
num
Pourcentage 0–100 du temps de
reconnexion à l’adresse. La valeur par
défaut est 80 pour cent.
renew
num
Pourcentage 0–100 du renouvellement
de l’adresse. La valeur par défaut est
50 pour–cent.
unicast–option
police
Permet aux conteneurs d’offrir un
échange de messages en diffusion
individuelle, ceci peut être utilisé pour
activer et désactiver des conteneurs
individuels ainsi que des sous–réseaux,
même si les règles concernant le
serveur diffèrent. Ceci n’est par défaut
pas activé et ignoré.
option
num
<string|stings
|hex>
Pour la liste d’options, reportez–vous à
Options connues du fichier du serveur
DHCPv6, page 4-158.
change–optiontable
optiontable
Autorisé uniquement au sein d’un
conteneur fournisseur.
Protocole TCP/IP
4-157
Options connues du fichier du serveur DHCPv6
Les options suivantes sont les options connues du fichier du serveur DHCPv6. Les options
comportant “Non” dans la colonne Autorisée ne peuvent pas être spécifiées dans le fichier
de configuration ; si elles le sont, elles sont ignorées.
Numéro de l’option
Type de données
par défaut
Autorisée ?
Description
1
Aucun
Non
Demander
2
Aucun
Non
Annoncer
3
Aucun
Non
Request
4
Aucun
Non
Confirmer
5
Aucun
Non
Adresse
6
Aucun
Non
Demande d’option
7
nombre
Non
Numéro de
préférence du
serveur
8
Aucun
Non
Temps écoulé
9
Aucun
Non
Message relais
11
Aucun
Non
Autorisation
12
Chaîne ASCII oui,
non, vrai, faux
Oui
Diffusion individuelle
13
Aucun
Non
État
14
Chaîne ASCII oui,
non, vrai, faux
Oui
Validation rapide
15
Aucun
Non
Classe d’utilisateur
16
Aucun
Non
Classe de
fournisseur
17
Aucun
Non
Option fournisseur
18
Aucun
Non
ID interface
19
Aucun
Non
Message de
reconfiguration
20
Chaîne ASCII oui,
non, vrai, faux
Oui
Reconfiguration
acceptée
23
Adresses IPv6
séparées par un
espace
Oui
Serveurs DNS
24
Chaîne ASCII
Oui
Liste de domaines
Valeurs
Les valeurs suivantes peuvent être utilisées pour les paramètres spécifiés ci–dessus :
unités : seconde, secondes, minute, minutes, heure, heures, jour, jours, semaine,
semaines, mois, mois, année, années
interface : en0, en1, tr0
identificateur: nombres ou caractères
règles : oui, non, vrai, faux
intervalle : ipv6addresss–ipv6addresss
expression normale: ”!epression to match$”, ”!epression to match^”
4-158
Guide de gestion du système – Communications et réseaux
Exemple fichier /etc/dhcpv6/dhcpsdv6.cnf
Ci–dessous un fichier d’exemple /etc/dhcpv6/dhcpsdv6.cnf :
logging_info{
logFileSize 4000
logItem
SYSERR
logItem
PROTERR
logItem
WARNING
logItem
EVENT
logItem
ACTION
logItem
INFO
logItem
ACNTING
logItem
TRACE
numLogFiles
3
logFileName ”/var/tmp/dhcpsdv6.log”
}
duid 1 en0
numprocessthreads 10
numpacketthreads 5
preference–number 255
reconfig–policy no
rapid–commit no
unicast–option
yes
leaseExpiredInterval 3000 secondes
unicast–enable
yes
saveInterval
60 seconds
reservedTimeInterval
8000 seconds
reservedTime
10000 seconds
clientpruneintv
20 seconds
subnet bbbb:aaaa:: 40 bbbb:aaaa::0004–bbbb:aaaa::000f {
balance–option {
option 23 dead::beef
option 23 beef::aaaa
option 24 yahoo.com
}
subnet dead:dead:aaaa:: 48
dead:dead:aaaa:aaaa::0006–dead:dead:aaaa:aaaa::000a {
id interface ”en1”
preferred–lifetime
100 seconds
valid–lifetime
200 seconds
rapid–commit yes
option 23 dead::beef beef:aaaa::bbbb:c aaaa:bbbb::cccc
option 24 ibm.com austin.ibm.com
}
Protocole TCP/IP
4-159
Configuration client DHCPv6
Le fichier /etc/dhcpv6/dhcpc6.cnf est utilisé pour configurer les clients DHCPv6.
Les directives pouvant être spécifiées dans ce fichier sont incluses ici. Si dhcpsdv6 est
sur le point d’être lancé via des redémarrages, ajoutez une entrée au fichier /etc/rc.tcpip.
Mots–clés de journalisation
Les mots–clés suivants sont valides :
Tableau 9. Mots–clés et descriptions pour des mots–clés de journalisation.
Mot–clé
Description
log–file–name
Nom du chemin d’accès et du fichier journal
le plus récent. Les noms des fichiers les
moins récents sont munis d’un numéro
accolé 1 à (n–1) ; plus ce numéro est grand,
moins le fichier est récent.
log–file–size
Indique la taille maximale d’un fichier
journal en Ko. Lorsque la taille du fichier
journal le plus récent atteint cette valeur,
celui–ci est renommé est un nouveau fichier
est créé.
log–file–num
Indique le nombre maximal de fichiers
journal gérés lorsque la taille du fichier
journal le plus récent atteint la valeur
log–file–size et que le fichier est
renommé en vue de générer un nouveau
fichier.
log–item
Précise les articles du journal devant être
journalisés.
ERR_SYS
Erreur système
ERR_OBJ
Erreur d’objet
ERR_PROT
Erreur de protocole
AVERTISSEMENT
Avertissement
EVENEMENT
Evénement survenu
ACTION
Action entreprise dans le cadre du
processus
INFO
Informations supplémentaires
COMPTA
Qui a été servi et quand
TRACE
flux de code, débogage
4-160
Guide de gestion du système – Communications et réseaux
Mot–clé DUID
Le format des entrées DUID :
duid
<duid_type> <value>
<value> ...
Le type de DUID peut être un mot–clé ou un nombre, ce qui laisse toute latitude de définir
des types de DUID à l’avenir. Trois types de DUID sont actuellement définis dans la
RFC 3315 :
Tableau 10. Mots–clé et valeurs pour les entrées DUID.
Mot–clé
Description
LLT
Type de DUID–LLT (valeur 1)
LL
DUID–LL (valeur 2)
EN
Type de DUID–EN (valeur 3)
Le format spécifique des entrées DUID dépend du mot–clé utilisé.
duid LLT
duid LL
duid EN
duid <number>
<interface name>
<interface name>
<enterprise number> <enterprise identifier>
<hex data (prefixed with ’0x’)
Mot–clé informatif
Les mot–clés informatifs sont les suivants :
Tableau 11. Mot–clé et description du mot–clé informatif.
Mot–clé
Description
info–only interfacename
Ce mot–clé précise le nom de l’interface
pour laquelle le client obtient du serveur
uniquement les informations concernant
la configuration mais pas les adresses.
Renouvellement du bail et mot–clé de ce renouvellement
Tableau 12. Mots–clé et descriptions pour le renouvellement du bail et les mots–clés de ce
renouvellement.
Mots–clés
Description
renew–time value
La période de renouvellement indique la
période après laquelle le client contacte le
serveur duquel il a obtenu les informations
concernant le bail, dans le but de le
renouveler.
rebind–time value
Dans le cas où le client ne parvient pas à
renouveler son bail (parce que le serveur ne
répond pas), la période de renouvellement
spécifie la période après laquelle le client
contacte les autres serveurs pour
renouveler le bail.
Protocole TCP/IP
4-161
Demande du mot–clé de retransmission
Tableau 13. Mots–clé et descriptions pour la demande de mots–clés de transmission.
Mots–clés
Descriptions
solicit–timeout
La période d’échéance de la demande
indique la période pendant laquelle le client
doit essayer d’envoyer un message de
demande au serveur avant que celui–ci ne
réponde.
solicit–maxcount
La période d’échéance de la demande
désigne le nombre de messages de
demande que le client doit envoyer au
serveur avant que celui–ci ne réponde.
Mots–clés d’option
Si les mots–clés d’option apparaissent hors des strophes de l’’interface”, alors ils sont
considérés comme généraux. # Les options de ce type s’appliquent à toutes les interfaces.
# Si les mots–clés d’option apparaissent au sein des strophes de l’’interface”, ces options
s’appliquent uniquement à cette interface. Le format de la strophe d’options est le suivant :
option <keyword | option code>
option <keyword | option code> exec ”exec string”
option <keyword | option code> { option specific parameters }
option <keyword | option code> { option specific parameters } exec ”exec
string”
Un code d’option peut être spécifié à l’aide du code d’option enregistré dans la IANA.
Cependant, certaines des options peuvent également être spécifiées à l’aide de mots–clés
affichés ci–dessous :
Mot–clé
4-162
Code d’option
ia–na
3
ia–ta
4
option de demande
6
validation rapide
14
classe d’utilisateur
15
classe de fournisseur
16
options de fournisseur
17
acceptation de reconfiguration
20
serveurs dns
23
liste de domaines
24
Guide de gestion du système – Communications et réseaux
Explications supplémentaires de chaque mot–clé :
Mot–clé
Objet, format et paramètres
ia–na
Description
Spécifie l’option 3. Si cela est indiqué, le client demande des adresses
permanentes au serveur.
Format
option ia–na [ { paramètres } ] [ exec ”exec chaîne” ]
Paramètres
L’option ia–na prend en compte les paramètres suivants : ia–id
<valeur>
période de renouvellement <valeur>
période de renouvellement <valeur>
Ces paramètres indiquent les valeurs favorites de l’utilisateur et sont
facultatifs. La valeur spécifiée peut être un nombre décimal ou un
nombre hexadécimal précédé de ’0x’
ia–ta
Description
Spécifie l’option 4. Si cela est indiqué, le client demande des adresses
temporaires au serveur.
Format
option ia–na [ { paramètres } ] [ exec ”exec chaîne” ]
Paramètres
L’option ia–na prend en compte les paramètres suivants : ia–id
<valeur>
Ce paramètre spécifie les valeurs favorites de l’utilisateur et il est
facultatif. La valeur spécifiée peut être un nombre décimal ou un
nombre hexadécimal précédé de ’Ox’
option de
demande
Description
Spécifie l’option 6. Si cela est indiqué, le client demande une liste
d’options au serveur.
Format
option option de demande { paramètres } [ exec ”exec chaîne” ]
Paramètres
l’option option de demande prend comme argument une liste de codes
d’option (en décimal) séparée par des espaces
validation
rapide
Description
Spécifie l’option 14. Si cela est spécifié, le client indique qu’il est prêt à
effectuer l’échange de message de réponse à la demande.
Format
option validation rapide [ exec ”exec chaîne” ]
Paramètres
Accepte uniquement le paramètre d’instruction exec facultatif
Protocole TCP/IP
4-163
Mot–clé
Objet, format et paramètres
classe
d’utilisateur
Description
spécifie l’option 15. Si cela est indiqué, le client indique le type ou
la catégorie de l’utilisateur ou les applications qu’il représente.
Format
option classe de l’utilisateur { paramètres } [ exec ”exec chaîne” ]
Paramètres
L’option classe de l’utilisateur accepte une ou plusieurs instances de
données de classe de l’utilisateur. Chaque instance des données de
classe de l’utilisateur est une chaîne d’une longueur arbitraire mise
entre guillemets ou non. Si la chaîne contient un espace vide, il doit
être mis entre guillemets. Les paramètres sont requis. Le format du
paramètre est le suivant : classe <valeur>
classe <valeur>
où la valeur est une chaîne entre guillemets ou non.
classe
fournisseur
Description
Spécifie l’option 16. Si cela est indiqué, le client indique le fournisseur
ayant fabriqué le matériel sur lequel le client fonctionne.
Format
option classe de fournisseur { paramètres } [ exec ”exec chaîne” ]
Paramètres
L’option classe de fournisseur accepte le numéro d’entreprise
enregistrée du fournisseur ainsi qu’une ou plusieurs instances des
données de la classe de fournisseur. Chaque instance des données
de la classe de fournisseur est une chaîne d’une longueur arbitraire
mise entre guillemets ou pas, chacune d’entre–elles décrivant
certaines caractéristiques de la configuration matérielle du client. Les
paramètres NE sont PAS facultatifs. Le format est le suivant : id
fournisseur <valeur>
classe <valeur>
classe <valeur>
où la valeur est une chaîne entre guillemets ou pas.
options
fournisseur
Description
Spécifie l’option 17. Si cela est indiqué, le client indique au serveur les
informations spécifiques au fournisseur.
Format
option options fournisseur <numéro d’entreprise> { paramètres } [ exec
”exec chaîne” ]]
Paramètres
L’option options de fournisseur accepte le numéro d’entreprise
enregistré du fournisseur ainsi qu’une ou plusieurs instances des
données d’options de fournisseur. Chaque instance des données
d’options de fournisseur est un code d’option de fournisseur suivi de
données d’options en chaîne ou au format hexadécimal. Les
paramètres NE sont PAS facultatifs. Le format est le suivant : id
fournisseur <valeur>
option <code option> <données option>
option <code option> <données option>
où les données d’options sont une chaîne mise entre guillemets ou
pas, ou une chaîne hexadécimale (précédée de ’0x’)
4-164
Guide de gestion du système – Communications et réseaux
Mot–clé
Objet, format et paramètres
acceptation de Description
reconfiguration
Spécifie l’option 20. Si cela est indiqué, le client indique au serveur s’il
est disposé à accepter un message de reconfiguration de la part du
serveur.
Format
option reconfiguration acceptée [ exec ”exec chaîne” ]
Paramètres
l’option reconfiguration acceptée n’accepte pas de paramètre
spécifique à l’option autre que l’instruction exec.
serveurs dns
Description
spécifie l’option 23. Si cela est indiqué, le client indique au serveur
l’ensemble des serveurs dns favoris.
Format
option serveurs dns [ {paramètres } ] [ exec ”exec chaîne” ]
Paramètres
l’option serveurs dns accepte comme argument une liste d’adresses
IPv6 séparées par des espaces/des lignes.
liste de
domaines
Description
spécifie l’option 24. Si cela est indiqué, le client indique la liste des
domaines favoris.
Format
option liste de domaines[ { paramètres } ] [ exec ”exec chaîne” ]
Paramètres
l’option liste de domaines accepte une liste de chaînes de noms de
domaines séparées par des espaces/des lignes.
Protocole TCP/IP
4-165
mots–clés d’interface
Tableau 14. mot–clé et description concernant les mots–clés d’interface.
Mots–clés
Descriptions
interface <interfacename> [ {
option declaration/s } ]
L’instruction d’interface accepte une ou
plusieurs déclarations d’options comme
arguments. Ces options spécifiées au sein
de la strophe de l’interface sont spécifiques
à cette interface, contrairement aux options
déclarées hors de la strophe d’interface qui
s’appliquent à toutes les interfaces.
interface
en1
{
option ia–na {
ia–id
renew–time
rebind–time
01
0x40
0x60
}
option
option
request–option
{ 3 23 24 }
user–class {
class ibm
class ”userclassA and B”
class ”userclassB”
}
option
vendor–class {
vendor–id
1234
class ”vendorclassA”
class ”vendorclassB”
}
option
vendor–opts {
id fournisseur
2343
option 89
vendoroption89
option 90
vendoroption90
}
option
reconf–accept
Agent relais DHCP
Le fichier /etc/dhcprd.cnf est le fichier de configuration pour l’agent relais DHCP et
BOOTP. Le format du fichier, les directives autorisées ainsi que les mots–clés sont
expliqués ici.
Les directives sont spécifiées au format suivant :
<
keyword
> <
value1
> ... <
valueN
>
La présence et les valeurs de ces paramètres sont utilisées par l’agent relais qui est lancé
ou relancé.
Cet ensemble de paramètres indique les fichiers journaux gérés par ce serveur.
Chaque paramètre est identifié par un mot–clé et suivi de sa valeur.
4-166
Guide de gestion du système – Communications et réseaux
Mot–clé
Valeur
Définition
numLogFiles
0àn
Nombre de fichiers journaux. Si 0 est
indiqué, aucun fichier journal n’est géré et
aucun message journal ne s’affiche. n est le
nombre maximal de fichiers journaux gérés,
lorsque la taille du fichier journal le plus
récent atteint sa taille maximale et qu’un
nouveau fichier journal est créé.
logFileSize
En Ko
Taille maximale d’un fichier journal. Lorsque
la taille du fichier journal le plus récent
atteint cette valeur, celui–ci est renommé
puis un nouveau fichier journal est créé.
logFileName
chemin d’accès du
fichier
Nom du fichier journal le plus récent. Les
fichiers journaux les moins récents
possèdent un numéro de 1 à (n – 1) accolé
à leur nom ; plus ce numéro est élevé,
moins le fichier est récent.
logItem
Il s’agit d’un article à ERR_SYS
journaliser.
Erreur du système au niveau de
l’interface menant à la plate–forme.
ERR_OBJ
Erreur d’objet entre des objets du
processus.
ERR_PROT
Erreur de protocole entre le client et le
serveur.
AVERTISSEMENT
Avertissement, mérite l’attention de
l’utilisateur.
EVENEMENT
Evénement survenu dans le cadre du
processus.
ACTION
Action entreprise par le processus.
INFO
Information pouvant être utile.
COMPTA
Qui a été servi et quand.
TRACE
Flux de code pour la résolution
d’incidents.
Protocole TCP/IP
4-167
Un fichier /etc/dhcprd.cnf peut par exemple avoir les entrées suivantes :
numLogFiles
logFileSize
logFileName
logItem
logItem
logItem
logItem
logItem
logItem
logItem
logItem
logItem
4
1000
/usr/tmp/dhcprd.log
SYSERR
OBJERR
PROTERR
WARNING
EVENT
ACTION
INFO
ACNTING
TRACE
Mot–clé
Valeur
Définition
relay
IPv4, IPv6, ou ALL
Indique le mode de relais de
paquets. Si IPv4 est indiqué,
l’agent relais sert uniquement
d’agent relais dhcpv4. Il s’agit du
mode par défaut de l’agent relais.
Si IPv6 est indiqué, l’agent
relais sert uniquement d’agent
relais dhcpv6.
Si ALL est indiqué, l’agent relais
sert uniquement d’agent relais
dhcpv4 et dhcpv6.
serveur
adresse IP
Indique l’adresse IP d’un serveur
bootp ou dhcp. Le paquet est
transmis aux serveurs répertoriés
dans ce fichier.
serveur6
Adresse IPv6
Indique l’adresse IPv6 du serveur
dhcpv6. Le paquet est transmis
aux serveurs répertoriés ici.
option6
< code d’option >
< données d’option >
Indique les options de l’agent
relais dhcpv6. Le mot–clé est
valide uniquement si le mode de
relais est défini pour IPv6. La
valeur code d’option est indiquée
par un nombre décimal. La
valeur données d’option est
indiquée en tant que chaîne mise
entre guillemets ou pas, ou au
format hexadécimal (précédée
de 0x)
site unique
4-168
Guide de gestion du système – Communications et réseaux
Indique que l’unité sur laquelle
l’agent relais est utilisé appartient
à un seul site.
Démon DHCP avec structure PXED
(Preboot Execution Environment Proxy)
Le serveur DHCP proxy PXE se comporte comme un serveur DHCP ; il écoute le trafic
client DHCP ordinaire et répond à certaines requêtes. Toutefois, contrairement au serveur
DHCP, le serveur DHCP proxy ne gère pas les adresses réseau, et il ne répond qu’aux
clients qui s’identifient en tant que clients PXE. Les réponses données par le serveur DHCP
proxy PXE contiennent le mécanisme selon lequel le client localise les serveurs de
démarrage ou les adresses réseau et les descriptions des serveurs de démarrage
compatibles pris en charge.
L’utilisation d’un serveur DHCP proxy PXE avec un serveur DHCP fournit trois
fonctionnalités clés. Tout d’abord, vous pouvez séparer l’administration des adresses
réseau de l’administration des images de démarrage. En utilisant deux processus différents
sur le même système, vous pouvez configurer les informations de démarrage gérées par le
serveur DHCP proxy PXE sans intervenir sur la configuration du serveur DHCP ou avoir
besoin d’y accéder. Ensuite, vous pouvez définir plusieurs serveurs de démarrage et laisser
le client PXE en sélectionner un lors du démarrage. Chaque serveur de démarrage peut,
par exemple, offrir un type différent de système d’exploitation ou de configuration système.
Enfin, l’utilisation du serveur proxy offre la possibilité de configurer le client PXE de telle
sorte qu’il utilise l’adressage IP multi–diffusion pour trouver la localisation des serveurs de
démarrage compatibles.
Le serveur DHCP proxy PXE peut être configuré pour s’exécuter sur le même système que
celui exécutant le serveur DHCP ou sur un système différent. En outre, il peut être configuré
pour s’exécuter sur le système qui exécute également le démon du serveur de démarrage
ou sur un système différent.
Le serveur DHCP proxy PXE
Le serveur PXED est divisé en trois grandes parties : une base de données, un moteur de
protocole et un ensemble de routines de service, chaque partie disposant de ses propres
informations de configuration.
La base de données PXED
La base de données db_file.dhcpo est utilisée pour générer les options à transmettre au
client lorsqu’il envoie un paquet REQUEST. Les options renvoyées par la base de données
dépendent du type de serveur choisi. Celui–ci est défini à l’aide du mot–clé pxeservertype
dans le fichier pxed.cnf.
A partir des informations du fichier de configuration, la base de données est amorcée et sa
cohérence est vérifiée.
Le moteur de protocole PXED
Pour AIX Version 4.3.1 et ultérieures, le moteur de protocole PXED est basé sur Preboot
Execution Environment (PXE) Specification Version 2.1 d’Intel, mais il reste compatible avec
PXE Specification Version 1.1. Le moteur de protocole utilise la base de donnés pour
déterminer quelles informations doivent être retournées au client.
Opérations PXED enchaînées
Le dernier élément du serveur PXED est en fait un ensemble d’opérations qui permettent
d’assurer la continuité de l’exécution. Comme le serveur PXED est du type enchaîné, ces
opérations sont définies sous la forme de routines qui interviennent occasionnellement pour
s’assurer du bon déroulement de l’exécution.
La première routine, ou routine principale, gère les requêtes SRC (par exemple startsrc,
stopsrc, lssrc, traceson et refresh). Cette routine coordonne également toutes les
opérations qui affectent toutes les routines et gère les signaux. Par exemple :
Protocole TCP/IP
4-169
• A SIGHUP (–1) provoque un rafraîchissement de toutes les bases de données du fichier
de configuration.
• A SIGTERM (–15) entraîne l’arrêt en douceur du serveur.
L’autre routine traite les paquets. Selon le type du serveur, une ou deux routines sont
utilisées. L’une d’entre elles écoute le port 67 et la deuxième le port 4011. Chacune peut
traiter une requête d’un client.
Configuration du serveur PXED
Par défaut, la configuration du serveur PXED est effectuée par la lecture du fichier
/etc/pxed.cnf, qui spécifie la base de données initiale d’adresses et d’options du serveur.
Le serveur est démarré à partir de Web-based System Manager, de SMIT ou via les
commandes SRC.
La configuration de PXED constitue la tâche la plus délicate dans le cadre de l’utilisation de
PXED sur votre réseau. Vous devez d’abord déterminer le nombre de réseaux qui devront
accueillir des clients PXE. L’exemple suivant configure le démon pxed de telle sorte qu’il
s’exécute sur la même machine que le serveur DHCP :
pxeservertype
proxy_on_dhcp_server
subnet default
{
vendor pxe
{
option 6
2
démarrage multi–diffusion
option 8
1
2
# Désactiver la découverte du serveur de
9.3.4.5
9.3.4.6
2
1
9.3.149.29
# L’option ci–dessus fournit la liste des
serveurs de démarrage
option 9
0
”PXE bootstrap server” \
1
”Microsoft Windows NT Boot Server” \
2
”DOS/UNDI Boot Server”
option 10 20
”secondes avant la sélection automatique de
la première option du menu de démarrage”
}
}
Les sous–options du conteneur fournisseur ne sont envoyées aux clients PXE que si
l’adresse IP du client figure dans la plage d’adresses IP du sous–réseau (de 9.3.149.0 à
9.3.149.255 par exemple).
L’exemple suivant configure le démon pxed de telle sorte qu’il s’exécute sur une autre
machine que le serveur DHCP :
4-170
Guide de gestion du système – Communications et réseaux
subnet default
{
vendor pxe
{
option
6
10
# Le nom du fichier de démarrage est
présent dans la proposition de paquet
# pxed du client.
option
8
1
2
9.3.4.5
9.3.4.6
2
1
9.3.149.29
# L’option ci–dessus fournit la liste des
serveurs de démarrage
option
9
0
”PXE bootstrap server” \
1
”Microsoft Windows NT Boot Server”
\
2
”DOS/UNDI Boot Server”
option 10 20
”secondes avant la sélection automatique de
la première option du menu de démarrage”
bootstrapserver
9.3.148.65
pxebootfile
1
2
1
window.one
pxebootfile
2
2
1
linux.one
pxebootfile
1
2
1
hello.one
client 6 10005a8ad14d any
{
pxebootfile
1
2
1
aix.one
pxebootfile
2
2
1
window.one
}
}
Vendor pxeserver
{
option
7
224.234.202.202
}
Le mot–clé pxeservertype n’est pas défini dans le fichier de configuration. La valeur par
défaut pdhcp_only est donc utilisée, ce qui signifie que le serveur PXED est exécuté sur
une machine différente que le serveur DHCP. Dans cette configuration, le serveur PXED est
à l’écoute des paquets BINLD REQUEST/INFORM des clients sur deux ports (67 et 4011).
L’option 7 est envoyée au serveur BINLD lorsque le serveur PXED reçoit un paquet
REQUEST/INFORM en provenance de BINLD sur le port 67 et si l’option 60 est définie sur
le serveur PXED.
La clause de base de données db_file indique la méthode à utiliser pour le traitement de
cette portion du fichier de configuration. Les commentaires sont introduits par le symbole #.
Tout le texte placé entre le # et la fin de la ligne est ignoré par le serveur PXED. Chaque
ligne d’option est utilisée par le serveur pour indiquer au client ce qu’il doit faire. La
section Sous–options du conteneur fournisseur PXE page 4-175 décrit les sous–options
reconnues et prises en charge à l’heure actuelle. Pour savoir comment définir des options
inconnues du serveur, reportez–vous à la section Syntaxe du fichier de serveur PXED pour
le fonctionnement général du serveur, page 4-177.
Le fichier de configuration
Le fichier de configuration comprend une section d’adresses et une section de définition
d’options, basées sur le concept des conteneurs, qui renferment les options, les
modificateurs et, le cas échéant, d’autres conteneurs.
Un conteneur (qui est finalement une méthode de regroupement des options) fait appel à un
identificateur pour classer les clients en plusieurs groupes. Les types de conteneur sont le
sous–réseau, la classe, le fournisseur et le client. A l’heure actuelle, il n’existe pas de
conteneur générique définissable par l’utilisateur. L’Identificateur définit le client de manière
unique, de sorte qu’il soit possible de suivre sa trace même s’il est déplacé vers un autre
sous–réseau. Il est possible d’utiliser plusieurs types de conteneur pour définir les droits
d’accès du client.
Protocole TCP/IP
4-171
Les options sont les identificateurs qui sont retournés au client, par exemple la passerelle
par défaut et l’adresse de DNS.
Conteneurs
Lorsque le serveur DHCP reçoit une requête, le paquet est analysé et les clés
d’identification permettent de déterminer les conteneurs, les options et les adresses à
extraire.
L’exemple précédent présente un conteneur de sous–réseau. La clé d’identification est la
position du client au sein du réseau. Si le client fait partie de ce réseau, alors il est intégré à
ce conteneur.
Chaque type de conteneur utilise une option différente pour identifier les clients :
• Le conteneur sous–réseau utilise le champ giaddr ou l’adresse de l’interface réceptrice
pour déterminer le sous–réseau d’origine du client.
• Le conteneur classe utilise la valeur de l’option 77
(User Site Class Identifier – identificateur de la classe du site utilisateur).
• Le conteneur fournisseur utilise la valeur de l’option 60
(Vendor Class Identifier – identificateur de la classe du fournisseur).
• Le conteneur client utilise la valeur de l’option 61 (Client Identifier – identificateur du
client) pour les clients PXE et le champ chaddr du paquet BOOTP pour les clients
BOOTP.
Sauf pour les sous–réseaux, chaque conteneur accepte la spécification de la valeur
de correspondance à l’aide d’expressions régulières.
A ces conteneurs, il faut ajouter un conteneur implicite, le conteneur global. Sauf
spécification contraire ou refus explicite, les options et modificateurs placés dans le
conteneur global s’appliquent à tous les conteneurs. La plupart des conteneurs peuvent être
inclus dans d’autres conteneurs, ce qui implique une certaine visibilité. Les conteneurs
peuvent ou non être associés à des plages d’adresses. Tel est le cas, par nature, des
sous–réseaux.
Les règles de base s’appliquant aux conteneurs et sous–conteneurs sont les suivantes :
• Tous les conteneurs sont valides au niveau général.
• Les sous–réseaux ne doivent jamais être inclus dans d’autres conteneurs.
•
Des conteneurs restreints ne peuvent englober des conteneurs réguliers du même type.
(Par exemple, un conteneur doté d’une option autorisant uniquement la classe
Comptabilité ne peut receler un conteneur doté d’une option autorisant toutes les
classes commençant par la lettre ”c”. Ceci n’est pas autorisé.)
•
Les conteneurs client restreints ne peuvent englober de sous–conteneurs.
En tenant compte des règles ci–dessus, vous pouvez générer une hiérarchie de conteneurs
qui répartissent les options en différents groupes pour des clients ou des ensembles de
clients spécifiques.
Comment sont gérées les options et adresses lorsqu’un client correspond à plusieurs
conteneurs ? Le serveur DHCP reçoit les messages, il transmet la requête à la base de
données (fichier db_file en l’occurrence) et une liste de conteneurs est générée. La liste est
organisée par ordre de profondeur et de priorité. La priorité se définit comme une hiérarchie
implicite au sein des conteneurs. Les conteneurs stricts ont une priorité supérieure à celle
des conteneurs réguliers. Les clients, les classes, les fournisseurs et enfin, les
sous–réseaux sont triés, dans cet ordre, et à l’intérieur de chaque conteneur en fonction
de leur profondeur. Ceci aboutit à une liste allant du plus spécifique au moins spécifique.
Par exemple :
4-172
Guide de gestion du système – Communications et réseaux
Sous–réseau 1
––Classe 1
––Client 1
Sous–réseau 2
––Classe 1
––––Fournisseur 1
––––Client 1
––Client 1
L’exemple ci–dessus présente deux sous–réseaux, Sous–réseau 1 et Sous–réseau 2.
Il y a un nom de classe, Classe 1, un nom de fournisseur, Fournisseur 1 et un nom de
client, Client 1. Classe 1 et Client 1 sont définis en plusieurs endroits. Comme ils
résident dans des conteneurs différents, leurs noms peuvent être identiques mais leurs
valeurs, différentes. Si Client 1 envoie un message au serveur DHCP depuis
Sous–réseau 1 avec Classe 1 spécifiée dans sa liste d’options, le serveur DHCP va
générer le chemin de conteneur suivant :
Sous–réseau 1, Classe 1, Client 1
Le conteneur le plus spécifique apparaît en dernier. Pour obtenir une adresse, la liste est
étudiée dans l’ordre inverse de la hiérarchie et la première adresse disponible est retenue.
Ensuite, l’étude de la liste de poursuit en remontant dans la hiérarchie afin d’obtenir les
options. Les options peuvent remplacer des valeurs précédentes, sauf si une option deny a
été incluse dans le conteneur. Par ailleurs, puisque Classe 1 et Client 1 figurent dans
Sous–réseau 1, ils sont ordonnés en fonction de la priorité de leur conteneur. Si le même
client se trouve dans Sous–réseau 2 et envoie le même message, la liste de conteneur
générée sera :
Sous–réseau 2, Classe 1, Client 1 (au niveau de Sous–réseau 2),
Client 1 (au niveau de Classe 1)
Sous–réseau 2 apparaît en premier, suivi de Classe 1, puis de Client 1 au niveau de
Sous–réseau 2 (car cette instruction client ne se trouve qu’à un niveau en dessous dans
la hiérarchie). Cette hiérarchie implique qu’un client correspondant à la première instruction
client est moins spécifique que le client correspondant à Client 1 de Classe 1 au sein
de Sous–réseau 2.
La priorité sélectionnée en fonction de la profondeur dans la hiérarchie prend le pas sur la
priorité des conteneurs eux–mêmes. Par exemple, si le même client émet le même
message, en précisant cette fois un identificateur de fournisseur, la liste de conteneur
devient :
Sous–réseau 2, Classe 1, Fournisseur 1, Client 1
(au niveau de Sous–réseau 2), Client 1 (au niveau de Classe 1)
La priorité au niveau des conteneurs améliore les performances en matière de recherche
car elle correspond à un concept général selon lequel les conteneurs client constituent le
moyen le plus spécifique de définir un ou plusieurs clients. Le conteneur client contient des
adresses plus spécifiques qu’un conteneur classe, lui–même plus spécifique qu’un
conteneur fournisseur, le conteneur sous–réseau étant le moins spécifique de tous.
Adresses et plages d’adresses
Les plages d’adresses, obligatoires pour les conteneurs sous–réseau, peuvent être
associées à tout type de conteneur. Chaque plage définie pour un conteneur doit être un
sous–ensemble de la plage du conteneur parent et ne doit pas présenter de
chevauchement avec la plage d’un autre conteneur. Par exemple, si une classe définie
dans un sous–réseau est associée à une plage d’adresses, cette plage doit constituer un
sous–ensemble des adresses de la plage du sous–réseau. En outre, le conteneur de la
classe ne doit pas recouvrir, même partiellement, d’autres plages d’adresses au même
niveau.
Protocole TCP/IP
4-173
Les plages peuvent être définies sur la ligne du conteneur et modifiées au moyen
d’instructions de plages et d’exclusion afin que des jeux d’adresse non contigus puissent
être associés à un conteneur. Ainsi, si les dix premières adresses d’un sous–réseau sont
disponibles, ainsi que les dix suivantes, le sous–réseau peut spécifier ces adresses par
plage dans la clause de sous–réseau afin de réduire l’utilisation de la mémoire et les
risques de collision d’adresses avec d’autres clients ne se trouvant pas dans les plages
spécifiées.
Dès qu’une adresse est sélectionnée, tout conteneur suivant dans la liste contenant les
plages d’adresses est retiré de la liste, avec ses enfants. La raison en est que les options
spécifiques au réseau dans les conteneurs supprimés ne sont pas valides si l’adresse n’est
pas utilisée à partir de ce conteneur.
Options
Une fois la liste ponctionnée pour déterminer les adresses, un ensemble d’options est
généré pour le client. Lors de ce processus de sélection, les nouvelles options remplacent
les options précédemment sélectionnées, sauf si une clause deny est rencontrée, auquel
cas l’option refusée est retirée de la liste envoyée au client. Cette méthode autorise les
héritages à partir des conteneurs parents afin de réduire la quantité de données à spécifier.
Journalisation
Les paramètres de journalisation sont précisés dans un conteneur tel que la base de
données, mais le mot de passe du conteneur est : logging_info. Au démarrage, il est
conseillé d’activer le niveau de journalisation le plus élevé. En outre, il est préférable de
configurer cette fonction préalablement à toute autre afin que les erreurs de configuration
puissent être consignées après initialisation du sous–système de journalisation. Le mot–clé
logitem active le niveau de journalisation ; si vous supprimez logitem, le niveau de
journalisation sera désactivé. Les autres mots–clé concernant la journalisation permettent
d’indiquer le nom du fichier journal, sa taille et le nombre de journaux utilisés en alternance.
Considérations de performance
Vous n’êtes pas sans savoir que certains mots–clé de configuration ainsi que la structure du
fichier de configuration ont une incidence sur l’utilisation de la mémoire et les performances
du serveur PXED.
Premièrement, il est possible d’éviter toute sollicitation excessive de la mémoire en
appréhendant le modèle d’héritage des options des conteneurs parents vers les conteneurs
enfants. Dans un environnement qui ne prend pas en charge les clients non répertoriés,
l’administrateur doit expressément lister chaque client du fichier. Lorsque des options sont
répertoriées pour chaque client en particulier, le serveur sollicite plus de capacité mémoire
pour stocker cette structure de configuration arborescente que lorsque des options sont
héritées d’un conteneur parent (conteneurs de sous–réseau, de réseau ou conteneurs
globaux, par exemple). Par conséquent, l’administrateur doit vérifier la répétition ou non des
options relatives au client au sein du fichier de configuration. Si tel est le cas, il doit décider
si ces options peuvent ou non être définies dans le conteneur parent et partagées par
l’ensemble des clients.
Deuxièmement, l’utilisation des entrées logItem INFO et TRACE entraîne la consignation
de nombreux messages au cours du traitement de chaque message du client PXE. L’ajout
d’une ligne au journal peut s’avérer une opération onéreuse. C’est pourquoi la limitation du
volume de journalisation améliore les performances du serveur PXED. En cas de
présomption d’erreur sur le serveur PXED, la journalisation peut être dynamiquement
réactivée à l’aide de la commande SRC traceson.
4-174
Guide de gestion du système – Communications et réseaux
Sous–options du conteneur fournisseur PXE
Dans le cadre de la prise en charge d’un client PXE, le serveur DHCP transmet l’option
suivante au serveur BINLD, qui l’utilise pour sa configuration :
Opt
Num
Type de données
par défaut
Autorisée ? Description
6
Nombre décimal
Oui
PXE_DISCOVERY_CONTROL. Limite 0–16.
Ceci est un champ de bit. Bit 0 est le bit le moins
significatif.
bit 0
S’il est défini, il désactive la découverte
de diffusion.
bit 1
S’il est défini, il désactive la découverte
de multidiffusion.
bit 2
S’il est défini, seuls les serveurs de
PXE_BOOT_ SERVERS sont
utilisés/acceptés.
bit 3
S’il est défini, et si un nom de fichier de
démarrage est présent dans le paquet
PXED initial, le fichier de démarrage est
téléchargé (sans invite préalable).
bit 4–7
Doit être défini sur 0. Si cette option
n’est pas fournie, le client suppose que
tous les bits sont égaux à 0.
7
Un ”dotted quad”
Oui
Adresse IP de multi–diffusion. Adresse IP de
multi–diffusion de découverte du serveur de
démarrage. Les serveurs dotés de cette
fonctionnalité doivent écouter cette adresse de
multi–diffusion. Cette option est requise si le bit de
désactivation de la découverte multi–diffusion (bit
1) de l’option PXE_DISCOVERY_ CONTROL n’est
pas défini.
Protocole TCP/IP
4-175
Opt
Num
Type de données
par défaut
Autorisée ? Description
8
Boot server type
(0–65535)
Oui
PXE_BOOT_SERVERS IP address count (0–256)
Type 0
Microsoft Windows IP address...IP address NT
Boot Server Boot server type IP address
Type 1
Intel LCM Boot Server count IP address ...
Type 3
DOS/UNDI Boot Server IP address
Type 4
NEC ESMPRO Boot Server
Type 5
WSoD Boot Server
Type 6
LCCM Boot Server
Type 7
CA Unicenter TNG Boot Server.
Type 8
HP OpenView Boot Server.
Types 9 à 32767
Réservés
Types 32768 à 65534
A l’usage du fournisseur
Type 65535
PXE API Test Server.
Si IP address count a la valeur zéro pour un type
de serveur, le client peut accepter des offres de
n’importe quel serveur de démarrage de ce type.
Les serveurs de démarrage ne répondent pas aux
requêtes de découverte des types qu’ils ne
prennent pas en charge.
4-176
9
Boot server type
(0–65535)
Oui
PXE_BOOT_MENU ”description” ”order” du
serveur de démarrage implicite dans le type.
”description”...menu order.
10
Délai d’attente en
secondes (0–255)
Oui
PXE_MENU_PROMPT ”prompt” Le délai d’attente
correspond au nombre de secondes avant la
sélection automatique de la première option du
menu de démarrage. Sur le système client, l’invite
est affichée suivie du nombre de secondes restant
avant cette sélection. Si l’utilisateur appuie sur la
touche F8 sur le système client, un menu est
affiché. Si cette option est fournie au client, le
menu est affiché sans invite ni délai d’attente. Si le
délai d’attente est égal à 0, la première option du
menu est automatiquement sélectionnée. Si le
délai d’attente est égal à 255, le menu et l’invite
sont affichés sans sélection automatique ni délai
d’attente.
Guide de gestion du système – Communications et réseaux
Syntaxe du fichier de serveur PXED pour le fonctionnement général
du serveur
Remarque :
Les unités de temps (time_units) indiquées dans le tableau suivant sont
facultatives et correspondent à un modificateur du temps réel. L’unité de
temps par défaut est exprimée en minutes. Les valeurs autorisées sont
les secondes (1), les minutes (60), les heures (3600), les jours (86400),
les semaines (604800), les mois (2392000) et les années (31536000). Le
nombre entre parenthèses est un multiplicateur appliqué à la valeur n
spécifiée pour exprimer cette valeur en secondes.
Mot–clé
Forme
Sous–
Valeur
conteneurs ? par
défaut
Signification
database
database db type
Oui
Aucune
Conteneur principal renfermant les
définitions des pools d’adresses,
options et instructions d’accès client.
db type est le nom du module chargé
pour traiter cette portion du fichier.
La seule valeur actuellement disponible
est db_file.
logging_
info
logging_info
Oui
Aucune
Conteneur de journalisation principal
définissant les paramètres de
journalisation.
logitem
logitem NONE
Non
Non
activé
ti é
pour tous
par
défaut.
Active le niveau de journalisation.
Pl i
Plusieurs
lignes
li
sontt autorisées.
t i é
logitem SYSERR
logitem OBJERR
logitem
PROTOCOL
logitem PROTERR
logitem WARN
logitem WARNING
logitem CONFIG
logitem EVENT
logitem
PARSEERR
logitem ACTION
logitem ACNTING
logitem STAT
logitem TRACE
logitem RTRACE
logitem START
numLog
Files
numLogFiles n
Non
0
Indique le nombre de fichiers journaux
à créer. Les journaux alternent lorsque
le premier journal est rempli. n est le
nombre de journaux à créer.
logFile
Size
logFileSize n
Non
0
Indique la taille de chaque fichier
journal, exprimée en unités de
1024 octets.
Protocole TCP/IP
4-177
Mot–clé
Forme
Sous–
Valeur
conteneurs ? par
défaut
Signification
logFile
Name
logFileName path
Non
Aucune
Indique le chemin d’accès au premier
fichier journal. Le nom d’origine du
fichier journal est nomfichier ou
nomfichier.extension. nomfichier est
limité à huit caractères. Lorsque la
permutation des fichiers est effectuée,
le premier fichier est renommé en
conservant la base du nom, nomfichier,
et en lui ajoutant un numéro, ou en
remplaçant l’extension par un numéro.
Par exemple, si le nom original du
fichier est file, le nom du fichier après
permutation devient file01. Si le nom
du fichier d’origine est file.log, il
devient file.01.
pxeserve
r
type
pxeservertype
servertype
Non
dhcp_only Indique le type du serveur dhcpsd.
servertype peut avoir la valeur
proxy_on_dhcp_server, ce qui signifie
que PXED est exécuté sur la même
machine que le serveur DHCP et est à
l’écoute des requêtes client PXE sur le
port 4011 uniquement, ou la valeur par
défaut pdhcp_only, ce qui signifie que
PXED est exécuté sur une machine à
part et doit écouter les paquets client
sur les ports 67 et 4011.
Remarques sur la syntaxe du fichier de serveur PXED pour la base
de données db_file :
Remarques :
1. Les unités de temps (time_units) indiquées dans le tableau suivant sont facultatives et
correspondent à un modificateur du temps réel. L’unité de temps par défaut est exprimée
en minutes. Les valeurs autorisées sont les secondes (1), les minutes (60), les heures
(3600), les jours (86400), les semaines (604800), les mois (2392000) et les années
(31536000). Le nombre entre parenthèses est un multiplicateur appliqué à la valeur n
spécifiée pour exprimer cette valeur en secondes.
2. Les éléments spécifiés dans un conteneur peuvent être remplacés par ceux d’un
sous–conteneur. Vous pouvez par exemple définir les clients BOOTP de manière
globale, et, au sein d’un sous–réseau particulier, autoriser les clients BOOTP en
indiquant le mot–clé supportBootp dans les deux conteneurs.
3. Les conteneurs client, classe et fournisseur acceptent les expressions régulières. Pour la
classe et le vendeur, une chaîne entre guillemets dont le premier caractère à l’intérieur
des guillemets est un point d’exclamation (!) indique que le reste de la chaîne doit être
considéré comme une expression régulière. Le conteneur client accepte les expressions
régulières dans les champs hwtype et hwaddr. Une chaîne unique est utilisée pour
représenter les deux champs, selon la syntaxe suivante :
nombre_décimal–données
Si nombre_décimal est égal à zéro, les données constituent une chaîne ASCII. Pour tout
autre nombre, les données sont des chiffres hexadécimaux.
4-178
Guide de gestion du système – Communications et réseaux
Mot–clé
Forme
Sous–
Valeur
conteneurs ? par
défaut
Signification
subnet
subnet
default
Oui
Aucune
Spécifie un sous–réseau sans
plage associée. Il n’est utilisé par le
serveur que lorsqu’il répond à un
paquet INFORM émanant du client.
subnet
subnet
subnet id
netmask
Oui
Aucune
Spécifie un sous–réseau et un pool
d’adresses. Toutes les adresses
sont supposées faire partie du pool,
sauf si une plage est spécifiée sur
l ligne
la
li
ou sii lles adresses
d
sontt
modifiées ultérieurement dans le
conteneur par une instruction de
plage ou d’exclusion. La plage
facultative est une paire d’adresses
IP en format de ”dotted quad”
séparées par un tiret. Il est possible
de préciser un label et une priorité.
Ceux–ci sont utilisés dans les
sous–réseaux virtuels pour
identifier et classer les
sous–réseaux du sous–réseau
virtuel. Le label et la priorité sont
séparés par un signe deux–points.
Ces conteneurs ne sont autorisés
qu’au niveau global ou au niveau
du conteneur base de données.
Oui
Aucune
Spécifie un sous–réseau qui
s’inscrit dans un conteneur réseau.
Il définit une plage d’adresses
formant la totalité du sous–réseau,
sauf si la plage facultative est
indiquée. Le masque de réseau
associé au sous–réseau est issu du
conteneur réseau environnant.
subnet
subnet id
netmask
range
subnet
subnet id
netmask
label:priority
subnet
subnet id
netmask
range
label:priority
subnet
subnet
subnet id
range
Remarque: Cette méthode est
déconseillée au profit
des autres formes de
sous–réseaux.
Protocole TCP/IP
4-179
Mot–clé
Forme
Sous–
Valeur
conteneurs ? par
défaut
Signification
option
option
number data
...
Non
Aucune
Spécifie une option à envoyer à un
client ou, dans le cas d’un refus
(deny), une option qui ne doit pas
être envoyée à un client. La clause
optionnelle * deny signifie que
toutes les options non spécifiées
dans le conteneur en cours ne
doivent pas être retournées au
client. L’option numberdeny ne
refuse que l’option spécifiée.
number est un entier 8 bits non
signé. data est spécifique à l’option
(voir ci–dessus) ou peut être définie
sous la forme d’une chaîne entre
guillemets (texte
ASCII)) ou
g
(
0xhexdigits ou hex”hexdigits” ou
encore hex ”hexdigits”. Si l’option
correspond à un conteneur
fournisseur, elle sera encapsulée
avec les autres options dans une
option 43.
Non
Aucune
Modifie la plage sur le conteneur
qui comporte l’instruction exclude.
L’instruction exclude n’est pas
valide au niveau des conteneurs de
base de données ou au niveau
général. L’instruction exclude
supprime l’adresse ou la plage
spécifiée de la plage actuelle sur le
conteneur. Elle permet de créer des
plages non contiguës pour sous
sous–réseaux ou d’autres
conteneurs.
Non
Aucune
Modifie la plage sur le conteneur
qui comporte l’instruction range.
L’instruction range n’est pas valide
au niveau des conteneurs de base
de données ou au niveau général.
S’il s’agit de la première plage du
conteneur qui ne spécifie pas une
plage sur la ligne de définition du
conteneur, la plage du conteneur
devient alors la plage spécifiée par
l’instruction range. Toute instruction
range suivante, ou toutes les
instructions range dans le cas d’un
conteneur spécifiant des plages
dans sa définition sont ajoutées à la
page actuelle. Avec l’instruction
range, il est possible d’ajouter à la
plage existante une adresse unique
ou un jeu d’adresses. La plage doit
être incorporée dans la définition du
conteneur de sous–réseau.
option
numberdeny
option * deny
exclude
exclude an
IP address
exclude
dotted_quad
–dotted_
quad
range
range
IP_address
range
dotted_quad
–dotted_
quad
4-180
Guide de gestion du système – Communications et réseaux
Mot–clé
Forme
Sous–
Valeur
conteneurs ? par
défaut
client
client hwtype Oui
hwaddr
NONE
Aucune
Spécifie un conteneur client qui
empêche le client indiqué par
hwaddr et hwtype d’obtenir une
adresse. Si hwtype est 0, alors
hwaddr est une chaîne ASCII.
Sinon, hwtype correspond au type
de matériel du client et hwaddr à
l’adresse du matériel du client. Si
hwaddr est une chaîne,, des
guillemets peuvent encadrer la
chaîne. Si hwaddr est une chaîne
hexadécimale, l’adresse peut être
spécifiée sous la forme 0xhexdigits
ou hex digits. range permet au
client
li t spécifié
é ifié par hwaddr
h dd ett hwtype
h t
d’obtenir une adresse faisant partie
de cette plage. Pour faire référence
à plusieurs clients, il faut utiliser
une expression régulière.
Aucune
Spécifie un conteneur classe
portant le nom string. La chaîne
peut ou non être placée entre
guillemets. Si oui, les guillemets
sont supprimés avant la
comparaison. Les guillemets sont
obligatoires si la chaîne contient
des espaces
ou des tabulations. Ce
p
conteneur est autorisé à tous les
niveaux. Il est possible d’indiquer
une plage pour spécifier le jeu
d’adresses à proposer au client
avec cette classe. La plage est soit
une adresse IP en format de
”dotted quad”, soit deux adresses
IP en format de ”dotted quad”
séparées par un tiret.
client hwtype
hwaddr ANY
client hwtype
hwaddr
dotted_quad
client hwtype
hwaddr
range
class
class string
class string
range
Oui
Signification
Protocole TCP/IP
4-181
Mot–clé
Forme
Sous–
Valeur
conteneurs ? par
défaut
Signification
réseau
network
network id
netmask
Oui
Spécifie un ID de réseau à l’aide
des informations de classe (par
exemple 9.3.149.0 avec un masque
de réseau de 255.255.255.0
correspond au réseau 9.0.0.0
255.255.255.0). Cette version du
conteneur de réseau est utilisée
sous–réseaux
pour englober les sous
réseaux
partageant le même masque et le
même ID de réseau. Lorsqu’une
plage est fournie, toutes les
adresses de la plage font partie du
pool. La plage doit être comprise
dans le réseau de l’ID de réseau.
Elle fait appel à l’adresse
l adresse intégrale
de la classe. Elle n’est valide qu’au
niveau général ou au niveau du
conteneur de base de données.
Aucune
network
network id
network
network id
range
Remarque: Le mot–clé network
est déconseillé au
profit du conteneur de
sous–réseau.
vendor
vendor
vendor_id
Oui
Aucune
vendor
vendor_id
hex””
vendor
vendor_id
hex ””
vendor
vendor_id
0xdata
vendor
vendor_id ””
vendor
vendor_id
range
vendor
vendor_id
range hex””
vendor
vendor_id
range hex ””
vendor
vendor_id
range 0xdata
vendor
vendor_id
range ””
4-182
Guide de gestion du système – Communications et réseaux
Spécifie un conteneur de
fournisseur. Les conteneurs
f
i
tili é pour
fournisseur
sontt utilisés
retourner l’option 43 au client.
L’id de fournisseur peut être
spécifié sous la forme d’une chaîne
entre guillemets ou d’une chaîne
binaire du type 0xhexdigits ou
hex”digits”.
hex
digits . Il est possible d’ajouter
d ajouter
à l’id de fournisseur une plage
facultative, en utilisant deux ”dotted
quad” séparés par un tiret. A la
suite de la plage facultative
facultative, une
chaîne hexadécimale ou ASCII
également facultative peut être
indiquée comme première partie de
l’option 43. Si des options figurent
dans le conteneur,, elles sont
annexées aux données de
l’option 43. Une fois toutes les
options traitées, une option End Of
Option List (fin de la liste d’options)
est ajoutée aux données. Pour
retourner les options en dehors
d’une
d
une option 43, utilisez une
expression régulière correspondant
à tous les clients pour spécifier les
p
y en
options
normales à renvoyer
fonction
de l’ID ffournisseur.
f
i d
i
Mot–clé
Forme
Sous–
Valeur
conteneurs ? par
défaut
Signification
inoption
inoption
number
option_data
Oui
Indique un conteneur à rapprocher
d’une option entrante arbitraire
définie par le client. number indique
le numéro de l’option. option_data
définit la clé correspondant au
conteneur à sélectionner lors du
choix de l’adresse et de l’option
pour ce client. La clé option_data
se présente sous forme de chaîne
entre guillemets, d’adresse IP ou
de nombre entier pour les options
connues mais peut également se
présenter sous forme de chaîne
hexadécimale d’octets si elle est
précédée des caractères 0x. Pour
les options que le serveur connaît
mal, il est possible de définir une
chaîne hexadécimale d’octets sur le
même schéma. En outre, la valeur
option_data peut faire référence à
une expression régulière à
rapprocher de la représentation en
chaîne des données d’option du
client. Ces expressions régulières
se présentent sous la forme d’une
chaîne entre guillemets (dont le
premier caractère est un point
d’exclamation ”!). Les options peu
connues du serveur se présentent
sous forme de chaîne
hexadécimale d’octets NON
précédée des caractères 0x.
inoption
number
option_data
range
Aucune
Protocole TCP/IP
4-183
Mot–clé
Forme
Sous–
Valeur
conteneurs ? par
défaut
Signification
virtual
virtual fill id
id ...
Non
Aucune
Spécifie un sous–réseau virtuel
avec une politique. fill signifie
utiliser toutes les adresses de ce
conteneur avant de passer au
suivant. rotate signifie
sélectionner une adresse du pool
suivant de la liste sur chaque
requête. sfill et srotate sont
identiques à fill et rotate, mais
une recherche est effectuée pour
savoir si le client correspond aux
conteneurs,, aux fournisseurs ou
aux classes du sous–réseau. Si
une correspondance permet
d’obtenir une adresse, cette
adresse est adoptée à partir du
conteneur au lieu de suivre la
politique indiquée. Il peut y avoir
autant
t t d’ID que nécessaire.
é
i id estt
soit l’ID de sous–réseau de la
définition de sous–réseau, soit le
label de cette même définition. Le
label est nécessaire si plusieurs
sous–réseaux partagent le même
ID de sous–réseau.
virtual sfill id
id ...
virtual rotate
id id ...
virtual
srotate id id
...
4-184
inorder:
inorder: id id
...
Non
Aucune
Spécifie un sous–réseau virtuel
avec une politique de remplissage,
ce qui signifie utiliser toutes les
adresses de ce conteneur avant de
passer au conteneur suivant. Il peut
y avoir autant d’ID que nécessaire.
id est soit l’ID de sous–réseau de la
définition de sous–réseau, soit le
label de cette même définition. Le
label est nécessaire si plusieurs
sous–réseaux partagent le même
ID de sous–réseau.
balance:
balance: id
id ...
Non
Aucune
Spécifie un sous–réseau virtuel
avec une politique de rotation,
ce qui signifie utiliser l’adresse
suivante du conteneur suivant.
Il peut y avoir autant d’ID que
nécessaire. id est soit l’ID de
sous–réseau de la définition de
sous–réseau, soit le label de cette
même définition. Le label est
nécessaire si plusieurs
sous–réseaux partagent le même
ID de sous–réseau.
Guide de gestion du système – Communications et réseaux
Mot–clé
Forme
Sous–
Valeur
conteneurs ? par
défaut
Signification
Non
Aucune
Indique le serveur que les clients
doivent utiliser comme point de
départ vers les fichiers TFTP à
l’issue de la réception de paquets
BOOTP ou DHCP. Cette valeur
complète le champ siaddr du
paquet. Cette option est valide à
tous les niveaux de conteneur.
giaddrfield IP Non
address
Aucune
Définit le champ giaddrfield pour
les paquets de réponse.
bootstrap bootstrapser
server
ver IP
address
giaddr
field
Remarque : Cette spécification
n’est pas autorisée pour les
protocoles BOOTP et DHCP, mais
certains clients exigent le champ
giaddr comme passerelle par
défaut pour le réseau. En raison de
ce risque de conflit, il est conseillé
de n’utiliser giaddrfield qu’au sein
d’un conteneur client, bien que
l’option fonctionne à tous les
niveaux.
bootfile
bootfile path
Non
Aucune
Indique le fichier de démarrage à
utiliser dans la section fichier du
paquet de réponse. Cette option
peut être définie à tous les niveaux
de conteneur. La politique bootfile
définit comment les éléments
spécifiés dans la section fichier du
paquet entrant se conjuguent avec
les instructions du fichier de
démarrage et du répertoire
personnel.
pxeboot
file
pxebootfile
Non
System Arch
MajorVer
MinorVer
Bootfilename
Aucune
Indique le fichier de démarrage à
donner à un client. L’analyseur du
fichier de configuration génère une
erreur si le nombre de paramètres
après le mot–clé est inférieur à
quatre, et il ignore les paramètres
supplémentaires. Ce mot–clé ne
peut être utilisé que dans un
conteneur.
Pour plus d’informations sur les autres options, reportez–vous à la section Options connues
du fichier du serveur DHCP, page 4-109.
Protocole TCP/IP
4-185
Démon BINLD (Boot Image Negotiation Layer Daemon)
Le serveur BINLD constitue le troisième contact des clients PXE. Après avoir communiqué
avec le serveur DHCP pour obtenir une adresse IP, et avec le serveur DHCP proxy PHE
pour connaître la localisation du serveur de démarrage, ce dernier est contacté afin
d’obtenir le chemin d’accès à partir duquel télécharger l’image de démarrage. Le client PXE
peut revenir communiquer plusieurs fois avec le serveur de démarrage au cours de
l’initialisation s’il a besoin de plusieurs fichiers pour son processus de démarrage.
La dernière étape du démarrage du réseau PXE est le téléchargement de l’image de
démarrage fournie par le serveur de démarrage. La localisation du serveur TFTP et le nom
du fichier qui doit être téléchargé sont donnés par le serveur de démarrage au client PXE.
Le serveur BINLD
A partir de la mise à jour version 4.3.3, le serveur BINLD est segmenté en trois composants
principaux : une base de données, un moteur de protocole et un ensemble de routines de
service, chaque élément disposant de ses propres informations de configuration.
La base de données BINLD
La base de données db_file.dhcpo est utilisée pour générer les options qui répondent à un
paquet REQUEST d’un client. Les options renvoyées par la base de données dépendent du
type de serveur choisi. Les options sont définies à l’aide du mot–clé pxeservertype dans le
fichier binld.cnf.
A partir des informations du fichier de configuration, la base de données est amorcée et sa
cohérence est vérifiée.
Le moteur de protocole BINLD
Le moteur de protocole PXED est basé sur Preboot Execution Environment (PXE)
Specification Version 2.1 d’Intel, mais il reste compatible avec PXE Specification Version
1.1. Le moteur de protocole utilise la base de donnés pour déterminer quelles informations
doivent être retournées au client.
Opérations BINLD enchaînées
Le dernier élément du serveur BINLD est en fait un ensemble d’opérations qui permettent
d’assurer la continuité de l’exécution. Comme le serveur BINLD est du type enchaîné, ces
opérations sont définies sous la forme de routines qui interviennent occasionnellement pour
s’assurer du bon déroulement de l’exécution.
La première routine, ou routine principale, gère les requêtes SRC (par exemple startsrc,
stopsrc, lssrc, traceson et refresh). Cette routine coordonne également toutes les
opérations qui affectent toutes les routines et gère les signaux. Par exemple :
• A SIGHUP (–1) provoque un rafraîchissement de toutes les bases de données du fichier
de configuration.
• A SIGTERM (–15) entraîne l’arrêt en douceur du serveur.
L’autre routine traite les paquets. Selon le type du serveur, une ou deux routines sont
utilisées. L’une d’entre elles écoute le port 67 et la deuxième le port 4011. Chacune peut
traiter une requête d’un client.
4-186
Guide de gestion du système – Communications et réseaux
Configuration de BINLD
Par défaut, la configuration du serveur BINLD est effectuée par la lecture du fichier
/etc/binld.cnf, qui spécifie la base de données initiale d’adresses et d’options du serveur.
Le serveur est démarré à partir de Web-based System Manager, de SMIT ou via les
commandes SRC.
La configuration de BINLD constitue la tâche la plus délicate dans le cadre de l’utilisation de
BINLD sur votre réseau. Vous devez d’abord déterminer le nombre de réseaux qui devront
accueillir des clients PXE. L’exemple suivant configure un serveur BINLD exécuté sur la
même machine que le serveur DHCP :
pxeservertype
binld_on_dhcp_server
subnet default
{
vendor pxe
{
bootstrapserver 9.3.149.6
#TFTP server IP address
pxebootfile
1
2
1
window.one
1
0
pxebootfile
2
2
1
linux.one
2
3
pxebootfile
1
2
1
hello.one
3
4
client 6 10005a8ad14d any
{
pxebootfile
1
2
1
aix.one
5
6
pxebootfile
2
2
1
window.one 6
7
}
}
}
Dans la configuration ci–dessus, le serveur BINLD écoute les paquets uni–diffusés d’un
client sur le port 4011 et les paquets multi–diffusés sur ce même port si BINLD obtient
l’adresse de multi–diffusion de dhcpsd/pxed. Le serveur BINLD répond aux paquets
REQUEST/INFORM du client avec le nom du fichier de démarrage et l’adresse IP du
serveur TFTP. Si BINLD ne trouve pas le fichier de démarrage avec une couche
correspondante spécifiée par le client, il tente ensuite de trouver un fichier de démarrage
pour la couche suivante. BINLD ne répond pas lorsqu’aucun fichier de démarrage ne
correspond aux requêtes du client (Type, SystemArch, MajorVers, MinorVers et Layer).
L’exemple ci–dessous configure BINLD pour une exécution sur une machine à part (DHCP
et PXED ne sont pas exécutés sur la même machine).
subnet 9.3.149.0 255.255.255.0
{
vendor pxe
{
bootstrapserver
9.3.149.6
# Adresse IP du serveur TFTP.
pxebootfile
1
2
1
window.one
1
0
pxebootfile
2
2
1
linux.one
2
3
pxebootfile
1
2
1
hello.one
3
4
client 6 10005a8ad14d any
{
pxebootfile
1
2
1
aix.one
5
6
pxebootfile
2
2
1
window.one
6
7
}
}
}
Dans l’exemple ci–dessus, pxeservertype n’est pas défini, le type de serveur par défaut est
donc binld_only. Le serveur BINLD écoute les paquets uni–diffusés d’un client sur le port
4011, les paquets diffusés et uni–diffusés sur le port 67 et les paquets multi–diffusés sur le
port 4011 si BINLD obtient l’adresse de multi–diffusion de dhcpsd/pxed. Le nom du fichier
de démarrage et l’adresse IP du serveur TFTP ne sont envoyés à un client PXE que si son
adresse IP figure dans la plage d’adresses IP du sous–réseau (de 9.3.149.0 à 9.3.149.255).
Protocole TCP/IP
4-187
L’exemple suivant configure BINLD pour une exécution sur la même machine que le
serveur PXED :
pxeservertype
binld_on_proxy_server
subnet default
{
vendor
{
bootstrapserver
9.3.149.6
# Adresse IP du serveur TFTP.
pxebootfile
1
2
1
window.one
1
0
pxebootfile
2
2
1
linux.one
2
3
pxebootfile
1
2
1
hello.one
3
4
client 6 10005a8ad14d any
{
pxebootfile
1
2
1
aix.one
5
6
pxebootfile
2
2
1
window.one 6
7
}
}
}
Dans cette configuration, le serveur BINLD n’écoute les paquets multi–diffusés sur le port
4011 que si BINLD obtient une adresse de multi–diffusion de dhcpsd/pxed. S’il ne reçoit pas
d’adresse de multidiffusion, BINLD est fermé et un message d’erreur est enregistré dans le
fichier journal.
La clause de base de données db_file indique la méthode à utiliser pour le traitement de
cette portion du fichier de configuration. Les commentaires sont introduits par le symbole #.
Tout le texte placé entre le # et la fin de la ligne est ignoré par le serveur PXED. Chaque
ligne d’option est utilisée par le serveur pour indiquer au client ce qu’il doit faire. La
section Sous–options du conteneur fournisseur PXE page 4-175 décrit les sous–options
reconnues et prises en charge à l’heure actuelle. Pour savoir comment définir des options
inconnues du serveur, reportez–vous à la section Syntaxe du fichier de serveur BINLD
pour le fonctionnement général du serveur, page 4-191.
Le fichier de configuration
Le fichier de configuration comprend une section d’adresses et une section de définition
d’options, basées sur le concept des conteneurs, qui renferment les options, les
modificateurs et, le cas échéant, d’autres conteneurs.
Un conteneur (qui est finalement une méthode de regroupement des options) fait appel à un
identificateur pour classer les clients en plusieurs groupes. Les types de conteneur sont le
sous–réseau, la classe, le fournisseur et le client. A l’heure actuelle, il n’existe pas de
conteneur générique définissable par l’utilisateur. L’Identificateur définit le client de manière
unique, de sorte qu’il soit possible de suivre sa trace même s’il est déplacé vers un autre
sous–réseau. Il est possible d’utiliser plusieurs types de conteneur pour définir les droits
d’accès du client.
Les options sont les identificateurs qui sont retournés au client, par exemple la passerelle
par défaut et l’adresse de DNS.
Conteneurs
Lorsque le serveur DHCP reçoit une requête, le paquet est analysé et les clés
d’identification permettent de déterminer les conteneurs, les options et les adresses à
extraire.
L’exemple précédent présente un conteneur de sous–réseau. La clé d’identification est la
position du client au sein du réseau. Si le client fait partie de ce réseau, alors il est intégré
à ce conteneur.
4-188
Guide de gestion du système – Communications et réseaux
Chaque type de conteneur utilise une option différente pour identifier les clients :
• Le conteneur sous–réseau utilise le champ giaddr ou l’adresse de l’interface réceptrice
pour déterminer le sous–réseau d’origine du client.
• Le conteneur classe utilise la valeur de l’option 77
(User Site Class Identifier – identificateur de la classe du site utilisateur).
• Le conteneur fournisseur utilise la valeur de l’option 60
(Vendor Class Identifier – identificateur de la classe du fournisseur).
• Le conteneur client utilise la valeur de l’option 61 (Client Identifier – identificateur du
client) pour les clients PXED et le champ chaddr du paquet BOOTP pour les clients
BOOTP.
Sauf pour les sous–réseaux, chaque conteneur accepte la spécification de la valeur de
correspondance à l’aide d’expressions régulières.
A ces conteneurs, il faut ajouter un conteneur implicite, le conteneur global. Sauf
spécification contraire ou refus explicite, les options et modificateurs placés dans le
conteneur global s’appliquent à tous les conteneurs. La plupart des conteneurs peuvent être
inclus dans d’autres conteneurs, ce qui implique une certaine visibilité. Les conteneurs
peuvent ou non être associés à des plages d’adresses. Tel est le cas, par nature, des
sous–réseaux.
Les règles de base s’appliquant aux conteneurs et sous–conteneurs sont les suivantes :
• Tous les conteneurs sont valides au niveau général.
• Les sous–réseaux ne doivent jamais être inclus dans d’autres conteneurs.
• Des conteneurs restreints ne peuvent englober des conteneurs réguliers du même type.
(Par exemple, un conteneur doté d’une option autorisant uniquement la classe
Comptabilité ne peut receler un conteneur doté d’une option autorisant toutes les
classes commençant par la lettre ”c”. Ceci n’est pas autorisé.)
• Les conteneurs client restreints ne peuvent englober de sous–conteneurs. En tenant
compte des règles ci–dessus, vous pouvez générer une hiérarchie de conteneurs qui
répartissent les options en différents groupes pour des clients ou des ensembles de
clients spécifiques.
Comment sont gérées les options et adresses lorsqu’un client correspond à plusieurs
conteneurs ? Le serveur DHCP reçoit les messages, il transmet la requête à la base de
données (fichier db_file en l’occurrence) et une liste de conteneurs est générée. La liste est
organisée par ordre de profondeur et de priorité. La priorité se définit comme une hiérarchie
implicite au sein des conteneurs. Les conteneurs stricts ont une priorité supérieure à celle
des conteneurs réguliers. Les clients, les classes, les fournisseurs et enfin, les
sous–réseaux sont triés, dans cet ordre, et à l’intérieur de chaque conteneur en fonction de
leur profondeur. Ceci aboutit à une liste allant du plus spécifique au moins spécifique. Par
exemple :
Sous–réseau 1
––Classe 1
––Client 1
Sous–réseau 2
––Classe 1
––––Fournisseur 1
––––Client 1
––Client 1
Protocole TCP/IP
4-189
Cet exemple présente deux sous–réseaux, Sous–réseau 1 et Sous–réseau 2. Il y a un
nom de classe, Classe 1, un nom de fournisseur, Fournisseur 1 et un nom de client,
Client 1. Classe 1 et Client 1 sont définis en plusieurs endroits. Comme ils résident
dans des conteneurs différents, leurs noms peuvent être identique mais leurs valeurs,
différentes. Si Client 1 envoie un message au serveur DHCP depuis Sous–réseau 1
avec Classe 1 spécifiée dans sa liste d’options, le serveur DHCP va générer le chemin
de conteneur suivant :
Sous–réseau 1, Classe 1, Client 1
Le conteneur le plus spécifique apparaît en dernier. Pour obtenir une adresse, la liste est
étudiée dans l’ordre inverse de la hiérarchie et la première adresse disponible est retenue.
Ensuite, l’étude de la liste de poursuit en remontant dans la hiérarchie afin d’obtenir les
options. Les options peuvent remplacer des valeurs précédentes, sauf si une option deny a
été incluse dans le conteneur. Par ailleurs, puisque Classe 1 et Client 1 figurent dans
Sous–réseau 1, ils sont ordonnés en fonction de la priorité de leur conteneur. Si le même
client se trouve dans Sous–réseau 2 et envoie le même message, la liste de conteneur
générée sera :
Sous–réseau 2, Classe 1, Client 1 (au niveau de Sous–réseau 2),
Client 1 (au niveau de Classe 1)
Sous–réseau 2 apparaît en premier, suivi de Classe 1, puis de Client 1 au niveau de
Sous–réseau 2 (car cette instruction client ne se trouve qu’à un niveau en dessous dans
la hiérarchie). Cette hiérarchie implique qu’un client correspondant à la première instruction
client est moins spécifique que le client correspondant à Client 1 de Classe 1 au sein
de Sous–réseau 2.
La priorité sélectionnée en fonction de la profondeur dans la hiérarchie prend le pas sur la
priorité des conteneurs eux–mêmes. Par exemple, si le même client émet le même
message, en précisant cette fois un identificateur de fournisseur, la liste de conteneur
devient :
Sous–réseau 2, Classe 1, Fournisseur 1, Client 1
(au niveau de Sous–réseau 2), Client 1 (au niveau de Classe 1)
La priorité au niveau des conteneurs améliore les performances en matière de recherche
car elle correspond à un concept général selon lequel les conteneurs client constituent le
moyen le plus spécifique de définir un ou plusieurs clients. Le conteneur client contient des
adresses plus spécifiques qu’un conteneur classe, lui–même plus spécifique qu’un
conteneur fournisseur, le conteneur sous–réseau étant le moins spécifique de tous.
Adresses et plages d’adresses
Les plages d’adresses, obligatoires pour les conteneurs sous–réseau, peuvent être
associées à tout type de conteneur. Chaque plage définie pour un conteneur doit être un
sous–ensemble de la plage du conteneur parent et ne doit pas présenter de
chevauchement avec la plage d’un autre conteneur. Par exemple, si une classe définie
dans un sous–réseau est associée à une plage d’adresses, cette plage doit constituer un
sous–ensemble des adresses de la plage du sous–réseau. En outre, le conteneur de la
classe ne doit pas recouvrir, même partiellement, d’autres plages d’adresses au même
niveau.
Les plages peuvent être définies sur la ligne du conteneur et modifiées au moyen
d’instructions de plages et d’exclusion afin que des jeux d’adresse non contigus puissent
être associés à un conteneur. Ainsi, si les dix premières adresses d’un sous–réseau sont
disponibles, ainsi que les dix suivantes, le sous–réseau peut spécifier ces adresses par
plage dans la clause de sous–réseau afin de réduire l’utilisation de la mémoire et les
risques de collision d’adresses avec d’autres clients ne se trouvant pas dans les plages
spécifiées.
4-190
Guide de gestion du système – Communications et réseaux
Dès qu’une adresse est sélectionnée, tout conteneur suivant dans la liste contenant les
plages d’adresses est retiré de la liste, avec ses enfants. La raison en est que les options
spécifiques au réseau dans les conteneurs supprimés ne sont pas valides si l’adresse n’est
pas utilisée à partir de ce conteneur.
Options
Une fois la liste ponctionnée pour déterminer les adresses, un ensemble d’options est
généré pour le client. Lors de ce processus de sélection, les nouvelles options remplacent
les options précédemment sélectionnées, sauf si une clause deny est rencontrée, auquel
cas l’option refusée est retirée de la liste envoyée au client. Cette méthode autorise les
héritages à partir des conteneurs parents afin de réduire la quantité de données à spécifier.
Journalisation
Les paramètres de journalisation sont précisés dans un conteneur tel que la base de
données, mais le mot de passe du conteneur est : logging_info. Au démarrage, il est
conseillé d’activer le niveau de journalisation le plus élevé. En outre, il est préférable de
configurer cette fonction préalablement à toute autre afin que les erreurs de configuration
puissent être consignées après initialisation du sous–système de journalisation. Le mot–clé
logitem active le niveau de journalisation ; si vous supprimez logitem, le niveau de
journalisation sera désactivé. Les autres mots–clé concernant la journalisation permettent
d’indiquer le nom du fichier journal, sa taille et le nombre de journaux utilisés en alternance.
Considérations de performance
Vous n’êtes pas sans savoir que certains mots–clés de configuration ainsi que la structure
du fichier de configuration ont une incidence sur l’utilisation de la mémoire et les
performances du serveur PXED.
Premièrement, il est possible d’éviter toute sollicitation excessive de la mémoire en
appréhendant le modèle d’héritage des options des conteneurs parents vers les conteneurs
enfants. Dans un environnement qui ne prend pas en charge les clients non répertoriés,
l’administrateur doit expressément lister chaque client du fichier. Lorsque des options sont
répertoriées pour chaque client en particulier, le serveur sollicite plus de capacité mémoire
pour stocker cette structure de configuration arborescente que lorsque des options sont
héritées d’un conteneur parent (conteneurs de sous–réseau, de réseau ou conteneurs
globaux, par exemple). Par conséquent, l’administrateur doit vérifier la répétition ou non des
options relatives au client au sein du fichier de configuration. Si tel est le cas, il doit décider
si ces options peuvent ou non être définies dans le conteneur parent et partagées par
l’ensemble des clients.
Deuxièmement, l’utilisation des entrées logItem INFO et TRACE entraîne la consignation
de nombreux messages au cours du traitement de chaque message du client PXE. L’ajout
d’une ligne au journal peut s’avérer une opération onéreuse. C’est pourquoi la limitation du
volume de journalisation améliore les performances du serveur PXED. En cas de
présomption d’erreur sur le serveur PXED, la journalisation peut être dynamiquement
réactivée à l’aide de la commande SRC traceson.
Syntaxe du fichier de serveur BINLD pour le fonctionnement
général du serveur
Remarque :
Les unités de temps (time_units) indiquées dans le tableau suivant sont
facultatives et correspondent à un modificateur du temps réel. L’unité de
temps par défaut est exprimée en minutes. Les valeurs autorisées sont
les secondes (1), les minutes (60), les heures (3600), les jours (86400),
les semaines (604800), les mois (2392000) et les années (31536000).
Le nombre entre parenthèses est un multiplicateur appliqué à la valeur n
spécifiée pour exprimer cette valeur en secondes.
Protocole TCP/IP
4-191
Mot–clé
Forme
Sous–
conte–
neurs
Valeur
par
défaut
database
database db type
Oui
Aucune Conteneur principal renfermant les
définitions des pools d’adresses,
options et instructions d’accès
client. db type est le nom du
module chargé pour traiter cette
portion du fichier. La seule valeur
actuellement disponible est db_file.
logging_info
logging_info
Oui
Aucune Conteneur de journalisation
principal définissant les paramètres
de journalisation.
logitem
logitem NONE
Non
Non
activé
ti é
pour
tous
par
défaut
défaut.
Active le niveau de journalisation.
Pl i
Plusieurs
lignes
li
sontt autorisées.
t i é
logitem SYSERR
logitem OBJERR
logitem PROTOCOL
logitem PROTERR
Signification
logitem WARN
logitem WARNING
logitem CONFIG
logitem EVENT
logitem PARSEERR
logitem ACTION
logitem ACNTING
logitem STAT
logitem TRACE
logitem RTRACE
logitem START
4-192
numLogFiles
numLogFiles n
Non
0
Indique le nombre de fichiers
journaux à créer. Les journaux
alternent lorsque le premier journal
est rempli. n est le nombre de
journaux à créer.
logFileSize
logFileSize n
Non
0
Indique la taille de chaque fichier
journal, exprimée en unités de
1024 octets.
Guide de gestion du système – Communications et réseaux
Mot–clé
Forme
Sous–
conte–
neurs
Valeur
par
défaut
logFileName
logFileName path
Non
Aucune Indique le chemin d’accès au
premier fichier journal. Le nom
d’origine du fichier journal est
nomfichier ou nomfichier.extension.
Lorsque la permutation des fichiers
est effectuée, le premier fichier est
renommé en conservant la base du
nom, nomfichier, et en lui ajoutant
un numéro, ou en remplaçant
l’extension par un numéro. Par
exemple, si le nom original du
fichier est file, le nom du fichier
après permutation devient file01.
Si le nom du fichier d’origine est
file.log, il devient file.01.
pxeservertype pxeservertype
servertype
Non
dhcp_o
nly
dhcp_or_prox
y _address
Non
Aucune Ce mot–clé fournit l’adresse IP du
serveur dhcp ou pxed auquel le
serveur BINLD peut envoyer un
paquet uni–diffusé de type
REQUEST/INFORM pour recevoir
l’adresse de multi–diffusion. Ce
mot–clé n’est défini que lorsque le
serveur dhcp ou pxed est exécuté
sur un sous–réseau différent de
BINLD.
dhcp_or_proxy_addre
ss IP address
Signification
Indique le type de serveur dhcpsd.
servertype peut avoir l’une des
valeurs suivantes :
binld_on_dhcp_server Cela
signifie que BINLD est exécuté sur
la même machine que le serveur
DHCP, qu’il écoute les requêtes
client PXE sur le port 4011 et
l’adresse de multi–diffusion si
celle–ci est reçue du serveur DHCP
/ PXED. binld_on_proxy_server
Cela signifie que BINLD est
exécuté sur la même machine que
le serveur PXED et écoute les
requêtes client PXE sur l’adresse
de multi–diffusion si celle–ci est
reçue du serveur DHCP / PXED. La
valeur par défaut est binld_only :
le serveur BINLD est exécuté sur
une machine à part et doit écouter
les paquets du client sur les ports
67 et 4011 et sur l’adresse de
multidiffusion si celle–ci est reçue
du serveur DHCP / PXED.
Protocole TCP/IP
4-193
Syntaxe du fichier de serveur BINLD pour le fonctionnement
général du serveur
Remarques :
1. Les unités de temps (time_units) indiquées dans le tableau suivant sont facultatives et
correspondent à un modificateur du temps réel. L’unité de temps par défaut est exprimée
en minutes. Les valeurs autorisées sont les secondes (1), les minutes (60), les heures
(3600), les jours (86400), les semaines (604800), les mois (2392000) et les années
(31536000). Le nombre entre parenthèses est un multiplicateur appliqué à la valeur n
spécifiée pour exprimer cette valeur en secondes.
2. Les éléments spécifiés dans un conteneur peuvent être remplacés par ceux d’un
sous–conteneur. Vous pouvez par exemple définir les clients BOOTP de manière
globale, et, au sein d’un sous–réseau donné, autoriser les clients BOOTP en indiquant le
mot–clé supportBootp dans les deux conteneurs.
3. Les conteneurs client, classe et fournisseur acceptent les expressions régulières. Pour la
classe et le vendeur, une chaîne entre guillemets dont le premier caractère à l’intérieur
des guillemets est un point d’exclamation (!) indique que le reste de la chaîne doit être
considéré comme une expression régulière. Le conteneur client accepte les expressions
régulières dans les champs hwtype et hwaddr. Une chaîne unique est utilisée pour
représenter les deux champs, selon la syntaxe suivante :
nombre_décimal–données
Si nombre_décimal est égal à zéro, les données constituent une chaîne ASCII. Pour tout
autre nombre, les données sont des chiffres hexadécimaux.
Mot–clé
Forme
Sous–
conte–
neurs
Valeur
par
défaut
Signification
subnet
subnet default
Oui
Aucune
Spécifie un sous–réseau sans plage
associée. Ce sous–réseau est utilisé par
un serveur uniquement pour répondre à un
paquet INFORM d’un client et si aucun
conteneur de sous–réseau ne correspond
à l’adresse de ce dernier.
subnet
subnet subnet
id netmask
Oui
Aucune
Spécifie un sous–réseau et un pool
d’adresses. Toutes les adresses sont
supposées
faire p
partie du p
pool, sauf si une
pp
l
é ifié sur lla liligne ou sii lles
plage
est spécifiée
adresses sont modifiées ultérieurement
dans le conteneur par une instruction de
plage ou d’exclusion. La plage facultative
est une paire d’adresses IP en format de
”dotted quad” séparées par un tiret. Il est
possible de préciser un label et une
priorité. Ceux–ci sont utilisés dans les
sous–réseaux
sous réseaux virtuels pour identifier et
classer les sous–réseaux du sous–réseau
virtuel. Le label et la priorité sont séparés
par un signe deux–points. Ces conteneurs
ne sont autorisés qu’au niveau global ou
au niveau du conteneur base de données.
subnet subnet
id netmask
range
subnet subnet
id netmask
label:priority
subnet subnet
id netmask
range
label:priority
4-194
Guide de gestion du système – Communications et réseaux
Mot–clé
Forme
Sous–
conte–
neurs
Valeur
par
défaut
Signification
subnet
subnet subnet
id range
Oui
Aucune
Spécifie un sous–réseau qui s’inscrit dans
un conteneur réseau. Il définit une plage
d’adresses formant la totalité du
sous–réseau, sauf si la plage facultative
est indiquée. Le masque de réseau
associé au sous–réseau est issu du
conteneur réseau environnant.
Remarque :
Cette méthode est déconseillée au
profit des autres formes de
sous–réseaux.
option
option number
data ...
Non
Aucune
Spécifie une option à envoyer à un client
ou, dans le cas d’un refus (deny), une
option qui ne doit pas être envoyée à un
client. La clause option * deny signifie
que toutes les options non spécifiées dans
le conteneur en cours ne doivent pas être
retournées au client. L’option numberdeny
ne refuse que l’option spécifiée. number
est un entier 8 bits non signé. data est
spécifique à l’option (voir ci–dessus) ou
peut être définie sous la forme d’une
g
(
chaîne entre guillemets
(texte
ASCII)) ou
0xhexdigits ou hex”hexdigits” ou encore
hex ”hexdigits”. Si l’option correspond à un
conteneur fournisseur, elle sera
encapsulée avec les autres options dans
une option 43.
Non
Aucune
Modifie la plage sur le conteneur qui
comporte l’instruction exclude. L’instruction
exclude n’est pas valide au niveau des
conteneurs de base de données ou au
général L’instruction exclude
niveau général.
supprime l’adresse ou la plage spécifiée de
la plage actuelle sur le conteneur. Elle
permet de créer des plages non contiguës
pour sous sous–réseaux ou d’autres
conteneurs.
option
numberdeny
option * deny
exclude
exclude an IP
address
exclude
dotted_quad–
dotted_quad
Protocole TCP/IP
4-195
Mot–clé
Forme
Sous–
conte–
neurs
Valeur
par
défaut
Signification
range
range
IP_address
Non
Aucune
Modifie la plage sur le conteneur qui
comporte l’instruction range. L’instruction
range n’est pas valide au niveau des
conteneurs de base de données ou au
niveau général. S’il s’agit de la première
plage du conteneur qui ne spécifie pas une
plage sur la ligne de définition du
conteneur, la plage du conteneur devient
alors la plage spécifiée par l’instruction
range. Toute instruction range suivante, ou
toutes les instructions range dans le cas
d’un conteneur spécifiant des plages dans
sa définition sont ajoutées à la page
actuelle. Avec l’instruction range, il est
possible d’ajouter à la plage existante une
adresse unique ou un jeu d’adresses. La
plage doit être incorporée dans la définition
du conteneur de sous–réseau.
Oui
Aucune
Spécifie un conteneur client qui empêche
le client indiqué par hwaddr et hwtype
d’obtenir une adresse. Si hwtype est 0,
alors hwaddr est une chaîne ASCII. Sinon,
hwtype correspond au type de matériel du
client et hwaddr à l’adresse du matériel du
client. Si hwaddr est une chaîne, des
guillemets peuvent encadrer la chaîne.
chaîne Si
hwaddr est une chaîne hexadécimale,
l’adresse peut être spécifiée sous la forme
0xhexdigits ou hex digits. range permet au
client spécifié par hwaddr et hwtype
d’obtenir une adresse faisant partie de
cette plage. Pour faire référence à
plusieurs clients, il faut utiliser une
expression régulière.
Oui
Aucune
Spécifie un conteneur classe portant le
nom string. La chaîne peut ou non être
placée entre guillemets. Si oui, les
guillemets sont supprimés avant la
comparaison. Les guillemets sont
obligatoires si la chaîne contient des
espaces ou des tabulations
tabulations. Ce conteneur
est autorisé à tous les niveaux. Il est
possible d’indiquer une plage pour
spécifier le jeu d’adresses à proposer au
client avec cette classe. La plage est soit
une adresse IP en format de ”dotted quad”,
soit deux adresses IP en format de ”dotted
quad” séparées par un tiret.
range
dotted_quad–
dotted_quad
client
client hwtype
hwaddr NONE
client hwtype
hwaddr ANY
client hwtype
hwaddr
dotted_quad
client hwtype
hwaddr range
class
class string
class string
range
4-196
Guide de gestion du système – Communications et réseaux
Mot–clé
Forme
Sous–
conte–
neurs
Valeur
par
défaut
Signification
réseau
network
network id
netmask
Oui
Aucune
Spécifie un ID de réseau à l’aide des
informations de classe (par exemple
9.3.149.0 avec un masque de réseau de
255.255.255.0 correspond au réseau
9.0.0.0 255.255.255.0). Cette version du
conteneur de réseau est utilisée pour
englober les sous–réseaux partageant le
même masque et le même ID de réseau.
Lorsqu’une plage est fournie, toutes les
adresses de la plage font partie du pool. La
plage doit être comprise dans le réseau de
l’ID de réseau. Elle fait appel
pp à l’adresse
i é l de
intégrale
d la
l classe.
l
Ell
Elle n’est
’
valide
lid
qu’au niveau général ou au niveau du
conteneur de base de données.
network
network id
network
network id
range
Remarque : Le mot–clé network est
déconseillé au profit du conteneur de
sous–réseau.
vendor
vendor
vendor_id
vendor
vendor_id hex””
vendor
vendor_id hex
””
vendor
vendor_id
0xdata
vendor
vendor_id ””
vendor
vendor_id
range
vendor
vendor_id
range hex””
vendor
vendor_id
range hex ””
vendor
vendor_id
range 0xdata
Oui
Aucune
Spécifie un conteneur de fournisseur. Les
conteneurs fournisseur sont utilisés pour
retourner
t
l’option
l’ ti 43 au client.
li t L’id d
de
fournisseur peut être spécifié sous la forme
d’une chaîne entre guillemets ou d’une
chaîne binaire du type 0xhexdigits ou
hex”digits”. Il est possible d’ajouter à l’id de
fournisseur une plage facultative, en
utilisant deux ”dotted quad” séparés par un
tiret. A la suite de la plage facultative, une
chaîne hexadécimale ou ASCII également
f
facultative
lt ti peutt êt
être iindiquée
di é comme
première partie de l’option 43. Si les
options figurent dans le conteneur,
conteneur elles
sont annexées aux données de l’option 43.
Une fois toutes les options traitées, une
option End Of Option List (fin de la liste
d’options) est ajoutée aux données. Pour
retourner les options en dehors d’une
option 43, utilisez une expression régulière
correspondant à tous les clients pour
spécifier les options normales à renvoyer
en fonction de l’ID fournisseur.
pxe après le mot–clé vendor crée un
conteneur fournisseur pour PXEClient.
pxeserver après le mot–clé vendor crée
un conteneur fournisseur p
pour PXEServer.
vendor
vendor_id
range ””
vendor pxe
vendor
pxeserver
Protocole TCP/IP
4-197
Mot–clé
Forme
Sous–
conte–
neurs
inoption
inoption number Oui
option_data
Valeur
par
défaut
Signification
Aucune
Indique un conteneur à rapprocher d’une
option entrante arbitraire définie par le
client. number indique le numéro de
l’option. option_data définit la clé
correspondant au conteneur à sélectionner
lors du choix de l’adresse et de l’option
pour ce client. La clé option_data se
présente sous forme de chaîne entre
guillemets, d’adresse IP ou de nombre
entier pour les options connues mais peut
également se présenter sous forme de
chaîne hexadécimale d’octets si elle est
précédée des caractères 0x. Pour les
p
options que le serveur connaît mal, il est
possible de définir une chaîne
hexadécimale d’octets sur le même
schéma. En outre, la valeur option_data
peut faire référence à une expression
régulière à rapprocher de la représentation
en chaîne des données d’option du client.
Ces expressions régulières se présentent
sous la forme d’une chaîne entre
guillemets (dont le premier caractère est
un point d’exclamation ”!). Les options
peu connues du serveur se présentent
sous forme de chaîne hexadécimale
d’octets NON précédée des caractères 0x.
Aucune
Spécifie un sous–réseau virtuel avec une
politique. fill signifie utiliser toutes les
adresses de ce conteneur avant de passer
au suivant. rotate signifie sélectionner
une adresse
d
d
du pooll suivant
i
td
de lla liliste
t sur
chaque requête. sfill et srotate sont
identiques à fill et rotate, mais une
recherche est effectuée pour savoir si le
client correspond aux conteneurs, aux
fournisseurs ou aux classes du
sous–réseau. Si une correspondance
permet d’obtenir une adresse, cette
adresse est adoptée à partir du conteneur
au lieu de suivre la politique indiquée. Il
d’ID
peut y avoir autant d
ID que nécessaire. id
est soit l’ID de sous–réseau de la définition
de sous–réseau, soit le label de cette
même définition. Le label est nécessaire si
plusieurs sous–réseaux partagent le même
ID de sous–réseau.
inoption number
option_data
range
virtual
virtual fill id id ... Non
virtual sfill id id
...
virtual rotate id
id ...
virtual srotate id
id ...
4-198
Guide de gestion du système – Communications et réseaux
Mot–clé
Forme
Sous–
conte–
neurs
Valeur
par
défaut
Signification
inorder:
inorder: id id ...
Non
Aucune
Spécifie un sous–réseau virtuel avec une
politique de remplissage, ce qui signifie
utiliser toutes les adresses de ce
conteneur avant de passer au conteneur
suivant. Il peut y avoir autant d’ID que
nécessaire. id est soit l’ID de sous–réseau
de la définition de sous–réseau, soit le
label de cette même définition. Le label est
nécessaire si plusieurs sous–réseaux
partagent le même ID de sous–réseau.
balance:
balance: id id ... Non
Aucune
Spécifie un sous–réseau virtuel avec une
politique de rotation, ce qui signifie utiliser
l’adresse suivante du conteneur suivant. Il
peut y avoir autant d’ID que nécessaire. id
est soit l’ID de sous–réseau de la définition
de sous–réseau, soit le label de cette
même définition. Le label est nécessaire si
plusieurs sous–réseaux partagent le même
ID de sous–réseau.
boots
trapserver
bootstrap
server IP
address
Non
Aucune
Indique le serveur que les clients doivent
utiliser comme point de départ vers les
fichiers TFTP à l’issue de la réception de
paquets BOOTP ou DHCP. Cette valeur
complète le champ siaddr du paquet.
Cette option est valide à tous les niveaux
de conteneur.
giaddrfield
giaddrfield IP
address
Non
Aucune
Définit le champ giaddrfield pour les
paquets de réponse.
Remarque : Cette spécification n’est pas
autorisée pour les protocoles BOOTP et
DHCP, mais certains clients exigent le
champ giaddr comme passerelle par
défaut pour le réseau. En raison de ce
risque de conflit, il est conseillé de
n’utiliser giaddrfield qu’au sein d’un
conteneur client, bien que l’option
fonctionne à tous les niveaux.
Protocole TCP/IP
4-199
Mot–clé
Forme
Sous–
conte–
neurs
Valeur
par
défaut
Signification
bootfile
bootfile path
Non
Aucune
Indique le fichier de démarrage à utiliser
dans la section fichier du paquet de
réponse. Cette option peut être définie à
tous les niveaux de conteneur. La politique
bootfile définit comment les éléments
spécifiés dans la section fichier du paquet
entrant se conjuguent avec les instructions
du fichier de démarrage et du répertoire
personnel.
Non
Aucune
Indique le fichier de démarrage à donner à
un PXEClient. L’analyseur du fichier de
configuration génère une erreur si le
nombre de paramètres après le mot–clé
est inférieur à 4 et les ignore s’il est
supérieur à 7. Si 4 paramètres sont
indiqués, il suppose les valeurs Type = 0 et
Layer = 0. Ce mot–clé ne peut être utilisé
que dans un conteneur.
pxebootfile pxebootfile
SystemArch
MajorVer
MinorVer
Bootfilename
Type Layer
Pour plus d’informations sur les autres options, reportez–vous aux sections Options
connues du fichier de serveur DHCP, page 4-109 et Sous–options du conteneur fournisseur
PXE, page 4-175.
4-200
Guide de gestion du système – Communications et réseaux
Démons TCP/IP
Les démons (ou serveurs) sont des process qui fonctionnent en continu, en arrière-plan,
pour exécuter des fonctions requises par d’autres process. TCP/IP fournit des démons pour
implémenter certaines fonctions sur le système. Leur exécution en arrière-plan n’interrompt
pas les autres processus (à moins qu’ils en soient chargés).
Les démons sont appelés par des commandes au niveau de la gestion système, par
d’autres démons ou scripts shell. Vous pouvez également les contrôler à l’aide du démon
inetd, du script shell rc.tcpip et du contrôleur SRC (System Resource Controller).
Sous-systèmes et sous-serveurs
Un sous-système est un démon ou serveur contrôlé par SRC. Un sous-serveur est un
démon contrôlé par un sous-système. (Les commandes et noms de démon sont
généralement suffixés par un d.) Sous–système et sous–serveurs sont deux catégories
opposées et incompatibles : un démon ne peut relever des deux catégories à la fois. Le
seul sous-système TCP/IP qui contrôle d’autres démons est inetd. Ainsi, tout sous-serveur
TCP/IP est également un sous-serveur inetd.
Les démons TCP/IP contrôlés par SRC sont :
Sous-systèmes
gated
Fournit des fonctions de routage de passerelle et prend en charge les
protocoles RIP (Routing Information Protocol ), RIPng (Routing
Information Protocol Next Generation), EGP (Exterior Gateway
Protocol), BGP (Border Gateway Protocol) et BGP4+, HELLO, OSPF
(Open Shortest Path First), IS–IS (Intermediate System to Intermediate
System), ICMP et ICMPv6 (Internet Control Message Protocol /Router
Discovery). Le démon gated prend également le protocole SNMP
(Simple Network Monitoring Protocol) en charge. Le démon gated est
l’un des deux démons de routage dédiés aux adresses de réseau.
Le démon gated est préféré au démon routed car il admet davantage
de protocoles de passerelle.
inetd
Appelle et planifie l’exécution d’autres démons à la réception des
demandes de services de démons. Ce démon peut aussi en lancer
d’autres. inetd est aussi appelé “ super démon ”.
iptrace
Suivi des paquets au niveau interface pour les protocoles Internet.
named
Fournit la fonction d’appellation au protocole de serveur de noms
DOMAIN.
routed
Gère les tables de routage de réseau et prend en charge le protocole
RIP (Routing Information Protocol). Le démon gated est préféré au
démon routed car il admet davantage de protocoles de passerelle.
rwhod
Diffuse des messages à l’ensemble des hôtes, toutes les trois minutes,
et stocke l’information relative aux utilisateurs connectés et à l’état du
réseau. Utilisez rwhod avec précaution car il monopolise une part
importante des ressources machine.
timed
Fournit la fonction serveur horaire.
Remarque :
Les démons routed et gated relèvent de la catégorie des sous-systèmes
TCP/IP. N’exécutez pas la commande startsrc –g tcpip, qui lance ces
deux démons de routage avec tous les autres sous-systèmes TCP/IP.
Ces deux démons lancés ensemble produiraient des résultats
imprévisibles.
Protocole TCP/IP
4-201
Les démons TCP/IP contrôlés par le sous-système inetd sont :
Sous-serveurs inetd
comsat
Avertit les utilisateurs de l’arrivée d’un courrier.
fingerd
Dresse un compte rendu concernant l’état de tous les utilisateurs
connectés et l’état du réseau sur l’hôte distant spécifié. Ce démon
utilise le protocole FINGER.
ftpd
Assure le transfert des fichiers pour un processus client en appliquant
le protocole FTP (File Transfer Protocol).
rexecd
Assure la fonction de serveur hôte étranger, pour la commande rexec.
rlogind
Effectue la connexion à distance pour la commande rlogin.
rshd
Effectue la fonction serveur d’exécution des commandes à distance
pour les commandes rcp et rsh.
talkd
Apport de la fonction conversation à la commande talk.
syslogd
Lecture et consignation des messages système. Ce démon appartient
au groupe de sous-systèmes Remote Access Service (RAS).
telnetd
Apport de la fonction serveur au protocole TELNET.
tftpd
Assure la fonction serveur pour le protocole TFTP
(Trivial File Transfer Protocol).
uucpd
Gère les communications entre BNU et TCP/IP.
Fonction SRC
Le contrôleur de ressources système (SRC) permet, entre autres, de lancer les démons,
les arrêter et suivre leurs activités. De plus, SRC permet de grouper des démons en
sous-systèmes et sous-serveurs.
Cet outil a été conçu pour aider l’administrateur système à contrôler les démons.
Ce contrôle s’effectue au-delà des indicateurs et paramètres disponibles pour chaque
commande de démon.
Pour en savoir plus sur SRC, reportez-vous à la section Contrôleur SRC dans AIX 5L
Version 5.3 System Management Concepts: Operating System and Devices.
Commandes SRC
Les commandes SRC sont applicables à un seul démon, à un groupe de démons ou à un
démon et à ceux qu’il contrôle (sous-système avec sous-serveurs). Par ailleurs, certains
démons TCP/IP ne répondent pas à toutes les commandes SRC. Voici la liste des
commandes SRC disponibles pour contrôler des démons TCP/IP et leurs exceptions.
4-202
startsrc
Démarre tous les sous-systèmes TCP/IP et sous-serveurs inetd,
sans exception. La commande startsrc fonctionne pour tous les
sous-systèmes TCP/IP et sous-serveurs inetd.
stopsrc
Arrête tous les sous-systèmes TCP/IP et sous-serveurs inetd,
sans exception. Cette commande s’appelle également stop normal.
La commande stop normal permet aux sous-systèmes de traiter
tout le travail en cours et d’y mettre fin en douceur. Pour les
sous–serveurs inetd, toutes les connexions en attente sont lancées
et celles en exécution, terminées. La commande stop normal
fonctionne pour tous les sous-systèmes TCP/IP et sous-serveurs
inetd.
Guide de gestion du système – Communications et réseaux
stopsrc –f
Arrête tous les sous-systèmes TCP/IP et sous-serveurs inetd,
sans exception. Cette commande s’appelle également stop normal.
La commande stop force arrête immédiatement tous les
sous–systèmes. Pour les sous-serveurs inetd, toutes les
connexions en cours ou en attente sont immédiatement terminées.
refresh
Rafraîchit les sous–systèmes et sous–serveurs suivants :
sous–systèmes inetd, syslogd, named, dhcpsd et gated.
lssrc
Fournit un bref compte rendu de l’état du sous–système spécifié
(actif ou non) et des sous–serveurs inetd. Fournit un bref compte
rendu d’état de inetd accompagné du nom, de l’état et de la
description du sous–serveur, du nom de la commande et des
arguments qui ont permis de le lancer.
lssrc –l
Fournit un bref compte rendu d’état accompagné d’informations
supplémentaires (état détaillé) sur les sous systèmes.
gated
Etat de la mise au point ou du suivi, protocoles
de routage activés, tables de routage, signaux
acceptés avec leur fonctions.
inetd
Etat de la mise au point, liste des sous-serveurs
actifs avec état succinct, signaux acceptés avec
leurs fonctions.
named
Etat de la mise au point, informations sur le fichier
named.conf.
dhcpsd
Etat de la mise au point, toutes les adresses IP
contrôlées et leur état actuel.
routed
Etat de la mise au point et du suivi, état des
informations de routage source, tables de routage.
syslogd
Données de configuration de syslogd.
La commande lssrc –l indique également l’état détaillé des
sous–serveurs inetd. L’état détaillé comprend un compte rendu et
des informations sur la connexion active. Certains sous–serveurs
fournissent des informations supplémentaires. Il s’agit de :
ftpd
Etat de la mise au point et de la journalisation.
telnetd
Type d’émulation de terminal.
rlogind
Etat de la mise au point.
fingerd
Etat de la mise au point et de la journalisation.
Les sous-serveurs rwhod et timed ne fournissent
pas d’état détaillé.
traceson
Active la mise au point au niveau socket. Utilisez la commande trpt
pour mettre la sortie en forme. Cette commande n’est pas prise en
charge par les sous-systèmes timed et iptraced.
tracesoff
Désactive la mise au point au niveau socket. Utilisez la commande
trpt pour mettre la sortie en forme. Cette commande n’est pas prise
en charge par les sous-systèmes timed et iptraced.
Pour des exemples d’utilisation, reportez-vous à la description de la commande qui vous
intéresse. Pour en savoir plus sur SRC, reportez-vous à la section Contrôleur SRC dans
AIX 5L Version 5.3 System Management Concepts: Operating System and Devices.
Protocole TCP/IP
4-203
Configuration du démon inetd
Pour configurer le démon inetd :
1. Définissez les sous-serveurs que le démon doit appeler en ajoutant un sous-serveur
inetd.
2. Définissez ses caractéristiques de relance, en modifiant les caractéristiques de relance
du démon inetd.
Configuration des tâches du démon inetd
Tâche
Raccourci
SMIT
Commande ou fichier
Web–based System
Manager Management
Environment
Démarrage du
démon inetd
smit mkinetd
startsrc –s inetd
Software ––> Network
––> TCPIP (IPv4 and
IPv6) ––> Subsystems.
Cliquez avec le bouton
droit de la souris sur un
sous–système inactif,
puis sélectionnez
Activate.
Modification des
smit chinetd ou
caractéristiques de smit lsinetd
relance du démon
inetd
4-204
Arrêt du démon
inetd
smit rminetd
Liste des
sous–serveurs
inetd
smit inetdconf
Ajout d’un
sous-serveur
inetd1
smit
mkinetdconf
Software ––> Network
––> TCPIP (IPv4 and
IPv6) ––> Subsystems
––> Selected ––>
Properties.
stopsrc –s inetd
Software ––> Network
––> TCPIP (IPv4 and
IPv6) ––> Subsystems.
Cliquez avec le bouton
droit de la souris sur un
sous–système actif,
puis sélectionnez ––>
Deactivate.
Software ––> Network
––> TCPIP (IPv4 and
IPv6) ––> Subsystems.
modifiez /etc/inetd.conf
puis exécutez refresh
–s inetd
ou tuez –1 inetdPID2
Guide de gestion du système – Communications et réseaux
Software ––> Network
––> TCPIP (IPv4 and
IPv6) ––> Subsystems
––> Subsystems
(menu déroulant) ––>
New inetd Subserver.
Tâche
Raccourci
SMIT
Commande ou fichier
Web–based System
Manager Management
Environment
Modification/Affich
age des
caractéristiques
d’un sous–serveur
inetd
smit inetdconf
modifiez /etc/inetd.conf
puis exécutez refresh
–s inetd
ou tuez –1 inetdPID2
Software ––> Network
––> TCPIP (IPv4 and
IPv6) ––> Subsystems
––> Selected ––>
Properties.
modifiez /etc/inetd.conf
puis exécutez refresh
–s inetd
ou tuez –1 inetdPID2
Software ––> Network
––> TCPIP (IPv4 and
IPv6) ––> Subsystems
––> Selected ––>
Deactivate.
Suppression d’un
smit rminetd
sous-serveur inetd
Remarques :
1. Ajouter un sous-serveur inetd revient à configurer le démon inetd pour qu’il puisse
appeler le sous-serveur lorsque nécessaire.
2. La commande refresh ou kill signale au démon inetd les modifications apportées à son
fichier de configuration.
Services réseau client
Les services réseau client (accessibles via le raccourci Web–based System Manager wsm
ou via le raccourci smit clientnet) sont les protocoles TCP/IP applicables sous ce système
d’exploitation. Chaque protocole ou service est identifié par le numéro de port qu’il utilise
sur le réseau, d’où l’expression port connu. Par commodité, ces numéros de port peuvent
être associés à des noms ou numéros. Par exemple, le protocole de messagerie TCP/IP
qui utilise le port 25 est connu sous le nom smtp. Si un protocole est déclaré (pas de
marque de commentaire) dans le fichier /etc/services, il peut être utilisé par un hôte.
Par défaut, tous les protocoles TCP/IP sont définis dans ce fichier /etc/services.
Vous n’avez donc pas besoin de configurer ce fichier. Cependant, si vous avez écrit vos
propres programmes client/serveur, vous pouvez être amené à les déclarer dans le fichier
/etc/services et à leur réserver un nom et un numéro de port. Si vous décidez d’ajouter un
service à /etc/services, notez que les ports 0 à 1024 sont réservés au système.
Tâches des services réseau client
Tâche
Raccourci SMIT
Commande ou
fichier
Web–based System
Manager
Management
Environment
Liste des services
disponibles
smit lsservices
Affichez
/etc/services
Software ––>
Network ––> TCPIP
(IPv4 and IPv6) ––>
Services.
Ajout d’un service
smit mkservices
Editez /etc/services
Software ––>
Network ––> TCPIP
(IPv4 and IPv6) ––>
Services ––> New
Service.
Protocole TCP/IP
4-205
Tâche
Raccourci SMIT
Commande ou
fichier
Web–based System
Manager
Management
Environment
Modification/
affichage des
caractéristiques d’un
service
smit chservices
Editez /etc/services
Software ––>
Network ––> TCPIP
(IPv4 and IPv6) ––>
Services.
Sélectionnez un
service, puis cliquez
sur Selected ––>
Properties.
Suppression d’un
service
smit rmservices
Editez /etc/services
Software ––>
Network ––> TCPIP
(IPv4 and IPv6) ––>
Services.
Sélectionnez un
service, puis cliquez
sur Selected ––>
Delete.
Services réseau serveur
Les services réseau serveur se composent du contrôle de l’accès distant, du démarrage ou
de l’arrêt de TCP/IP, et de la gestion du pilote d’unité pty, comme indiqué dans le tableau
suivant.
Le pilote d’unité pty est installé automatiquement avec le système. Par défaut, ce pilote,
configuré pour des liaisons symboliques 16 BSD, est disponible dès l’amorçage.
Tâches des services réseau serveur
4-206
Tâche
Raccourci SMIT
Commande ou
fichier
Contrôle d’accès à
distance
Reportez–vous à ”Exécution de
commandes à distance et
”Restrictions d’accès FTP”.
Software ––>
Network ––> TCPIP
(IPv4 and IPv6) ––>
Access Control.
Cliquez avec le
bouton droit de la
souris sur Remote
Access, puis
sélectionnez
Properties.
Démarrage,
redémarrage ou
arrêt des
sous-systèmes
TCP/IP
smit otherserv
Software ––>
Network ––> TCPIP
(IPv4 and IPv6) ––>
Subsystems.
Cliquez avec le
bouton droit de la
souris sur un
sous–système, puis
sélectionnez
Properties.
Reportez–vous à
System Resource
Control (SRC)
page 4-202.
Guide de gestion du système – Communications et réseaux
Web–based System
Manager
Management
Environment
Tâche
Raccourci SMIT
Commande ou
fichier
Web–based System
Manager
Management
Environment
Modification/affichag
e des
caractéristiques du
pilote d’unité pty
smit chgpty
chdev –l pty0 –P –a
num= X
X étant une valeur
comprise entre 0
et 64
Désactivation du
pilote d’unité pty
smit pty puis
sélectionnez
Retrait du PTY ;
conserver
définition
Activation du pilote
d’unité pty
smit pty puis
sélectionnez
Configuration du
PTY défini
Génération d’un
compte rendu
d’erreur
smit errpt
Suivi de pty
smit trace
Protocole TCP/IP
4-207
Routage TCP/IP
Cette section traite des points suivants :
• Routage statique ou dynamique, page 4-209
• Passerelles, page 4-209
• Planification des passerelles, page 4-211
• Configuration d’une passerelle, page 4-212
• Restriction de l’utilisation de route, page 4-214
• Détection des passerelles non opérationnelles, page 4-214
• Clonage de route, page 4-215
• Suppression manuelle de routes dynamiques, page 4-215
• Configuration du démon routed, page 4-215
• Obtention d’un numéro de système autonome, page 4-219
Une route indique l’itinéraire des paquets à travers le réseau Internet. Elle ne définit pas le
parcours complet, mais seulement le segment entre un hôte et une passerelle vers la
destination (ou une autre passerelle). Il existe cinq types de routes :
route hôte
Passerelle capable d’envoyer les paquets vers un hôte ou une
passerelle d’un autre réseau.
route réseau
Passerelle capable d’envoyer les paquets vers n’importe quel
hôte d’un réseau spécifique.
route par défaut
Passerelle utilisable lorsqu’aucune route hôte ou réseau n’est
définie.
route de boucle
Route par défaut pour tous les paquets envoyés aux adresses
du réseau local. L’IP de la route de boucle est toujours 127.0.0.1.
route de diffusion
Route par défaut pour tous les paquets de diffusion. Deux routes
de diffusion sont automatiquement attribuées à chaque
sous–ensemble possédant un IP du réseau (un sur l’adresse du
sous–réseau et un sur l’adresse de diffusion du sous–réseau).
Les routes sont définies dans la table de routage du noyau. Chaque définition donne des
informations sur les réseaux accessibles à partir de l’hôte local et sur les passerelles
disponibles pour atteindre les réseaux distants. A réception d’un datagramme, la passerelle
recherche dans la table de routage l’étape suivante du parcours.
A partir de Aix 5.1, vous pouvez ajouter plusieurs routes dans la table de routage du noyau
pour indiquer la même destination. La recherche d’un routage évalue toutes les routes qui
correspondent à la demande, puis choisit la route ayant la distance métrique la plus courte.
Si la recherche trouve plusieurs routes de même distance, elle choisit la route plus
adéquate. Si les deux critères sont équivalents pour plusieurs routes, la recherche se
concentre sur les critères alternatifs des routes correspondantes.
4-208
Guide de gestion du système – Communications et réseaux
Routage statique ou dynamique
TCP/IP propose deux types de routage : statique ou dynamique. Avec le routage statique, la
table de routage est gérée manuellement à l’aide d’une commande de routage. Le routage
statique est conseillé lorsqu’un réseau communique avec un ou plusieurs réseaux.
Toutefois, si ce type de routage est pratique lorsque la communication se limite à deux ou
trois réseaux, il devient fastidieux sur une plus grande échelle, avec la multiplication du
nombre de passerelles.
Avec le routage dynamique, ce sont les démons qui mettent à jour la table de routage
automatiquement. Les démons de routage reçoivent en permanence les informations
émises par d’autres démons de routage, et mettent systématiquement à jour la table de
routage en conséquence.
TCP/IP propose deux démons de routage dynamique : routed et gated. Le démon gated
gère les protocoles RIP (Routing Information Protocol), RIPng (Routing Information Protocol
Next Generation), EGP (Exterior Gateway Protocol), BGP (Border Gateway Protocol) et
BGP4+, HELLO (Defense Communications Network Local–Network Protocol), OSPF
(Open Shortest Path First), IS–IS (Intermediate System to Intermediate System), ainsi que
ICMP et ICMPv6 (Internet Control Message Protocol) / Router Discovery simultanément.
Le démon gated prend également le protocole SNMP (Simple Network Monitoring Protocol)
en charge. Le démon routed n’admet que le protocole RIP.
Les démons de routage peuvent fonctionner en mode passif ou actif (selon l’option définie
à leur lancement). En mode actif, ils diffusent périodiquement des informations de routage
sur leur réseau local aux passerelles et aux hôtes, et en reçoivent d’eux. En mode passif,
ils se limitent à recevoir les informations et ne tiennent pas à jour les passerelles distantes.
Ces deux types de routage sont applicables aux passerelles mais aussi à d’autres hôtes
d’un réseau. Les travaux de routage statique fonctionnent de la même façon pour les
passerelles que pour les autres hôtes. Les démons de routage dynamique, toutefois,
doivent être exécutés en mode passif (quiet) sur les hôtes qui ne sont pas des passerelles.
Passerelles
Les passerelles sont des types de routeur. Les routeurs interconnectent des réseaux
et assurent la fonction de routage. Certains routeurs opèrent le routage au niveau de
l’interface de réseau ou de la couche physique.
Les passerelles, quant à elles, assurent le routage au niveau de la couche réseau. Elles
reçoivent les datagrammes IP des autres passerelles ou hôtes, les transmettent aux hôtes
du réseau local et acheminent les datagrammes IP d’un réseau à l’autre. Par exemple, une
passerelle reliant deux réseaux en anneau à jeton est équipée de deux cartes de réseau en
anneau à jeton dotée chacune de sa propre interface de réseau en anneau à jeton. Pour la
transmission des informations, la passerelle reçoit les datagrammes via une interface de
réseau et les envoie par l’autre. Les passerelles contrôlent périodiquement leurs
connexions réseau à partir de messages d’état sur les interfaces.
Pour l’aiguillage des paquets, les passerelles se fondent sur le réseau de destination et non
sur l’hôte de destination. Ainsi, elles n’ont pas à garder trace des diverses destinations hôte
possibles d’un paquet. Au lieu de cela, elles acheminent les paquets en fonction du réseau
de l’hôte de destination. C’est le réseau de destination qui se charge ensuite d’envoyer les
paquets à l’hôte de destination. Généralement, une passerelle ne requiert qu’une capacité
limitée de stockage disque (éventuellement) et de mémoire centrale.
La distance à parcourir entre l’hôte émetteur et l’hôte destinataire dépend du n à traverser
(sauts de passerelles à traverser). 0 si la passerelle est rattachée directement au réseau,
1 si le réseau est accessible via une passerelle, etc. La distance d’un message s’exprime
généralement en nombre de passerelles, ou nombre de bonds (ou distance métrique).
Protocole TCP/IP
4-209
Passerelles intérieures et extérieures
Les passerelles intérieures font partie du même système autonome. Elles communiquent
entre elles à l’aide des protocoles RIP (Routing Information Protocol), RIPng (Routing
Information Protocol Next Generation), Intermediate System to Intermediate System, OSPF
(Open Shortest Path First protocol) ou du protocole HELLO. Les passerelles extérieures
appartiennent à des systèmes autonomes distincts. Elles utilisent les protocoles EGP
(Exterior Gateway Protocol), BGP (Border Gateway Protocol) ou BGP4+.
Prenons l’exemple de deux systèmes autonomes. Le premier correspond à tous les
réseaux administrés par la société Widget. Le second correspond à tous les réseaux
administrés par la société Gadget. La société Widget possède une machine pomme, qui est
la passerelle de Widget pour Internet. La société Gadget possède une machine orange, qui
est la passerelle de Gadget pour Internet. Les deux sociétés possèdent plusieurs réseaux
distincts en interne. Les passerelles reliant les réseaux internes sont des passerelles
intérieures. Mais les passerelles pomme et orange sont extérieures.
Chaque passerelle extérieure ne communique pas avec toutes les autres passerelles
extérieures. En fait, la passerelle extérieure acquiert un ensemble de passerelles
limitrophes (les autres passerelles extérieures) avec lesquelles elle communique. Ces
passerelles limitrophes ne sont pas définies par une proximité géographique, mais plutôt
par les communications qui s’établissent entre elles. Les passerelles limitrophes, à leur tour,
possèdent d’autres passerelles limitrophes extérieures. Ainsi, les tables de routage des
passerelles extérieures sont mises à jour et les informations de routage sont diffusées vers
l’ensemble des passerelles extérieures.
Les informations de routage sont expédiées avec les coordonnées (R,D), R étant le réseau
cible et D la distance à parcourir (et donc le coût correspondant) pour l’atteindre. Chaque
passerelle indique les réseaux qui lui sont accessibles et le coût de leur accès. La
passerelle réceptrice détermine les chemins les plus courts et les indique aux passerelles
limitrophes. Ainsi, chaque passerelle extérieure reçoit en continu des informations (et met
alors à jour ses tables de routage) qu’elle retransmet aux passerelles limitrophes.
Protocoles de passerelle
Toute passerelle, interne ou externe, communique avec les autres via des protocoles.
Voici une présentation succincte des protocoles de passerelle TCP/IP courants :
Protocole HELLO
Le protocole HELLO est utilisé par les passerelles intérieures pour
communiquer entre elles. HELLO est chargé de calculer le chemin d’accès
le plus court (en durée) aux autres réseaux.
RIP (Routing Information Protocol )
Le protocole RIP est également utilisé par les passerelles intérieures pour
communiquer entre elles. Comme le protocole HELLO, RIP calcule le
chemin d’accès le plus court aux autres réseaux. A la différence de HELLO
cependant, RIP calcule la distance en nombre de sauts, et non en durée.
Comme le démon gated enregistre toutes les distances métriques en
interne en tant que durée, il convertit les nombres de sauts calculés par
RIP en durée.
Routing Information Protocol Next Generation
RIPng est le protocole RIP étendu qui permet de gérer IPv6.
OSPF (Open Shortest Path First)
Le protocole OPSF est utilisé par les passerelles intérieures pour
communiquer entre elles. Ce protocole de communication est plus
approprié que RIP pour les réseaux complexes comprenant plusieurs
routeurs. Il fournit un routage multi–itinéraire au même coût.
4-210
Guide de gestion du système – Communications et réseaux
EGP (Exterior Gateway Protocol)
Les passerelles extérieures utilisent ce protocole pour communiquer entre
elles. Le protocole EGP ne calcule par le plus court chemin vers les autres
réseaux. Il indique simplement si un réseau particulier est accessible ou
non.
Border Gateway Protocol (BGP)
Les passerelles extérieures utilisent ce protocole pour communiquer entre
elles. Ce protocole permet l’échange d’informations d’accessibilité entre
des systèmes autonomes, mais il fournit davantage de fonctions que le
protocole EGP. BGP utilise les attributs de chemin pour fournir des
informations supplémentaires sur chaque route afin de sélectionner la plus
appropriée.
Border Gateway Protocol 4+
BGP4+ est le protocole BGP version 4, qui gère IPv6 et propose d’autres
fonctions étendues par rapport aux versions précédentes.
IS–IS (Intermediate System to Intermediate System)
Les passerelles intérieures utilisent le protocole IS–IS pour communiquer
entre elles. Ce protocole de communication permet de router des paquets
IP et ISO/CLNP et, comme OSPF, il utilise un algorithme de détection du
chemin le plus court pour déterminer les routes les plus rapides.
Planification des passerelles
Avant de configurer les passerelles de votre réseau, vous devez :
1. Evaluez le nombre de passerelles à utiliser
(reportez–vous à Evaluation du nombre de passerelles à utiliser), page 4-211).
2. Déterminez le type de routage à utiliser
(reportez–vous à Détermination du type de routage à utiliser), page 4-212).
Nombre de passerelles
Le nombre de passerelles nécessaires dépend :
• du nombre de réseaux à connecter,
• du type de connexion des réseaux,
• du niveau d’activité des réseaux connectés.
Par exemple, si les utilisateurs des réseau 1, réseau 2 et réseau 3 doivent tous
communiquer ensembles (comme le montre la figure Exemple de configuration de
passerelle).
Figure 26. Configuration de passerelle simple Cette illustration contient trois nuages
réseau un, deux et trois. Les réseaux un et deux sont connectés avec la passerelle A.
Les réseaux deux et trois sont connectés avec la passerelle B.
passerelle A
réseau 1
passerelle B
réseau 2
réseau 3
Pour relier le réseau 1 directement au réseau 2, vous devez utiliser une première passerelle
(passerelle A). Pour relier le réseau 2 directement au réseau 3, vous devez utiliser une
autre passerelle (passerelle B). Supposons maintenant que les routes appropriées sont
déterminées et que tous les utilisateurs des trois réseaux parviennent à communiquer.
Protocole TCP/IP
4-211
Cependant, si le réseau 2 est très occupé, les communications entre le réseau 1 et le
réseau 3 peuvent s’en trouver ralenties. De plus, si la communication entre ces deux
réseaux est la plus importante, il peut être utile de les connecter directement. Pour ce faire,
vous devez ajouter deux passerelles supplémentaires, une sur le réseau 1 (passerelle C),
l’autre sur le réseau 3 (passerelle D), reliées par une connexion directe. Cette solution n’est
peut–être pas suffisante, une passerelle pouvant raccorder plus de deux réseaux.
Un moyen plus efficace peut consister à connecter directement la passerelle A à la
passerelle B et au réseau 2, ce qui suppose d’équiper A et B d’une seconde carte réseau.
En règle générale, le nombre de connexions réseau assuré par une passerelle est limité au
nombre de cartes réseau qu’elle peut prendre en charge.
Type de routage
Si votre réseau est limité et sa configuration relativement fixe, le routage statique est une
solution satisfaisante. En revanche, si votre réseau est étendu et sa configuration très
variable, il est préférable d’opter pour un routage dynamique. Une solution intermédiaire
peut également être envisagée en panachant les routages statique et dynamique. Par
exemple, il est possible de définir statiquement certaines routes et d’autoriser la mise à jour
d’autres routes par les démons. Les routes statiques créées ne sont ni notifiées aux autres
passerelles ni mises à jour par les démons de routage.
Routage dynamique
Déterminez le démon de routage à utiliser en fonction du type de passerelle nécessaire
et des protocoles qu’elle peut prendre en charge. S’il s’agit d’une passerelle intérieure et
qu’elle ne requiert que le protocole RIP, optez pour le démon routed. Sinon, utilisez gated.
Remarque :
Vous risquez d’obtenir des résultats imprévisibles si les démons gated
et routed sont exécutés sur le même hôte simultanément.
Configuration d’une passerelle
Pour définir une machine comme passerelle, procédez comme suit. Dans un souci de
clarté, on suppose que la passerelle doit être connectée à deux réseaux et qu’elle a déjà
fait l’objet d’une configuration minimale sur un des deux réseaux.
1. Installez et configurez la deuxième carte de réseau, si ce n’est déjà fait.
(Reportez–vous à Installation d’une carte réseau, page 4-38 et à Configuration
et gestion des cartes, page 4-39.)
2. Choisissez une adresse IP pour la seconde interface de réseau et configurez l’interface
comme indiqué à Configuration d’une interface de réseau, page 4-56.
3. Ajoutez une route d’accès au second réseau.
4. Pour utiliser une machine comme routeur interréseau sur les réseaux TCP/IP, entrez :
no –o ipforwarding=1
5. La passerelle peut désormais accéder aux deux réseaux directement raccordés.
a. Pour que le routage statique serve à communiquer avec des hôtes et réseaux en
dehors de ces deux réseaux, ajoutez les routes nécessaires.
b. Pour le routage dynamique, procédez comme indiqué dans Configuration du démon
routed, page 4-215 ou dans 1Configuration du démon gated, page 4-215. Si votre
interréseau doit rejoindre le réseau Internet, suivez les instructions de la section
Obtention d’un numéro de système autonome, page 4-219.
4-212
Guide de gestion du système – Communications et réseaux
Configuration d’une passerelle
Tâche
Raccourci SMIT
Commande ou
fichier
Affichage du
tableau de
routage
smit lsroute
netstat –rn1
Ajout d’une route
statique
smit mkroute
Suppression
d’une route
statique
smit rmroute
Vidage de la
table de routage
smit fshrttbl
Web-based System Manager
Management Environment
Software ––> Network ––> TCPIP
(IPv4 and IPv6) ––> TCPIP
Protocol Configuration ––>
TCP/IP ––> Configure TCP/IP ––>
Advanced Methods ––> Static
Routes ––> Statistics.
route ajoutée
Software ––> Network ––> TCPIP
destination
(IPv4 and IPv6) ––> TCPIP
passerelle2
Protocol Configuration ––>
TCP/IP ––> Configure TCP/IP ––>
Advanced Methods ––> Static
Routes. Complétez les informations
dans Add/Change a static route
(ajout/modification d’une route
statique) : Destination Type (type
de destination), Gateway address
(adresse de la passerelle), Network
interface name (menu déroulant de
l’interface de réseau), Subnet mask
(masque de sous–réseau), Metric
(coût de la distance métrique) et
Enable active dead gateway
detection (activer la détection des
passerelles non opérationnelles).
Cliquez sur Add/Change Route
(ajout/modification d’une route).
route supprimée Software ––> Network ––> TCPIP
destination
(IPv4 and IPv6) ––> TCPIP
passerelle2
Protocol Configuration ––>
TCP/IP ––> Configure TCP/IP ––>
Advanced Methods ––> Static
Routes. Sélectionnez une route,
puis cliquez sur Delete Route
(supprimer la route).
vidage de la
route
Software ––> Network ––> TCPIP
(IPv4 and IPv6) ––> TCPIP
Protocol Configuration ––>
TCP/IP ––> Configure TCP/IP ––>
Advanced Methods ––> Static
Routes ––> Delete All.
Remarques :
1. La table est divisée en colonnes, où sont répertoriés l’adresse de destination, l’adresse
de passerelle, les indicateurs, le nombre de sauts et l’interface de réseau. Pour la
description de ces colonnes, reportez-vous à la commande netstat dans le manuel AIX
5L Version 5.3 Commands Reference. En cas d’échec de livraison de trames, si les
tables de routage sont correctes, un ou plusieurs des événements ci-dessous sont
probablement en cause :
– réseau défaillant,
– passerelle ou hôte distant défaillant,
– passerelle ou hôte distant en panne, ou non disponible pour réceptionner des trames,
– hôte distant ne disposant pas de route retour au réseau source.
Protocole TCP/IP
4-213
2. destination représente l’adresse ou le nom symbolique de l’hôte ou réseau de
destination et passerelle, l’adresse ou le nom symbolique de la passerelle.
(Une route implicite a 0 comme valeur de destination.)
Sécurité des routes
Les routes peuvent être sécurisées en limitant leur accès à certains utilisateurs. Les
restrictions d’accès sont basées sur les ID de groupe primaire des utilisateurs. Avec la
commande route, vous pouvez établir une liste de 32 ID groupe maximum et les autoriser
ou non à utiliser une route. Si la liste contient des groupes autorisés, n’importe quel
utilisateur de n’importe quel groupe a accès à la route. Si au contraire, la liste est formée de
groupes non autorisés, seuls les utilisateurs n’appartenant pas aux groupes de la liste ont
accès à la route. L’utilisateur racine a accès à toutes les routes.
En outre, les groupes peuvent être associés à une interface via la commande ifconfig.
Dans ce cas, tout paquet à expédier peut utiliser n’importe quelle route dont l’accès est
autorisé aux groupes associés à son interface en entrée.
Si plusieurs routes ont la même destination, les réceptions de réacheminement ICMP pour
cette destination sont ignorés et la recherche de MTU d’accès n’est pas effectuée sur ces
routes.
Détection des passerelles non opérationnelles
A partir d’AIX 5.1 et des versions ultérieures, vous pouvez configurer un hôte pour qu’il
détecte si une passerelle est désactivée et pour qu’il modifie la table de routage en fonction
des situations. Lorsque l’option de réseau –passive_dgd est définie sur 1, la détection
passive des passerelles non opérationnelles est activée pour l’ensemble du système. Si les
demandes ARP consécutives pour dgd_packets_lost n’obtiennent pas de réponse, cette
passerelle est considérée non opérationnelle et le système attribue aux distances métriques
(également nommées nombre de bonds ou coût) de toutes les routes empruntant cette
passerelle les valeurs les plus élevées possibles. Après un dépassement de temps
(minutes) associé à dgd_retry_time, les coûts des routes sont restaurés sur la base des
valeurs définies par l’utilisateur. L’hôte est également impliqué dans l’échec des connexions
TCP. Si les paquets TCP consécutifs dgd_packets_lost sont perdus, l’entrée ARP de la
passerelle est supprimée et la connexion TCP tente la route suivante la plus appropriée.
Si la passerelle est effectivement non opérationnelle, à l’utilisation suivante de la passerelle,
les actions citées ci–dessus se reproduisent. Les paramètres passive_dgd,
dgd_packets_lost, and dgd_retry_time peuvent tous être configurés à l’aide de la
commande no.
Vous pouvez également configurer les hôtes pour qu’ils appliquent la détection des
passerelles non opérationnelles selon la route à l’aide de l’indicateur –active_dgd de la
commande route. La détection des passerelles non opérationnelles exécute un ping sur
toutes les passerelles utilisées par les routes associées à la détection selon l’intervalle en
seconde lié au paramètre dgd_ping_time. Si la passerelle ne donne pas de réponse,
l’exécution du ping est répétée plus rapidement en fonction de la valeur associée à
dgd_packets_lost. Si la passerelle ne donne toujours pas de réponse, le système
augmente tous les coûts des routes qui utilisent cette passerelle. La passerelle poursuit
l’exécution du ping et lorsque la réponse arrive, les coûts des routes sont restaurés sur la
base des valeurs définies par l’utilisateur. Le paramètre dgd_ping_time peut être configuré
à l’aide de la commande no.
Normalement, la détection des passerelles non opérationnelles est plus utile pour les hôtes
avec un routage statique qu’avec un routage dynamique. La détection des passerelles non
opérationnelles comporte une charge réduite et elle est conseillée pour les réseaux ayant
des passerelles redondantes. Toutefois, la détection des passerelles non opérationnelles
est appliquée uniquement dans l’optique d’offrir le meilleur service possible. Certains
protocoles, tels que UDP, ne fournissent aucun retour d’informations à l’hôte en cas d’échec
de la transmission des données ; dans de telles circonstances, la détection des passerelles
non opérationnelles ne peut prendre aucune mesure.
4-214
Guide de gestion du système – Communications et réseaux
La détection des passerelles non opérationnelles est plus utile lorsqu’un hôte doit découvrir
immédiatement l’arrêt d’une passerelle. Toutefois, du fait des requêtes répétées vers les
passerelles définies, elle implique une certaine charge sur le réseau. La détection des
passerelles non opérationnelles est recommandée uniquement pour les hôtes qui
fournissent des services vitaux et les réseaux ayant un nombre limité d’hôtes.
Remarque :
La détection des passerelles non opérationnelles et les protocoles de
routage utilisés par les démons gated et routed exécutent une fonction
similaire en détectant des modifications de la configuration du réseau et en
ajustant la table de routage. Toutefois, ils utilisent des mécanismes
différents et s’ils sont exécutés en même temps, ils peuvent entrer en conflit
l’un avec l’autre. Pour cette raison, la détection des passerelles non
opérationnelles ne doit pas être utilisée sur les systèmes exécutant les
démons gated ou routed.
Clonage de route
Le clonage de route permet de créer une route hôte pour tous les hôtes avec lesquels un
système communique. Lorsque vous êtes sur le point d’envoyer du trafic sur le réseau, une
recherche est effectuée dans la table de routage pour trouver une route jusqu’à l’hôte. Si
une route spécifique est trouvée jusqu’à l’hôte, elle est utilisée. Dans le cas contraire, une
route réseau ou la route par défaut peut être trouvée. Si l’indicateur de clonage ’c’ est défini
pour la route, une route hôte pour la destination est créée à l’aide de la passerelle de la
route clonée. Les recherches suivantes effectuées sur la table de routage trouvent la route
hôte clonée. Les routes clonées sont associées à l’indicateur ’W’. Ces routes expirent et
sont supprimées de la table de routage si elles restent inutilisées pendant route_expire
minutes. Vous pouvez modifier route_expire à l’aide de la commande no.
La fonction de clonage de route est utilisée principalement par le protocole de détection
MTU de chemin dans AIX afin de lui permettre de suivre les informations MTU de chemin
pour chaque destination avec laquelle il communique. Si les options de réseau
tcp_pmtu_discover ou udp_pmtu_discover (qui peuvent être définies avec la
commande no ) sont égales à 1, l’indicateur de clonage est activé pour toutes les routes
réseau du système. Dans AIX 4.3.3 et les versions ultérieures, la détection MTU de chemin
est activée par défaut.
Suppression manuelle de routes dynamiques
Si le démon routed est actif, aucune route supprimée manuellement n’est remplacée par
les informations RIP entrantes (du fait des contrôles d’E/S). Si vous utilisez le démon gated
sans l’indicateur –n, la route supprimée manuellement est remplacée par celle fournie par
les informations RIP entrantes.
Configuration du démon routed
Pour configurer le démon routed :
1. Supprimez le symbole de commentaire (#) et modifiez la clause associée au démon
routed dans le script du shell /etc/rc.tcpip. Cette commande initialise automatiquement
le démon routed à chaque lancement du système.
– Indiquez le mode d’exécution souhaité : actif (indicateur –s) ou passif (indicateur–q).
– Activez éventuellement le suivi des paquets (indicateur –t). Vous pouvez également le
faire pendant l’exécution du démon routed, via la commande kill. Cette commande
communique au démon un signal SIGUSR1. Ce signal peut également servir à
incrémenter le niveau de suivi sur quatre niveaux. Vous pouvez également désactiver
le suivi de paquet pendant l’exécution du démon routed, via la commande kill : cette
commande communique au démon un signal SIGUSR2. Pour en savoir plus,
reportez-vous au démon routed et à la commande kill.
Protocole TCP/IP
4-215
– Activez éventuellement la mise au point (indicateur –d). Précisez alors également
le fichier journal dans lequel consigner les informations de mise au point (ou indiquez
que vous souhaitez les diriger vers l’écran de la console).
– Indiquez si vous exécutez le démon routed sur une passerelle (indicateur –g).
Remarque :
Un hôte non passerelle peut exécuter le démon routed, mais en
mode passif uniquement.
2. Identifiez tous les réseaux connus en les répertoriant dans le fichier /etc/network. Pour
en savoir plus, reportez-vous à la section Networks File Format for TCP/IP dans le
manuel AIX 5L Version 5.3 Files Reference. Un exemple du fichier networks est
proposé dans le répertoire /usr/samples/tcpip.
3. Définissez dans le fichier /etc/gateways les routes d’accès à toutes les passerelles
connues qui ne sont pas directement connectées à votre réseau. Reportez–vous à
Format de fichier passerelle pour TCP/IP dans AIX 5L Version 5.3 Files Reference pour
des exemples d’entrées détaillés dans le fichier /etc/gateways. Un exemple du fichier
gateways est proposé dans le répertoire /usr/samples/tcpip.
Attention : N’exécutez pas le démon routed et le démon gated sur la même machine.
Des résultats imprévisibles peuvent survenir.
Configuration du démon gated
Pour configurer le démon gated, procédez comme suit :
1. Déterminez les protocoles de passerelle appropriés pour votre système. Vous pouvez
utiliser les protocoles de routage EGP, BGP, RIP, RIPng, HELLO, OSPF, ICMP/Router
Discovery ou IS–IS. Vous pouvez également prévoir le protocole SNMP, qui permet
d’afficher et de modifier à partir d’un hôte distant les informations de gestion d’un
élément de réseau.
Remarque :
Utilisez les protocoles EGP, BGP ou BGP4+ pour notifier les adresses
des réseaux d’un système autonome auprès des passerelles des autres
systèmes autonomes. Si vous faites partie du réseau Internet, EGP,
BGP, or BGP4+ doivent être appliqués pour notifier le système de
passerelles noyau de l’accessibilité du réseau. Utilisez les protocoles de
routage interne pour communiquer les informations d’accessibilité à
l’intérieur d’un système autonome.
2. Identifiez tous les réseaux connus en les répertoriant dans le fichier /etc/network.
Pour en savoir plus, reportez-vous à la section Networks File Format for TCP/IP dans
le manuel AIX 5L Version 5.3 Files Reference. Un exemple du fichier networks est
proposé dans le répertoire /usr/samples/tcpip.
3. Modifiez le fichier /etc/gated.conf pour intégrer la configuration souhaitée pour le
démon gated.
Remarque :
Le démon gated fourni avec
AIX Version 4.3.2 et versions ultérieures correspond à la version 3.5.9.
La syntaxe du fichier /etc/gated.conf a été modifiée. Les exemples
ci–dessous concernent la version 3.5.9 du démon gated. Le fichier
/etc/gated.conf fournit également la syntaxe pour sa configuration si
vous devez l’utiliser avec les versions antérieures à
AIX Version 4.3.2.
a. Indiquez le niveau de suivi souhaité. S’il doit débuter avant l’analyse du fichier
gated.conf, spécifiez l’indicateur –t pour activer le suivi au lancement du démon.
Pour en savoir plus, reportez-vous à la section gated Daemon dans le manuel AIX 5L
Version 5.3 Commands Reference.
b. Indiquez les protocoles de routage souhaités. Vous devez spécifier une instruction
par protocole. Supprimez la marque de commentaire (#) et modifiez les instructions
correspondant aux protocoles à utiliser.
4-216
Guide de gestion du système – Communications et réseaux
. Avec EGP :
– Insérez la clause autonomoussystem. Demandez un numéro de système
autonome à Internet si vous êtes sur Internet, sinon, attribuez vous-même
ce numéro en fonction des numéros sur votre réseau.
– Positionnez la clause EGP sur yes.
– Insérez une clause group pour chaque système autonome.
– Insérez une clause neighbor pour chaque passerelle limitrophe dans ce
système autonome. Par exemple :
autonomoussystem 283 ;
egp yes {
group maxup 1 {
neighbor nogendefault
neighbor nogendefault
} ;
group {
neighbor 192.10.201.1
neighbor 192.10.201.2
} ;
} ;
192.9.201.1 ;
192.9.201.2 ;
;
;
. Avec RIP ou HELLO :
– Positionnez l’instruction RIP ou HELLO sur yes.
– Dans l’instruction RIP ou HELLO, spécifiez nobroadcast pour que la
passerelle se contente de recevoir des informations de routage, mais n’en
diffuse pas. Sinon, spécifiez broadcast pour qu’elle puisse recevoir et
diffuser ces informations.
– Pour que la passerelle envoie les informations directement aux passerelles
source, utilisez l’instruction sourcegateways. Spécifiez le nom ou
l’adresse Internet d’une passerelle en notation décimale à points dans la
clause sourcegateways. Par exemple :
# Notification à des
passerelles spécifiques
rip/hello yes {
sourcegateways
101.25.32.1
101.25.32.2 ;
} ;
L’exemple suivant illustre la syntaxe de RIP/HELLO du fichier gated.conf d’une machine
qui n’envoie aucun paquet RIP, ni n’en reçoit sur son interface tr0.
rip/hello nobroadcast {
interface tr0 noripin ;
} ;
. Avec BGP :
– Insérez la clause autonomoussystem. Demandez un numéro de système
autonome à Internet si vous êtes sur Internet, sinon, attribuez vous-même
ce numéro en fonction des numéros sur votre réseau.
– Positionnez la clause BGP sur yes.
Protocole TCP/IP
4-217
– Insérez une clause peer pour chaque passerelle limitrophe dans ce
système autonome. Par exemple :
# Exécuter toutes les opérations BGP
bgp yes {
peer 192.9.201.1 ;
} ;
. Avec SNMP :
– Positionnez la clause SNMP sur yes.
snmp yes ;
Configuration du démon gated pour l’exécution de IPv6
Pour configurer le démon gated pour l’exécution avec IPv6 (Internet Protocol version 6),
vérifiez d’abord que votre système est configuré pour IPv6 et le routage IPv6 :
1. Exécutez autoconf6 pour configurer automatiquement vos interfaces pour IPv6.
2. Configurez les adresses locales de chaque interface IPv6 sur laquelle vous voulez
utiliser le routage IPv6, via la commande :
ifconfig interface inet6 fec0:n::address/64 alias
où
interface
est le nom de l’interface, comme tr0 ou en0.
n
est un nombre décimal quelconque, par exemple 11
address
est la portion de l’interface IPv6 qui suit les deux colonnes, par exemple,
avec l’adresse IPv6 fe80::204:acff:fe86:298d, l’entrée address
serait 204:acff:fe86:298d.
Remarque :
La commande netstat –i permet d’afficher votre adresse IPv6 pour
chaque interface configurée.
Ainsi, si l’anneau à jeton tr0 est associé à l’adresse IPv6
fe80::204:acff:fe86:298d, entrez la commande :
ifconfig tr0 inet6 fec0:13::204:acff:fe86:298d/64 alias
3. Pour activer le réacheminement IPv6, utilisez la commande :
no –o ip6forwarding=1
4. Pour lancer ndpd–router, utilisez la commande :
ndpd–router –g
Affichez ndpd–router pour déterminer les indicateurs à utiliser dans votre configuration
réseau.
Si vous lancez ndpd–router, votre système pourra être utilisé comme routeur pour le
protocole Neighbor Discovery Protocol. Les routeurs Neighbor Discovery Protocol
communiquent les informations de routage aux hôtes Neighbor Discovery afin qu’ils
acheminent les paquets IPv6.
4-218
Guide de gestion du système – Communications et réseaux
Tout hôte du réseau devant appartenir au réseau IPv6 doit exécuter ndpd–host. Les
hôtes du réseau qui exécutent ndpd–host se reconnaîtront comme appartenant à un
réseau IPv6 et utiliseront par conséquent le protocole Neighbor Discovery Protocol. Ce
protocole leur permet de déterminer et de contrôler les adresses de communication, non
seulement pour autoriser le routage limitrophe, mais aussi pour rechercher les routeurs
limitrophes afin de réacheminer les paquets.
Pour plus d’informations, reportez–vous aux sections ndpd–router, ndpd–host, ou
consultez RFC 1970, Neighbor Discovery.
Ensuite, configurez le démon gated :
1. Déterminez les protocoles de passerelle IPv6 appropriés pour votre système. Vous
pouvez utiliser les protocoles de routage IPv6 BGP4+ (Border Gateway Protocol étendu
pour IPv6) et RIPng (Routing Information Protocol Next Generation).
2. Modifiez le fichier /etc/gated.conf pour intégrer la configuration souhaitée pour le
démon gated.
Remarque :
AIX Version 4.3.2 et ultérieures exécutent gated version 3.5.9. La
syntaxe du fichier gated.conf est légèrement modifiée par rapport aux
versions précédentes. Pour connaître la syntaxe appropriée,
reportez–vous à la documentation gated.conf ou utilisez le fichier
exemple disponible dans le répertoire /usr/sample/tcpip.
Pour configurer BGP4+ ou RIPng, utilisez les adresses IPv6 dont la syntaxe spécifie une
adresse IP.
Remarque :
Par défaut, le protocole RIPng envoie des paquets à plusieurs
destinataires.
Dès que le fichier /etc/gated.conf a été modifié, le démon gated peut être lancé.
Obtention d’un numéro de système autonome
Si vous utilisez EGP ou BGP, il est recommandé de solliciter auprès du NIC un numéro de
système autonome officiel pour votre passerelle. Pour ce faire, contactez NIC à l’adresse
[email protected].
Protocole TCP/IP
4-219
Mobile IPv6
Le mobile IPv6 prend en charge la mobilité à IPv6. Il vous permet de conserver la même
adresse Internet dans le monde entier et permet aux applications utilisant cette adresse de
mettre à jour les connexions de transport et de couche supérieure lorsque vous changez de
lieu. Il permet aussi la mobilité dans des milieux homogènes et hétérogènes. Par exemple,
Mobile IPv6 facilite le déplacement de nœud d’un segment Ethernet vers une cellule LAN
sans fil, tandis que l’adresse IP du nœud mobile reste inchangée.
Dans Mobile IPv6, chaque nœud mobile est identifié par deux adresses IP : l’adresse
d’origine et l’adresse provisoire. L’adresse d’origine est une adresse IP permanente qui
identifie le nœud mobile quel que soit son emplacement. L’adresse provisoire change à
chaque nouveau point de connexion et fournit des informations sur la situation actuelle du
nœud mobile. Lorsqu’un nœud mobile arrive sur un réseau visité, il doit se procurer une
adresse provisoire qu’il utilise pendant tout le temps qu’il occupera cet emplacement dans
le réseau visité. Il peut utiliser les méthodes d’IPv6 Neighborhood Discovery pour obtenir
l’adresse provisoire (reportez–vous à Neighbor Discovery/autoconfiguration d’une adresse
sans état page 4-11). Une autoconfiguration sans état ou avec état est possible. L’adresse
provisoire peut aussi être configurée manuellement. Le mode d’acquisition de l’adresse
provisoire n’a pas d’importance pour Mobile IPv6.
Un agent d’origine au moins doit être configuré sur le réseau d’origine et le nœud mobile
doit être configuré pour connaître l’adresse IP de cet agent. Le nœud mobile envoie un
paquet contenant une mise à jour de lien à l’agent d’origine. L’agent d’origine reçoit le
paquet et établit une association entre l’adresse d’origine et le nœud mobile ainsi que
l’adresse provisoire qu’il a reçue. L’agent d’origine répond en envoyant un paquet contenant
un accusé de réception de lien.
L’agent d’origine dispose d’une cache de lien contenant les associations entre les adresses
d’origine et les adresses provisoires des nœuds mobiles qu’il dessert. L’agent d’origine
intercepte les paquets destinés à l’adresse d’origine et les transmet aux nœuds mobiles.
Un nœud mobile envoie alors une mise à jour de lien au nœud correspondant, en
l’informant de son adresse provisoire. Le nœud correspondant crée une entrée de cache
de lien afin de pouvoir envoyer du trafic futur directement au nœud mobile de son adresse
provisoire.
La prise en charge de la mobilité par AIX offre les fonctions suivantes :
En tant qu’agent Agent d’origine :
• Tenue à jour d’une entrée dans sa cache de liens pour chaque nœud mobile servi.
• Interception des paquets adressés à un nœud mobile qu’il dessert en tant qu’agent
d’origine, sur le lien d’origine de ce nœud mobile, lorsque le nœud mobile est en
déplacement.
• Encapsulation des paquets interceptés afin de les tunnéliser vers l’adresse provisoire
principale du nœud mobile indiqué dans son lien, dans la cache de liens de l’agent
d’origine.
• Renvoi d’une option d’accusé de réception de liens en réponse à une option de mise
à jour de liens reçue avec le groupe de bits de l’accusé de réception.
• Procédez à la détection des adresses doubles dans l’adresse provisoire du noeud
mobile afin de vous assurer que les adresses IPv6 sont uniques.
• La prise en charge de la détection d’adresses d’agents d’origine dynamique servant
d’assistance aux noeuds mobiles détecte les adresses des agents d’origine.
• Prend en charge la réception de la sollicitation du préfixe mobile et l’envoi d’annonce
du préfixe mobile.
4-220
Guide de gestion du système – Communications et réseaux
En tant que nœud Correspondant stationnaire :
• Traitement d’une option d’adresse d’origine reçue dans un paquet IPv6.
• Traitement d’une option de mise à jour de liens reçue dans un paquet et renvoi d’une
option d’accusé de réception de liens si le bit d’accusé de réception (A) est défini dans
la mise à jour de liens reçue.
• Tenue à jour d’une cache de liens contenant les lien reçus dans les mises à jour de liens
acceptées.
• Envoi de paquets utilisant un en–tête de routage lorsqu’il existe une entrée de cache
de liens pour un nœud mobile contenant l’adresse provisoire en cours du nœud mobile.
En tant que nœud Routeur dans un réseau visité par le nœud mobile :
• Envoi d’une option d’intervalle d’annonce dans ses annonces de routeur afin de faciliter
la détection de mouvements par les nœuds mobiles. La configuration s’effectue à l’aide
du paramètre –m dans le démon ndpd–router.
• Prise en charge de l’envoi d’annonces de routeur multidiffusion non sollicitées à la
vitesse la plus élevée décrite dans RFC 2461. La configuration peut s’effectuer à l’aide
des paramètres –m et –D dans le démon ndpd–router.
• Envoie une option d’informations relatives à l’agent d’origine (préférence et durée de vie
de l’agent d’origine) dans les annonces de routeur afin d’aider les noeuds mobiles à
sélectionner leur agent d’origine. La configuration s’effectue à l’aide du paramètre –H
dans le démon ndpd–router.
Compréhension de la sécurité du mobile IPv6
Les messages de mise à jour de liens et les accusés de réception échangés entre le noeud
mobile et l’agent d’origine doivent être protégés par IP Security utilisant la protection
Encapsulating Security Payload (ESP) pourvue d’un algorithme d’authentification de charge
non–nul. Pour plus d’informations sur IP Security, reportez–vous au Manuel de sécurité AIX
5L Version 5.3.
La procédure Return Routability permet de sécuriser l’établissement de liens entre le noeud
mobile et le noeud correspondant. Dans cette procédure, les messages échangés entre le
noeud d’agent d’origine et les noeuds mobiles doivent également être protégé par IP
Security utilisant ESP. Les messages de mise à jour de liens et les accusés de réception
de liens échangés entre le noeud correspondant et le noeud mobile étant protégés par la
procédure Return Routability, l’IP Security n’est pas nécessaire pour les noeuds
correspondants. En revanche, si le noeud correspondant utilise IP Security afin de
restreindre son accès, les messages avec le protocole MH (135) doivent être admis.
Les tunnels peuvent être définis manuellement ou à l’aide de IKE servant de répondeur
(seul le mode agressif est pris en charge). Les tunnels IP Security suivants doivent au
moins être définis sur l’agent d’origine via l’en–tête ESP :
• un tunnel en mode transport avec un protocole MH (135) entre l’adresse IP de l’agent
d’origine et l’adresse d’origine de chaque noeud mobile susceptible d’être enregistré sur
cet agent d’origine.
• un tunnel en mode tunnel avec un protocole MH (135) entre une adresse IP quelconque
et l’adresse d’origine de chaque noeud mobile susceptible d’être enregistré sur cet agent
d’origine.
Les tunnels correspondants doivent être définis sur les noeuds mobiles.
Remarque :
Les messages de mise à jour et les accusés de réception sont envoyés
via un en–tête de mobilité et doivent être protégés par IP Security en
utilisant ESP.
Protocole TCP/IP
4-221
Dans les implémentations précédentes de Mobile IPv6 dans AIX, la prise en charge était
fournie pour des noeuds mobiles utilisant des paquets Destination Option afin d’envoyer
des messages de mise à jour de liens. Ces messages peuvent être protégés avec IP
Security en utilisant un en–tête d’authentification.
Afin qu’un agent d’origine ou un noeud correspondant accepte de tels messages de mise à
jour de liens en utilisant une option de destination, éditez le fichier /etc/rc.mobip6 et activez
la variable Enable_Draft13_Mobile avant de lancer Mobile IPv6. Dans ce cas, si vous
utilisez IP Security pour protéger les messages de mise à jour des liens, vous devez définir
un manuel ou des tunnels IKE en mode transport dans le protocole 60, qui protège les
messages de Mise à jour des liens et les Accusés de réception.
Afin qu’un agent d’origine ou un noeud correspondant accepte de tels messages de mise à
jour de liens non protégés par IP Security, éditez le fichier /etc/rc.mobip6 et désactivez la
variable Check_IPsec. Cette méthode n’est pas recommandée car elle affecte la sécurité
de manière significative et plus particulièrement l’acheminement des paquets adressés à un
noeud mobile.
Configuration de Mobile IPv6
Cette section contient des informations relatives à la configuration de Mobile IPv6. Afin de
pouvoir utiliser Mobile IPv6, vous devez dans un premier temps installer l’ensemble des
fichiers bos.net.mobip6.rte. Pour plus d’informations concernant l’installation de
l’ensemble des fichiers, reportez–vous à Produits logiciels facultatifs et mises à jour de
services dans Manuel d’installation et de référence AIX 5L Version 5.3
Lancement de Mobile IPv6
Procédez comme suit pour lancer Mobile IPv6.
En tant qu’agent d’origine
1. Définissez chaque tunnel IKE (phases 1 et 2) comme répondeur en utilisant le protocole
ESP ou manuellement en utilisant ESP IP Security Association entre l’adresse IP de
l’agent d’origine et chaque adresse d’origine mobile avec laquelle le noeud
correspondant peut communiquer.
2. Activez le système comme agent d’origine et noeud correspondant Mobile IPv6.
Sur la ligne de commande, entrez smit enable_mobip6_home_agent.
3. Sélectionnez le moment où vous souhaitez qu’il soit actif.
En tant que nœud correspondant
1. Définissez les tunnels IKE (phases 1 et 2) comme répondeurs en utilisant le protocole
ESP ou manuellement avec ESP IP Security Association entre l’adresse IP de l’agent
d’origine et chaque adresse d’origine mobile avec laquelle le noeud correspondant peut
communiquer.
2. Activez le système comme noeud correspondant Mobile IPv6. Sur la ligne de
commande, entrez smit enable_mobip6_correspondent.
3. Sélectionnez le moment où vous souhaitez qu’il soit actif.
En tant que routeur
Pour faciliter la détection de mouvement, exécutez ce qui suit :
ndpd–router –m
4-222
Guide de gestion du système – Communications et réseaux
Arrêt de Mobile IPv6
Pour mettre fin à Mobile IPv6, entrez smit disable_mobip6 sur la ligne de commande.
Sélectionnez le moment où vous souhaitez mettre fin à Mobile IPv6, si vous souhaitez
mettre fin au démon ndpd–router, et si vous souhaitez désactiver la transmission de IPv6.
Identification des incidents Mobile IPv6
• Obtenez les état des liens en exécutant la commande suivante :
mobip6ctrl –b
• Pour plus d’informations concernant l’utilisation des utilitaires de résolution des incidents
TCP/IP, reportez–vous à Identification des problèmes TCP/IP, page 4-274
Protocole TCP/IP
4-223
Adresse IP virtuelle (VIPA)
Une adresse IP virtuelle évite à l’hôte de dépendre d’interface réseau précises. Les paquets
entrants sont envoyés à l’adresse VIPA du système mais tous les paquets passent par le
réseau réel.
Auparavant, en cas de défaillance d’une interface, les connexions à cette interface étaient
perdues. Avec l’activation de VIPA sur le système et le réacheminement automatique
assuré par les protocoles de routage dans le réseau, la reprise après incident se déroule
sans interruption des connexions utilisateur existantes passant par l’interface virtuelle, à
condition que les paquets puissent arriver via une autre interface physique. Les systèmes
exécutant VIPA sont plus disponibles car les pannes de carte n’affectent plus les
connexions actives. Comme de multiples cartes physiques transmettent le trafic IP du
système, la charge globale n’est pas concentrée sur une seule carte et son sous–réseau
associé.
La fonction AIX VIPA est transparente pour l’équipement réseau. Aucun équipement réseau
spécial ou d’autre matériel n’est requis. Pour implémenter VIPA, vous devez disposer de la
configuration suivante :
• deux interfaces IP existantes de type physique indifférent sur des sous–réseaux
différents qui se connectent au réseau d’entreprise
• des protocoles de routage IP s’exécutant dans le réseau de l’entreprise
Configuration de VIPA
VIPA doit être configuré dans SMIT, comme toutes les interfaces réseau IP. Vous pouvez
aussi définir un groupe d’interfaces tout en configurant VIPA. Lorsqu’elle est configurée de
cette façon, pour toutes les connexions initialisées par l’hôte VIPA via ces interfaces, qui
sont conçues pour utiliser un VIPA, l’adresse virtuelle devient l’adresse source placée dans
l’en–tête du paquet TCP/IP des paquets en sortie.
1. Pour VIPA IPv4, tapez smit mkinetvi sur la ligne de commande.
Pour VIPA IPv6, tapez smit mkinetvi6 sur la ligne de commande.
2. Remplissez tous les champs requis et appuyez sur Entrée.
Gestion de VIPA
Cette section traite des points suivants :
• Ajout d’une carte à un VIPA, page 4-224
• Retrait d’une carte d’un VIPA, page 4-225
• Exemple d’environnement VIPA dans AIX 5.2, page 4-225
• Autres informations techniques, page 4-226
Ajout d’une carte à un VIPA
Pour ajouter une carte à votre interface VIPA, procédez comme suit :
1. Tapez smit chvi sur la ligne de commande.
2. Sélectionnez le VIPA auquel ajouter une carte et appuyez sur Entrée.
3. Indiquez la carte à ajouter dans le champ Interface Name(s).
4. Entrez ADD dans le champ ADD/REMOVE interface(s) et appuyez sur Entrée.
4-224
Guide de gestion du système – Communications et réseaux
Retrait d’une carte d’un VIPA
Pour supprimer une carte d’un VIPA, procédez comme suit :
1. Tapez smit chvi sur la ligne de commande.
2. Sélectionnez le VIPA duquel retirer une carte et appuyez sur Entrée.
3. Indiquez la carte à retirer dans le champ Interface Name(s).
4. Entrez REMOVE dans le champ ADD/REMOVE interface(s) et appuyez sur Entrée.
Exemple d’environnement VIPA dans AIX 5.2
Un système a une adresse IP virtuelle, vi0, de 10.68.6.1 et deux connexions
physiques, en1 avec l’adresse IP 10.68.1.1 et en5,
avec l’adresse IP 10.68.5.1. Dans cet exemple, les deux connexions physiques sont
Ethernet, mais toute combinaison d’interfaces IP, par exemple en anneau à jeton ou FDDI,
sera prise en charge à partir du moment où les sous–réseaux ont été rattachés au réseau
principal d’entreprise et sont connus des routeurs d’entreprise.
L’exécution de la commande lsattr –El vi0 génère les résultats suivants :
netaddr
10.68.6.1
N/A
True
state
up
Standard Ethernet Network Interface
True
netmask
255.255.255.0 Maximum IP Packet Size for This Device
True
netaddr6
Maximum IP Packet Size for REMOTE Networks
True
alias6
Internet Address
True
prefixlen
Current Interface Status
True
alias4
TRAILER Link–Level Encapsulation
True
interface_names en1,en5
Interfaces using the Virtual Address
True
L’exécution de la commande ifconfig vi0 génère les résultats suivants :
vi0: flags=84000041<UP,RUNNING,64BIT>
inet 10.68.6.1 netmask 0xffffff00
iflist : en1 en5
L’exécution de la commande netstat –rn génère les résultats suivants :
Tables de routage
Destination
Groups
Gateway
Flags
Refs
Route Tree for Protocol Family 2 (Internet):
default
10.68.1.2
UG
3
10.68.1/24
10.68.1.1
U
0
10.68.5/24
10.68.5.1
U
0
127/8
127.0.0.1
U
4
10.68.6.1
127.0.0.1
UH
0
Use
If
1055
665
1216
236
0
en1
en1
en5
lo0
lo0
PMTU Exp
–
–
–
–
–
–
–
–
–
–
L’adresse source des paquets en sortie pour lesquels une adresse source n’est pas définie
et qui sont routés via les interfaces en1 et en5 est définie comme l’adresse virtuelle
(10.68.6.1). Les paquets entrants sont routés vers l’adresse VIPA ( 10.68.6.1)
annoncée sur le réseau. Comme vi0 est virtuel, c’est–à–dire qu’il n’est associé à aucune
unité, il ne doit pas exister d’entrées lui correspondant dans la table de routage à l’échelle
de tout le système affichée par la commande netstat –rn. Ceci signifie qu’aucune route
d’interface n’est ajoutée lorsque l’interface est configurée dans SMIT.
Si l’une des interfaces physiques, une connexion réseau ou un chemin réseau échoue, les
protocoles réseau effectuent l’acheminement vers l’autre interface physique du même
système. Si un système éloigné envoie une commande telnet à l’adresse vi0, les paquets
destinés à vi0 peuvent arriver via en1 ou en5. Si en1 est en panne, par exemple, les
paquets peuvent toujours arriver sur en5. Les protocoles de routage peuvent prendre un
certain temps pour propager les routes.
Protocole TCP/IP
4-225
Lorsque vous utilisez le VIPA, les systèmes finals et les routeurs intermédiaires doivent
pouvoir acheminer les paquets destinés à VIPA ( vi0) vers l’une des interfaces physiques
(en1 ou en5).
Autres informations techniques
Comparaison VIPA/alias
Le concept VIPA est semblable aux alias IP, sauf que les adresses ne sont pas associées à
une interface matérielle. VIPA offre plusieurs avantages que les alias IP ne possèdent pas :
• VIPA propose une unité virtuelle qui peut être activée et arrêtée de façon indépendante,
sans impact sur les interfaces physiques.
• Les adresses VIPA peuvent être modifiées, tandis que les alias peuvent seulement être
ajoutés ou supprimés.
Accès via l’adresse IP des cartes réelles
Les interfaces individuelles sont toujours accessibles aux autres systèmes une fois VIPA
implémenté. Toutefois, l’utilisation des adresses IP réelles pour les sessions ping et telnet
renforce l’avantage VIPA qui communique indépendamment des cartes physiques. VIPA
cache les défaillances de carte physique aux clients externes. L’utilisation des adresses
réelles réintroduit la dépendance par rapport aux cartes physiques.
Si le système éloigné contacte le système VIPA à l’aide de l’adresse VIPA ou si une
application sur le système VIPA initialise la communication avec un autre système, l’adresse
VIPA est utilisée comme adresse IP source dans le paquet. Toutefois, si le système éloigné
initialise la session à l’aide de l’adresse IP de l’interface réelle, cette adresse IP réelle est
l’adresse IP source dans les paquets de réponse. Il y a cependant une exception. Pour les
applications établissant une liaison à une interface IP particulière, les paquets sortants
transfèrent l’adresse source de l’interface à laquelle ils sont liés.
VIPA et les protocoles de routage
Le démon gated a été modifié pour VIPA afin de ne pas ajouter de route d’interface ou
d’envoyer d’annonces via des interfaces virtuelles. Le protocole OSPF, pris en charge par
gated, annonce l’interface virtuelle aux routeurs de voisinage. Les autres hôtes du réseau
peuvent parler à l’hôte VIPA via le routeur du premier tronçon.
Adresses VIPA multiples
Il est possible de configurer plusieurs interfaces virtuelles.
Il est utile d’avoir plusieurs interfaces VIPA, par exemple si des routeurs réseau peuvent
offrir un traitement préférentiel aux paquets envoyés de ou vers certaines adresses VIPA.
Vous pouvez aussi utiliser plusieurs interfaces VIPA si elles liaient des applications à une
interface VIPA spécifique. Par exemple, pour exécuter plusieurs serveurs Web pour
plusieurs entreprises sur une seule machine, vous pouvez configurer ce qui suit :
• vi0 200.1.1.1 www.companyA.com
• vi1 200.1.1.2 www.companyB.com
• vi2 200.1.1.3 www.companyC.com
VIPA sous AIX 5.1
Il n’était pas possible de définir un groupe d’interfaces utilisant un VIPA particulier dans
AIX 5.1. Le premier VIPA de la liste d’adresses sera choisi comme adresse source par
défaut lorsque l’application n’établit pas de lien explicite à une adresse.
4-226
Guide de gestion du système – Communications et réseaux
EtherChannel et IEEE 802.3ad Link Aggregation
EtherChannel et IEEE 802.3ad Link Aggregation désignent des technologies d’agrégation
de port réseau permettant à plusieurs cartes Ethernet d’être rassemblées pour former une
seule pseudo–unité Ethernet. Par exemple, ent0 et ent1 peuvent être réunis dans une
carte EtherChannel appelée interface ent3. L’interface en3 est alors configurée avec une
adresse IP. Le système considère cet agrégat de cartes comme une carte unique. Par
conséquent, IP est configuré via ces cartes comme s’il s’agissait d’une carte Ethernet
normale. En outre, toutes les cartes d’EtherChannel ou de Link Aggregation reçoivent la
même adresse matérielle (MAC) et sont donc traitées par les systèmes distants comme
s’il s’agissait d’une seule carte. EtherChannel et IEEE 802.3ad Link Aggregation requièrent
la prise en charge dans le commutateur de sorte que celui–ci sait quels ports du
commutateur doivent être traités ensemble.
L’avantage principal d’EtherChannel et de IEEE 802.3ad Link Aggregation est qu’ils
disposent de toute la bande passante de toutes leurs cartes tout en étant uniques dans le
réseau. En cas de panne d’une carte, le trafic réseau est automatiquement envoyé à la
carte disponible suivante sans interruption des connexions utilisateur existantes. La carte
est remise automatiquement en service sur EtherChannel ou Link Aggregation lorsque
son fonctionnement est rétabli.
Il existe des différences entre EtherChannel et IEEE 802.3ad Link Aggregation. Consultez
les différences indiquées dans le Tableau 15, page 4-227 pour déterminer la solution vous
convenant le mieux.
Tableau 15. Différences entre EtherChannel et IEEE 802.3ad Link Aggregation.
EtherChannel
IEEE 802.3ad
Requiert la configuration du commutateur
Peu ou pas de configuration de
commutateur pour former l’agrégat.
Une configuration initiale du commutateur
peut être nécessaire.
Prend en charge différents modes de
distribution des paquets
Prend en charge uniquement le mode
de distribution standard
La fonctionnalité Dynamic Adapter Membership est disponible à partir de AIX 5L avec
5200–03. Cette fonctionnalité vous permet d’ajouter ou de supprimer des cartes
d’EtherChannel sans interrompre les connexions utilisateur. Pour plus d’informations,
reportez–vous à la section Dynamic Adapter Membership, page 4-238.
Cartes prises en charge
EtherChannel et IEEE 802.3ad Link Aggregation sont pris en charge par les cartes Ethernet
suivantes :
• Carte PCI Ethernet 10/100 Mo/s
• Carte 10/100 Ethernet universelle, 4 ports
• Carte II PCI Ethernet 10/100 Mo/s
• Carte PCI Ethernet 10/100/1000 Base–T
• Carte PCI Gigabit Ethernet–SX
• Carte PCI–X Ethernet 10/100/1000 Base–TX
• Carte PCI–X Gigabit Ethernet–SX
• Carte PCI–X Ethernet 10/100/1000 Base–TX 2 ports
• Carte PCI–X Gigabit Ethernet–SX 2 ports
Protocole TCP/IP
4-227
Seule la fonctionnalité EtherChannel de base (fonctionnant exclusivement en mode
“standard” ou “circulaire” sans option de secours) est prise en charge par les cartes
Ethernet suivantes :
• Carte PCI Ethernet BNC/RJ–45
• Carte PCI Ethernet AUI/RJ–45
Sauf indications contraires contenues dans les remarques sur la version AIX, la prise en
charge de nouvelles cartes sera fournie lorsque ces cartes seront libérées.
Remarque :
Le mélange de cartes de vitesses différentes dans le même EtherChannel,
même si l’une d’elles fonctionne en tant que carte de secours, n’est pas
officiellement pris en charge. Cela ne signifie pas pour autant que de telles
configurations ne fonctionneront pas. Le pilote de EtherChannel essaiera,
dans la mesure du possible, de fonctionner également dans un scénario
comportant diverses vitesses.
Pour plus d’informations sur la configuration et l’utilisation d’EtherChannel, reportez–vous
à EtherChannel, page 4-228. Pour plus d’informations sur la configuration et l’utilisation
de IEEE 802.3ad Link Aggregation, reportez–vous à IEEE 802.3ad Link Aggregation,
page 4-243. Pour plus d’informations sur les différentes combinaisons de configuration
d’AIX et de commutateur, et sur les résultats obtenus, reportez–vous à Scénarios
d’interopérabilité, page 4-246.
EtherChannel
Les cartes appartenant à un EtherChannel doivent être connectées au même commutateur
EtherChannel. Ce commutateur doit être configuré manuellement afin de traiter les ports
appartenant à EtherChannel en tant que lien agrégé. Notez que la documentation sur votre
commutateur peut renvoyer à cette fonction sous ”agrégat de liaisons” or ”acheminement”.
Le trafic est distribué entre les cartes soit de façon standard (la carte via laquelle les
paquets sont envoyés est choisie en fonction d’un algorithme), soit de façon circulaire
(les paquets sont répartis équitablement entre toutes les cartes). Le trafic entrant est
distribué en fonction de la configuration du commutateur et n’est pas contrôlé par le mode
d’exploitation d’EtherChannel.
Dans AIX, vous pouvez configurer plusieurs EtherChannels par système, mais la norme
exige que tous les liens d’un EtherChannel soient rattachées à un seul commutateur.
Comme EtherChannel ne peut pas être réparti entre plusieurs commutateurs, la totalité
d’EtherChannel est perdue en cas de coupure du courant ou de panne du commutateur.
Pour résoudre ce problème, une nouvelle option disponible dans AIX 5.2 et les versions
supérieures maintient le service actif en cas de défaillance de l’EtherChannel principal.
La carte de secours et la carte EtherChannel doivent être raccordées à différents
commutateurs réseau et ceux–ci doivent être interconnectés afin que cette configuration
fonctionne correctement. Au cas où toutes les cartes de l’EtherChannel seraient
défaillantes, la carte de secours serait utilisée pour envoyer et recevoir tout le trafic. Lors de
la restauration d’une liaison d’EtherChannel, le service est retransféré vers l’EtherChannel.
Par exemple, ent0 et ent1 peuvent être configurées comme cartes principales de
l’EtherChannel et ent2 comme carte de secours, créant ainsi un EtherChannel appelé
ent3. Idéalement, ent0 et ent1 sont connectées au même commutateur adapté à
EtherChannel et ent2 est connecté à un autre commutateur. Dans cet exemple, tout le
trafic envoyé via en3 (l’interface d’EtherChannel) est envoyé via ent0 ou ent1 par
défaut (en fonction du schéma de distribution de paquet d’EtherChannel) alors que ent2
est inactif. Si, à un moment donné, ent0 et ent1 échouent, tout le trafic est envoyé via la
carte de secours ent2. Lorsque ent0 ou ent1 sont rétablies, elles sont de nouveau
utilisées pour tout le trafic.
4-228
Guide de gestion du système – Communications et réseaux
Network Interface Backup, un mode d’exploitation disponible pour EtherChannel dans AIX
4.3.3 et AIX 5.1, offre une protection contre un point de défaillance Ethernet unique. Aucun
matériel spécial n’est requis pour utiliser Network Interface Backup, mais la carte de
secours doit être connectée à un commutateur distinct pour obtenir une fiabilité maximale.
Dans le mode Network Interface Backup, une seule carte à la fois est utilisée activement
pour le trafic réseau. L’EtherChannel teste la carte active et facultativement, le chemin
réseau vers un nœud spécifié par l’utilisateur. Lorsqu’une défaillance est détectée, la carte
suivante est utilisée pour tout le trafic. Network Interface Backup fournit des fonctions de
détection et de prise de relais sans interruption des connexions utilisateur. Network
Interface Backup a à l’origine été mis en œuvre en tant que mode dans le menu
EtherChannel SMIT. Dans AIX 5.2 et les versions supérieures, la carte de secours fournit
une fonction équivalente et ce mode a donc été supprimé du menu SMIT. Pour configurer
Network Interface Backup dans AIX 5.2 et les versions supérieures, reportez–vous à
Configure Network Interface Backup, page 4-232.
Configuration d’EtherChannel
Procédez comme suit pour configurer un EtherChannel.
Remarques
• Vous pouvez disposer d’un maximum de huit cartes Ethernet principales et d’une seule
carte de secours Ethernet par EtherChannel.
• Vous pouvez configurer plusieurs EtherChannels sur un seul système, mais chaque
EtherChannel constitue une interface Ethernet supplémentaire. Par conséquent, vous
devez augmenter la valeur de l’option ifsize de la commande no pour inclure les
interfaces Ethernet pour chaque carte, mais également toutes les unités logiques VLAN
configurées. Dans AIX 5.2 et les versions antérieures, le ifsize par défaut est de huit.
Dans AIX 5.2 et les versions supérieures, la taille par défaut est de 256.
• Vous pouvez utiliser n’importe quelle carte Ethernet prise en charge par un
EtherChannel (reportez–vous à Supported Adapters, page 4-227). Toutefois, les cartes
Ethernet doivent être connectées à un commutateur prenant en charge EtherChannel.
Reportez–vous à la documentation fournie avec votre commutateur pour déterminer s’il
prend en charge EtherChannel (la documentation sur votre commutateur peut renvoyer
à cette fonction sous agrégat de liaisons ou acheminement).
• Toutes les cartes d’EtherChannel doivent être configurées pour la même vitesse
(100 Mb, par exemple) et doivent utiliser le mode duplex intégral.
• Les cartes utilisées dans l’EtherChannel ne sont pas accessibles par le système une fois
l’EtherChannel configuré. Pour modifier un de leurs attributs, telle que la vitesse du
support, transmettre ou recevoir les tailles des files d’attente etc., vous devez procéder
de cette manière avant de les inclure dans EtherChannel.
• Les cartes que vous prévoyez d’utiliser pour votre EtherChannel ne doivent pas avoir
d’adresse IP configurée avant de commencer cette procédure. Lorsque vous configurez
un EtherChannel pour des cartes qui étaient précédemment configurées avec une
adresse IP, assurez–vous que leurs interfaces sont dans l’état detach. Les cartes à
ajouter à l’EtherChannel ne peuvent pas avoir d’interfaces configurées dans l’état up
dans le gestionnaire Object Data Manager (ODM) (comme c’est le cas si leurs adresses
IP ont été configurées avec SMIT). Ceci peut causer des problèmes pour activer
EtherChannel lors du redémarrage de la machine, car l’interface sous–jacente est
configurée avant l’EtherChannel avec les informations trouvées dans ODM. Par
conséquent, lorsque l’EtherChannel est configuré, il détecte que l’une de ses cartes est
déjà utilisée. Pour modifier ceci, avant de créer l’EtherChannel, tapez smit chinet,
sélectionnez chacune des interfaces des cartes à inclure dans l’EtherChannel, et
remplacez sa valeur state par detach. Lors du redémarrage de la machine,
l’EtherChannel peut être configuré sans erreurs.
Protocole TCP/IP
4-229
Pour plus d’informations sur ODM, reportez–vous à Object Data Manager (ODM) dans
AIX 5L Version 5.3 General Programming Concepts : Writing and Debugging Programs
• Si vous utilisez des cartes 10/100 Ethernet dans l’EtherChannel, vous devez activer le
sondage de liaison sur ces cartes avant de les ajouter à l’EtherChannel. Tapez smit
chgenet sur la ligne de commande. Remplacez la valeur de Enable Link Polling par
yes puis appuyez sur Entrée.
Remarque :
Dans AIX 5L version 5200–03 et supérieures, l’activation du mécanisme
de sondage de liaison n’est pas nécessaire. Le sondeur de liaison est
démarré automatiquement.
• Si vous avez l’intention d’utiliser des trames jumbo, vous devez activer cette
fonctionnalité sur chaque carte avant de créer l’EtherChannel et l’activer aussi dans
l’EtherChannel lui–même. Tapez smitty chgenet sur la ligne de commande.
Remplacez la valeur de Enable Jumbo Frames par yes, puis appuyez sur Entrée.
Procédez de cette façon pour toutes les cartes pour lesquelles vous voulez activer les
trames jumbo. Vous activerez ultérieurement les trames jumbo dans l’EtherChannel
lui–même.
Remarque :
Dans AIX 5.2 et versions supérieures, l’activation des trames jumbo
dans chaque carte sous–jacente n’est pas nécessaire une fois que ces
trames jumbo ont été activées dans l’EtherChannel lui–même. Cette
fonctionnalité est activée automatiquement si vous activez les attributs
de Enable Jumbo Frames sur yes.
Configuration d’un EtherChannel
1. Tapez smit etherchannel sur la ligne de commande.
2. Sélectionnez Add an EtherChannel / Link Aggregation dans la liste et appuyez
sur Entrée.
3. Sélectionnez les cartes Ethernet principales de l’EtherChannel et appuyez sur Entrée.
Si vous prévoyez d’utiliser la sauvegarde de secours EtherChannel, ne sélectionnez
pas la carte de secours à ce stade. L’option de secours EtherChannel est disponible
dans AIX 5.2 et les versions supérieures.
Remarque :
Cartes réseau disponibles affiche toutes les cartes Ethernet.
Si vous sélectionnez une carte Ethernet déjà utilisée (dont l’interface
est définie), vous obtenez un message d’erreur. Vous devez d’abord
détacher cette interface si vous souhaitez l’utiliser.
4. Entrez les informations dans les champs en respectant les consignes suivantes :
– Cartes EtherChannel / Link Aggregation : Vous devez voir s’afficher toutes les
cartes principales utilisées dans votre EtherChannel. Vous avez sélectionné ces
cartes à l’étape précédente.
– Enable Alternate Address : Ce champ est facultatif. Le choix de la valeur yes
vous permet de préciser une adresse MAC que l’EtherChannel doit utiliser. Si vous
définissez la valeur no pour cette option, l’EtherChannel utilisera l’adresse MAC
de la première carte indiquée.
– Alternate Address : Si vous attribuez à Enable Alternate Address la valeur yes,
indiquez l’adresse MAC à utiliser ici. L’adresse indiquée doit commencer par 0x
et être une valeur hexadécimale à 12 chiffres (par exemple, 0x001122334455).
– Enable Gigabit Ethernet Jumbo Frames : Ce champ est facultatif. Pour l’utiliser, le
commutateur doit prendre en charge les trames jumbo. Ceci fonctionne uniquement
avec une interface Ethernet Standard (en) mais pas avec une interface IEEE 802.3.
Affectez la valeur yes si vous voulez l’activer.
4-230
Guide de gestion du système – Communications et réseaux
– Mode : Vous pouvez choisir entre les modes suivants :
. standard : Dans ce mode, l’EtherChannel utilise un algorithme pour choisir la
carte à laquelle il va envoyer les paquets sortants. L’algorithme consiste à prendre
une valeur de données, à la diviser par le nombre de cartes d’EtherChannel et à
utiliser le reste (utiliser l’opérateur de modules) pour identifier le lien sortant. La
valeur Hash Mode détermine la valeur de données entrée dans cet algorithme
(reportez–vous à l’attribut Hash Mode pour une explication sur les différents
modes hash). Par exemple, si le mode Hash est standard, il utilise l’adresse
IP de destination du paquet. Si c’est 10.10.10.11 et qu’il y a 2 cartes dans
l’EtherChannel, (1 / 2) = 0 avec comme reste 1, la deuxième carte est utilisée
(les cartes sont numérotées à partir de 0). Les cartes sont numérotées dans l’ordre
indiqué dans le menu SMIT. C’est le mode de fonctionnement par défaut.
. round_robin : Dans ce mode, l’EtherChannel utilise tour à tour les cartes, en
envoyant un seul paquet à chaque carte avant de recommencer. les paquets
peuvent être envoyés dans un ordre légèrement différent que celui de leur envoi
à l’EtherChannel, mais l’utilisation de la bande passante est optimisée. Cette
combinaison n’est pas valable pour sélectionner ce mode avec un mode Hash
différent de default. Si vous sélectionnez le mode circulaire, laissez la valeur
Hash Mode sur default.
. netif_backup : Cette option est disponible uniquement dans AIX 5.1 et AIX 4.3.3.
Dans ce mode, l’EtherChannel active une seule carte à la fois. Le but est de
connecter les cartes à différents commutateurs Ethernet, chacun pouvant accéder
à n’importe quelle autre machine du sous–réseau ou du réseau. Lorsqu’un
problème lié à la connexion directe est détecté (ou facultativement parce qu’il est
impossible d’envoyer une commande ping à une machine), l’EtherChannel
désactive la carte en cours et active une carte de secours. Ce mode est le seul
qui utilise les champs Internet Address to Ping, Number of Retries, et Retry
Timeout.
Le mode Network Interface Backup Mode n’existe pas en tant que mode explicite
dans AIX 5.2 et les versions supérieures. Pour activer le mode Network Interface
Backup dans AIX 5.2 et les versions supérieures, vous devez configurer une seule
carte dans l’EtherChannel principale et une carte de secours. Pour plus
d’informations, consultez la section Configuration de Network Interface Backup
page 4-232.
. 8023ad : Cette option permet d’utiliser le IEEE 802.3ad Link Aggregation Control
Protocol (LACP) pour une agrégation automatique de liaisons. Pour plus
d’informations concernant cette fonction, reportez–vous à IEEE 802.3ad Link
Aggregation page 4-243.
– Mode Hash : Vous pouvez choisir parmi les modes hash celui qui va déterminer
la valeur de données utilisée par l’algorithme pour déterminer la carte sortante :
. default : Dans ce mode hash, l’adresse IP de destination du paquet est utilisée
pour déterminer la carte sortante. Pour le trafic non–IP (par exemple ARP), le
dernier octet de l’adresse MAC de destination est utilisé pour effectuer le calcul.
Ce mode garantit que les paquets sont envoyés via l’EtherChannel dans l’ordre
dans lequel ils ont été reçus, mais il peut ne pas utiliser toute la bande passante.
. src_port : Dans ce mode hash, la valeur de port UDP ou TCP source du paquet
est utilisée pour déterminer la carte sortante. Si le paquet ne correspond pas au
trafic UDP ou TCP, le dernier octet de l’adresse IP de destination est utilisé. Si le
paquet ne correspond pas au trafic IP, le dernier octet de l’adresse MAC de
destination est utilisé.
Protocole TCP/IP
4-231
. dst_port : Dans ce mode hash, la valeur de port UDP ou TCP de destination du
paquet est utilisée pour déterminer la carte sortante. Si le paquet ne correspond
pas à du trafic UDP ou TCP, le dernier octet de l’IP de destination est utilisé.
Si le paquet ne correspond pas au trafic IP, le dernier octet de l’adresse MAC
de destination est utilisé.
. src_dst_port : Dans ce mode hash, les valeurs de port UDP ou TCP source et de
destination du paquet sont utilisées pour déterminer la carte sortante (à savoir, les
ports source et de destination sont ajoutés puis divisés par deux avant d’être
entrés dans l’algorithme). Si le paquet ne correspond pas à du trafic UDP ou TCP,
le dernier octet de l’IP de destination est utilisé. Si le paquet ne correspond pas au
trafic IP, le dernier octet de l’adresse MAC de destination est utilisé. Ce mode
permet une bonne distribution des paquets dans la plupart des situations, à la fois
pour les clients et les serveurs.
Remarque :
Ceci est une combinaison invalide pour la sélection du mode Hash
différente de default avec un mode round_robin. Pour plus
d’informations sur la distribution des paquets et l’équilibrage de
charge, reportez–vous aux options d’équilibrage de charge
page 4-235.
– Backup Adapter : Ce champ est facultatif. Indiquez la carte à utiliser comme carte
de secours EtherChannel. L’option de secours EtherChannel est disponible dans AIX
5.2 et les versions supérieures.
– Internet Address to Ping : Cette zone est facultative et ne prend effet que si vous
activez le mode Network Interface Backup ou si vous n’avez qu’une carte dans
l’EtherChannel et une carte de secours. L’EtherChannel lance une commande ping
sur l’adresse IP ou le nom de l’hôte indiqué ici. Si l’EtherChannel ne parvient pas à
lancer une commande ping pour cette adresse pour Number of Retries dans les
intervalles Retry Timeout, l’EtherChannel effectue un basculement des cartes.
– Number of Retries : Entrez le nombre d’échecs de réponses ping autorisés avant
que l’EtherChannel ne change de cartes. La valeur par défaut est 3. Ce champ est
facultatif et valide uniquement si vous avez défini une Internet Address to Ping.
– Retry Timeout : Entrez le nombre de secondes entre les envois de commande ping
de l’EtherChannel portant sur Internet Address to Ping. La valeur par défaut est une
seconde. Ce champ est facultatif et valide uniquement si vous avez défini une
Internet Address to Ping.
5. Appuyez sur Entrée après avoir modifié les champs voulus pour créer l’EtherChannel.
6. Configurez IP via la nouvelle unité EtherChannel en tapant smit chinet dans la ligne
de commande.
7. Sélectionnez votre nouvelle interface EtherChannel dans la liste.
8. Remplissez tous les champs requis et appuyez sur Entrée.
Configuration de Network Interface Backup
Network Interface Backup offre une protection contre un point de défaillance réseau unique
en permettant la détection des défaillances et la prise de relais, sans interruption des
connexions utilisateur. Dans ce mode, une seule carte est active à un moment donné. En
cas de défaillance de la carte active, une autre carte de l’EtherChannel est utilisée pour tout
le trafic. En mode Network Interface Backup, il n’est pas nécessaire d’établir une connexion
aux commutateurs adaptés à EtherChannel.
La configuration de Network Interface Backup est plus efficace lorsque les cartes sont
connectées à différents commutateurs réseau, car ceci permet de bénéficier d’une meilleure
redondance que la connexion de toutes les cartes à un seul commutateur. Lors de la
connexion à différents commutateurs, assurez–vous qu’il existe une connexion entre les
commutateurs. Ceci fournit des fonctions de prise de relais d’une carte à l’autre en veillant à
ce qu’il existe toujours un accès à la carte active.
4-232
Guide de gestion du système – Communications et réseaux
Dans les éditions antérieures à AIX 5.2, le mode Network Interface Backup a été
implémenté en tant que mode explicite de fonctionnement dans le menu EtherChannel
SMIT. Dans AIX 5.2 et les versions supérieures, la carte de secours fournit une fonction
équivalente et ce mode a donc été supprimé du menu SMIT.
En outre, AIX 5.2 et les versions supérieures indiquent la priorité, c’est–à–dire que la carte
configurée dans l’EtherChannel principal est utilisée en priorité par rapport à la carte de
secours. Tant que la carte principale est fonctionnelle, elle sera utilisée. Ceci s’oppose au
comportement du mode Network Interface Backup dans les versions antérieures à AIX 5.2,
dans lesquelles la carte de secours était utilisée jusqu’à sa défaillance, que la carte
principale soit ou non déjà rétablie.
Par exemple, ent0 peut être configuré comme carte principale et ent2 comme carte de
secours, créant ainsi un EtherChannel appelé ent3. Idéalement, ent0 et ent2 sont
connectés à deux commutateurs différents. Dans cet exemple, tout le trafic envoyé via en3
(l’interface de l’EtherChannel) est envoyé via ent0 par défaut et ent2 reste inactif. Si, à
un moment donné, ent0 échoue, tout le trafic est envoyé via la carte de secours ent2.
Lorsque ent0 est rétablie, elle est à nouveau utilisée pour tout le trafic.
Tout en fonction en mode Network Interface Backup, il est aussi possible de configurer
l’EtherChannel pour détecter la défaillance de la liaison et l’inaccessibilité du réseau. Pour
ce faire, indiquez l’adresse IP ou le nom de l’hôte pour un hôte distant auquel la connexion
doit toujours être établie. L’EtherChannel lance régulièrement une commande ping sur cet
hôte pour déterminer s’il existe toujours un chemin réseau permettant d’y accéder. Si un
certain nombre de tentatives de commande ping restent sans réponse, l’EtherChannel
bascule vers l’autre carte, dans l’éventualité où il existerait un chemin d’accès réseau à
l’hôte distant via l’autre carte. Dans cette configuration, non seulement chaque carte doit
être connectée à un commutateur différent, mais chaque commutateur doit avoir un chemin
d’accès différent à l’hôte recevant la commande ping.
La commande ping est disponible uniquement en mode Network Interface Backup.
Toutefois, dans AIX 5.2 et les versions supérieures, s’il y a une prise de relais due à des
commandes ping restées sans réponse sur la carte principale, la carte de secours demeure
le canal actif tant que cela fonctionne. Il n’y a aucun moyen de savoir, lorsque tout
fonctionne via la carte de secours, s’il est possible d’accéder à l’hôte à qui le système a
envoyé une commande ping depuis la carte principale. Pour éviter des prises de relais
fréquentes entre la carte principale et celle de secours, le système continue de fonctionner
sur la carte de secours (sauf si les commandes ping restent également sans réponse sur la
carte de secours ou si la carte de secours elle–même échoue, auquel cas le système
bascule sur la carte principale). Toutefois, si la prise de relais a eu lieu en raison de l’échec
de la carte principale (mais pas parce que les commandes ping sont restées sans réponse),
l’EtherChannel revient à la carte principale dès que celle–ci est de nouveau disponible.
Pour configurer Network Interface Backup dans AIX 5.2, reportez–vous à Configure
Network Interface Backup dans AIX 5.2 et dans les versions supérieures page 4-233.
Pour configurer Network Interface Backup dans les versions précédentes d’AIX,
reportez–vous à l’Annexe D. Configuration de Network Interface Backup dans
les versions précédentes d’AIX page D-1.
Configuration de Network Interface Backup dans AIX 5.2 et versions supérieures
1. Avec les droits root, tapez smit etherchannel sur la ligne de commande.
2. Sélectionnez Add an EtherChannel / Link Aggregation dans la liste et appuyez
sur Entrée.
3. Sélectionnez la carte Ethernet principale et appuyez sur Entrée.
C’est la carte qui est utilisée tant qu’elle n’a pas de défaillance.
Remarque :
Cartes réseau disponibles affiche toutes les cartes Ethernet. Si vous
sélectionnez une carte Ethernet déjà utilisée, vous obtenez un message
d’erreur et devrez détacher l’interface avant de l’utiliser. Reportez–vous
à la commande ifconfig pour savoir comment détacher une interface.
Protocole TCP/IP
4-233
4. Entrez les informations dans les champs en respectant les consignes suivantes :
– Cartes EtherChannel / Link Aggregation : Vous devez voir s’afficher la carte
principale sélectionnée à l’étape précédente.
– Enable Alternate Address : Ce champ est facultatif. Le choix de la valeur yes vous
permet de préciser une adresse MAC que l’EtherChannel doit utiliser. Si vous
définissez la valeur no pour cette option, l’EtherChannel utilisera l’adresse MAC de la
carte principale.
– Alternate Address : Si vous attribuez à Enable Alternate Address la valeur yes,
indiquez l’adresse MAC à utiliser ici. L’adresse indiquée doit commencer par 0x et
être une valeur hexadécimale à 12 chiffres (par exemple 0x001122334455).
– Enable Gigabit Ethernet Jumbo Frames : Ce champ est facultatif. Pour l’utiliser, le
commutateur doit prendre en charge les trames jumbo. Ceci fonctionne uniquement
avec une interface Ethernet Standard (en) mais pas avec une interface IEEE 802.3.
Affectez la valeur yes si vous voulez l’activer.
– Mode : Le mode de fonctionnement que vous sélectionnez n’a pas d’importance car il
n’existe qu’une seule carte dans l’EtherChannel principal. Tous les paquets sont
envoyés via cette carte jusqu’à ce qu’elle ait une défaillance. Il n’existe pas de mode
netif_backup car ce mode peut être émulé via une carte de secours.
– Mode Hash : Le mode hash que vous sélectionnez n’a pas d’importance car il
n’existe qu’une seule carte dans l’EtherChannel principal. Tous les paquets sont
envoyés via cette carte jusqu’à ce qu’elle ait une défaillance.
– Backup Adapter : Indiquez la carte à utiliser comme carte de secours. A la suite
d’une prise de relais, cette carte est utilisée jusqu’à ce que la carte principale soit
rétablie. Il est conseillé d’utiliser la carte de prédilection comme carte principale.
– Internet Address to Ping : Ce champ est facultatif. L’EtherChannel lance une
commande ping sur l’adresse IP ou le nom de l’hôte indiqué ici. Si l’EtherChannel ne
parvient pas à lancer une commande ping sur cette adresse pour Number of Retries
dans les intervalles Retry Timeout, l’EtherChannel effectue un basculement des
cartes.
– Number of Retries : Entrez le nombre d’échecs de réponses ping autorisés avant
que l’EtherChannel ne change de cartes. La valeur par défaut est 3. Ce champ est
facultatif et valide uniquement si vous avez défini une Internet Address to Ping.
– Retry Timeout : Entrez le nombre de secondes entre les envois de commande ping
de l’EtherChannel à Internet Address to Ping. La valeur par défaut est une
seconde. Ce champ est facultatif et valide uniquement si vous avez défini une
Internet Address to Ping.
5. Appuyez sur Entrée après avoir modifié les champs voulus pour créer l’EtherChannel.
6. Configurez IP via la nouvelle interface en tapant smit chinet dans la ligne de
commande.
7. Sélectionnez votre nouvelle interface EtherChannel dans la liste.
8. Remplissez tous les champs requis et appuyez sur Entrée.
Pour savoir quelles sont les autres tâches à exécuter une fois l’EtherChannel configuré,
reportez–vous à Managing EtherChannel et de IEEE 802.3ad Link Aggregation,
page 4-238.
4-234
Guide de gestion du système – Communications et réseaux
Options d’équilibrage de charge
Il existe deux méthodes d’équilibrage de charge pour le trafic sortant de l’EtherChannel,
qui sont les suivantes : la méthode circulaire, qui répartit le trafic sortant de façon équitable
entre toutes les cartes de l’EtherChannel et la méthode standard, qui sélectionne la carte
via l’utilisation d’un algorithme. Le paramètre Hash Mode détermine la valeur numérique
entrée dans l’algorithme.
Le tableau suivant reprend les combinaisons d’option d’équilibrage de charge valides
proposées.
Table 16. Combinaisons Mode et Mode de hachage et distributions de trafic sortant que
chacune d’elle produit.
Mode
Mode Hash
Distribution du trafic
sortant
standard ou 8023ad
par défaut
Comportement traditionnel
de AIX. L’algorithme de
sélection de la carte utilise le
dernier octet de l’adresse IP
de destination (pour le trafic
TCP/IP) ou de l’adresse
MAC (pour le trafic ARP et
le trafic non–IP). Ce mode
est généralement un bon
choix de départ pour un
serveur ayant un grand
nombre de clients.
standard ou 8023ad
src_dst_port
Le chemin d’accès sortant
de la carte est sélectionné
par un algorithme utilisant
les valeurs de ports TCP ou
UDP source et destination.
Puisque chaque connexion
possède un port TCP ou
UDP unique, les modes
hash à trois ports offrent une
flexibilité de distribution de
carte supplémentaire
lorsqu’il existe plusieurs
connexions TCP ou UDP
séparées dans la paire
d’adresse IP.
standard ou 8023ad
src_port
L’algorithme de sélection de
la carte utilise la valeur de
port TCP ou UDP source.
Dans la sortie de commande
netstat –an, le port est la
valeur de suffixe d’adresse
TCP/IP dans la colonne
Local.
Protocole TCP/IP
4-235
Mode
Mode Hash
Distribution du trafic
sortant
standard ou 8023ad
dst_port
Le chemin d’accès sortant
de la carte est sélectionné
par l’algorithme en utilisant
la valeur de port du système
de destination. Dans la
sortie de commande netstat
–an, le suffixe d’adresse
TCP/IP dans la colonne
Foreign est la valeur de
port de destination TCP ou
UDP.
circulaire
par défaut
Le trafic sortant est réparti
équitablement entre tous les
ports de cartes de
l’EtherChannel. Ce mode est
généralement choisi par
deux hôtes connectés
back–to–back (sans
l’intervention d’un
commutateur).
Circulaire (round–robin)
Tout le trafic sortant est réparti équitablement entre toutes les cartes de l’EtherChannel.
Cela permet l’optimisation de la bande passante supérieure pour le système de serveur
AIX. Alors que la distribution circulaire est le moyen idéal d’utiliser équitablement toutes les
liaisons, tenez compte du fait qu’elle introduit la possibilité d’obtenir des paquets dans le
désordre dans le système de réception.
En général, le mode circulaire est idéal pour des connexions back–to–back exécutant les
trames jumbo. Dans cet environnement, aucun commutateur n’intervient, il n’y a donc
aucun risque que le traitement par le commutateur modifie l’heure de livraison du paquet,
l’ordre ou le chemin d’accès de la carte. Dans ce chemin d’accès réseau câblé direct, les
paquets sont reçus exactement comme ils sont envoyés. Les trames jumbo (MTU 9000
octets) génèrent toujours une performance de transfert de fichiers supérieure aux
traditionnels MTU 1500 octets. Dans ce cas, toutefois, ils présentent un autre avantage.
Ces paquets plus gros sont plus longs à envoyer, il est donc moins probable que l’hôte
récepteur soit continuellement interrompu par des paquets dans le désordre.
Le mode circulaire peut être implémenté dans d’autres environnements mais comporte un
risque plus élevé de désordre dans les paquets dans le système récepteur. Ce risque est
particulièrement élevé lorsqu’il y a une minorité de connexions TCP fluctuantes et de longue
durée. Lorsqu’il existe plusieurs connexions de ce genre dans une paire d’hôtes, les
paquets venant de différentes connexions peuvent être mélangés, ce qui réduit le risque
que les paquets d’une même connexion arrivent dans le désordre. Recherchez les
statistiques de paquets dans le désordre dans la section tcp de la sortie de commande
netstat –s. Une valeur augmentant constamment indique un éventuel problème dans le
trafic envoyé depuis un EtherChannel.
Si des paquets dans le désordre posent problème dans un système devant utiliser des MTU
Ethernet traditionnels et devant être connecté via un commutateur, essayez les différents
modes hash proposés en fonctionnement en mode standard. Chaque mode présente des
avantages, mais les modes par défaut et src_dst_port sont des points de départ logiques
car ils sont plus facilement applicables.
4-236
Guide de gestion du système – Communications et réseaux
Standard ou 8023ad
Algorithme standard. L’algorithme standard est utilisé à la fois pour les agrégations de
liaisons standard et de type IEEE 802.3ad. AIX divise le dernier octet de la ”valeur
numérique” par le nombre de cartes de l’EtherChannel et utilise le reste pour identifier la
liaison sortante. Si le reste est zéro, c’est la première carte de l’EtherChannel qui est
sélectionnée ; un reste de 1 signifie que c’est la deuxième carte qui est sélectionnée, ainsi
de suite (les cartes sont sélectionnées selon l’ordre dans lequel elle sont répertoriées dans
les attributs adapter_names).
La sélection du mode hash détermine la valeur numérique utilisée dans le calcul. Par
défaut, c’est le dernier octet de l’adresse IP ou MAC de destination qui est utilisé dans le
calcul, mais les valeurs de ports TCP ou UDP source et de destination peuvent également
être utilisées. Ces alternatives vous permettent de régler avec précision la distribution du
trafic sortant via les cartes réelles de l’EtherChannel.
Dans le mode hash par défaut, l’algorithme de sélection de la carte s’applique au dernier
octet de l’adresse IP de destination pour le trafic IP. Pour le trafic ARP et non IP, la même
formule s’applique au dernier octet de l’adresse MAC de destination. Sauf si une défaillance
de la carte provoque une prise de relais, tout le trafic existant entre une paire d’hôtes en
mode standard par défaut sort via la même carte. Le mode hash par défaut est idéal
lorsque le l’hôte local établit des connexions à différentes adresses IP.
Si l’hôte local établit des connexions longues à une minorité d’adresses IP, vous
remarquerez que certaines cartes portent une charge plus grande que d’autres parce que
tout le trafic envoyé à une destination spécifique est envoyé via la même carte. Tandis que
cela empêche les paquets d’arriver dans le désordre, il se peut que le système n’utilise pas
la bande passante de la manière la plus efficace dans tous les cas. Les modes hash basés
sur le port continuent d’envoyer les paquets dans l’ordre, mais ils autorisent des paquets,
appartenant à différentes connexions UDP ou TCP et même s’ils sont envoyés vers la
même destination, à être envoyés via différentes cartes, utilisant ainsi la bande passante de
chaque carte de manière plus efficace.
Dans le mode hash src_dst_port, les valeurs de port TCP ou UDP source et de destination
du paquet sortant sont ajoutées puis divisées par deux. Le nombre entier (non décimal) qui
en résulte est entré dans l’algorithme standard. Le trafic TCP ou UDP est envoyé sur la
carte sélectionnée par l’algorithme standard et la valeur de mode hash sélectionnée. Le
trafic non TCP ou UDP reviendra au mode hash par défaut, c’est–à–dire au dernier octet de
l’adresse IP ou MAC de destination. L’option mode hash src_dst_port tient compte à la fois
des valeurs de port TCP ou UDP source et de destination. Dans ce mode, tous les paquets
d’une connexion TCP or UDP sont envoyés via une seule carte afin de garantir leur arrivée
dans l’ordre, mais le trafic continue d’être réparti parce que les connexions (même celles
vers le même hôte) peuvent être envoyées via différentes cartes. Les résultats de ce mode
hash ne sont pas biaisés par la direction de l’établissement de la connexion parce que les
valeurs de port TCP ou UDP source et de destination sont utilisées.
Dans le mode hash src_port, la valeur de port TCP ou UDP source du paquet sortant est
utilisée. Dans le mode hash dst_port, la valeur de port TCP ou UDP de destination du
paquet sortant est utilisée. Utilisez les options mode hash src_port ou dst_port si les
valeurs de port changent d’une connexion à l’autre et si l’option src_dst_port ne génère
pas de distribution souhaitable.
Protocole TCP/IP
4-237
Gestion d’EtherChannel et de IEEE 802.3ad Link Aggregation
Cette section vous indique comment exécuter les tâches suivantes :
• Affichage de la liste des EtherChannels ou des Link Aggregations, page 4-238
• Modification de l’adresse de remplacement, page 4-238
• Ajout, suppression ou changement des cartes dans un EtherChannel ou Link
Aggregation, page 4-239
• Suppression d’un EtherChannel ou d’un Link Aggregation, page 4-241
• Configuration ou suppression d’une carte de secours sur un EtherChannel
ou un Link Aggregation existant, page 4-241
Affichage de la liste des EtherChannels ou des Link Aggregations
1. Sur la ligne de commande, tapez smit etherchannel.
2. Sélectionnez List All EtherChannels / Link Aggregations et appuyez sur Entrée.
Modification de l’adresse de remplacement
Ceci vous permet d’indiquer une adresse MAC pour votre EtherChannel ou Link
Aggregation.
1. Sur AIX 5.2 version 5200–01 et les versions antérieures, tapez ifconfig interface
detach, où interface désigne votre interface EtherChannel ou Link Aggregation.
(Sur AIX 5L version 5200–03 et les versions supérieures, vous pouvez modifier l’adresse
de remplacement de l’EtherChannel sans détacher son interface).
2. Sur la ligne de commande, tapez smit etherchannel.
3. Sélectionnez Change / Show Characteristics of an EtherChannel et appuyez
sur Entrée.
4. Si vous avez plusieurs EtherChannels, sélectionnez celui pour lequel vous voulez
créer une adresse de remplacement.
5. Remplacez la valeur de Enable Alternate EtherChannel Address par yes.
6. Entrez l’adresse de remplacement dans le champ Alternate EtherChannel Address.
L’adresse doit commencer par 0x et être une valeur hexadécimale à 12 chiffres
(par exemple, 0x001122334455).
7. Appuyez sur Entrée pour exécuter la procédure.
Remarque :
Changer l’adresse MAC de l’EtherChannel pendant la durée d’exécution
peut entraîner une perte temporaire de la connexion. Cela est peut–être
dû au fait que les cartes doivent être réinitialisées pour mémoriser leur
nouvelle adresse matérielle et que l’initialisation de certaines cartes
prend quelques secondes.
Dynamic Adapter Membership
Dans les versions antérieures à AIX 5L version 5200–03, pour ajouter ou supprimer une
carte de l’EtherChannel, son interface devait d’abord être détachée, interrompant ainsi
temporairement tout le trafic utilisateur. Pour remédier à cette restriction, Dynamic Adapter
Membership (DAM) a été introduit dans AIX 5L version 5200–03. Il permet aux cartes d’être
ajoutées ou supprimées de l’EtherChannel sans interrompre les connexions utilisateur. Une
carte de secours peut également être ajoutée ou supprimée ; un EtherChannel peut être
initialement créé sans carte de secours et il est possible d’en ajouter une ultérieurement
si besoin.
4-238
Guide de gestion du système – Communications et réseaux
Non seulement il est possible d’ajouter et de supprimer des cartes sans interrompre les
connexions utilisateur, mais il est également possible de modifier la plupart des attributs de
l’EtherChannel pendant la durée d’exécution. Par exemple, vous pouvez commencer en
utilisant la fonction ”ping” de Network Interface Backup quand l’EtherChannel est en cours
d’utilisation, ou modifier l’hôte distant sur lequel s’effectue une commande ping depuis un
point quelconque.
Vous pouvez également transformer un EtherChannel normal en un IEEE 802.3ad Link
Aggregation (ou inversement), permettant aux utilisateurs d’employer cette fonction sans
devoir supprimer et recréer l’EtherChannel.
En outre, avec DAM, vous pouvez créer un EtherChannel à une seule carte. Un
EtherChannel à une seule carte se comporte exactement comme une carte normale ;
toutefois, si cette carte est défaillante, il est possible de la remplacer pendant la durée
d’exécution sans perdre la connexion. Pour ce faire, ajoutez une carte temporaire à
l’EtherChannel, ôtez la carte défectueuse de l’EtherChannel, remplacez la carte
défectueuse par une carte qui fonctionne et utilise la connexion à chaud, ajoutez la nouvelle
carte à l’EtherChannel puis ôtez la carte temporaire. Durant ce processus, vous ne
percevez aucune perte de connexion. Si la carte fonctionne en tant que carte autonome,
elle doit être détachée avant d’être supprimée via la connexion à chaud et pendant ce
temps, tout le trafic passant par elle est perdu.
Ajout, suppression ou changement de cartes dans un EtherChannel
ou Link Aggregation
Il existe deux méthodes pour ajouter, supprimer ou modifier une carte de l’EtherChannel
ou de Link Aggregation. La première méthode suppose le détachement de l’interface
EtherChannel ou Link Aggregation, ce qui n’est pas le cas de la seconde (elle utilise
Dynamic Adapter Membership, disponible dans AIX 5L version 5200–03 et supérieures).
Modifier un EtherChannel à l’aide de Dynamic Adapter Membership
Effectuer des modifications à l’aide de Dynamic Adapter Membership n’exige pas que vous
interrompiez tout le trafic passant par l’EtherChannel en détachant son interface. Tenez
compte des points suivants avant de continuer :
Remarques :
1. Lorsque vous ajoutez une carte pendant la durée d’exécution, notez que différentes
cartes Ethernet prennent en charge différentes capacités (par exemple, celle d’effectuer
le déchargement du total de contrôle, celle d’utiliser des segments privés, celle
d’effectuer un envoi important, etc.). Si différents types de cartes sont utilisés dans le
même EtherChannel, les capacités relatives à la couche d’interface sont celles qui sont
prises en charge par toutes les cartes (par exemple, si toutes les cartes sauf une
prennent en charge l’utilisation de segments privés, l’EtherChannel indique qu’il ne
prend pas les segments privés en charge ; si toutes les cartes prennent en charge les
envois importants, le canal indique qu’il prend en charge un envoi important). Lorsque
vous ajoutez une carte à l’EtherChannel pendant la durée d’exécution, assurez–vous
qu’elle prend en charge au moins les mêmes capacités que les autres cartes de
l’EtherChannel. Si vous essayez d’ajouter une carte qui ne prend pas en charge toutes
les capacités de l’EtherChannel, l’ajout échoue. Notez toutefois que si l’interface de
l’EtherChannel est détachée, vous pouvez ajouter n’importe quelle carte (quelle que soit
sa capacité de prise en charge) et que lorsque l’interface est réactivée, l’EtherChannel
recalcule les capacités qu’elle prend en charge, sur la base de la nouvelle liste de
cartes.
2. Si vous n’utilisez pas d’adresse de remplacement et que vous avez prévu de supprimer
la carte dont l’adresse MAC a été utilisée pour l’EtherChannel (l’adresse MAC utilisée
pour l’EtherChannel ”appartient” à l’une des cartes), l’EtherChannel utilise l’adresse
MAC pour la prochaine carte disponible (en d’autres termes, celle qui devient la
première carte après la suppression, ou la carte de secours si toutes les cartes
principales ont été supprimées). Par exemple, si un EtherChannel possède plusieurs
cartes ent0 et ent1 et une carte de secours ent2, il utilisera par défaut l’adresse
Protocole TCP/IP
4-239
MAC deent0 (on dira que ent0 ”possède” l’adresse MAC). Si ent0 est supprimée,
l’EtherChannel utilisera l’adresse MAC de ent1. Si ent1 est supprimée, l’EtherChannel
utilisera alors l’adresse MAC de ent2. Si ent0 est de nouveau ajoutée à
l’EtherChannel ultérieurement, celui–ci continuera d’utiliser l’adresse MAC de ent2
parce que c’est maintenant ent2 qui possède l’adresse MAC. Si ent2 est ensuite
supprimé de l’EtherChannel, celui–ci va recommencer à utiliser l’adresse MAC de ent0.
La suppression de la carte dont l’adresse MAC était utilisée pour l’EtherChannel peut
provoquer une perte temporaire de connexion parce que toutes les cartes de
l’EtherChannel doivent être réinitialisées afin de mémoriser leur nouvelle adresse
matérielle. Certaines cartes sont initialisées en quelques secondes.
Si votre EtherChannel utilise une adresse de remplacement (une adresse MAC que vous
avez indiquée), il continuera d’utiliser cette adresse MAC quelles que soient les cartes
ajoutées ou supprimées. En outre, cela signifie qu’il n’y a aucune perte temporaire de
connexion lorsque vous ajoutez ou supprimez des cartes parce qu’aucune des cartes ne
”possède” l’adresse MAC de l’EtherChannel.
3. Presque tous les attributs de l’EtherChannel peuvent désormais être modifiés pendant la
durée d’exécution. La seule exception est Enable Gigabit Ethernet Jumbo Frames.
Afin de modifier les attributs Enable Gigabit Ethernet Jumbo Frames, vous devez
d’abord détacher l’interface de l’EtherChannel avant d’essayer de modifier cette valeur.
4. Pour tous les attributs qui ne peuvent être modifiés pendant la durée d’exécution
(actuellement Enable Gigabit Ethernet Jumbo Frames uniquement), il existe une zone
appelée Effectuer les modifications dans la BASE DE DONNEES uniquement. Si cet
attribut est défini sur yes, il est possible de changer, pendant la durée d’exécution, la
valeur d’un attribut qui ne peut habituellement pas être modifié pendant la durée
d’exécution. Si la zone Effectuer les modifications dans la BASE DE DONNEES
uniquement est définie sur yes, l’attribut est modifié uniquement dans ODM et n’est
pas réfléchi dans l’EtherChannel en cours d’exécution tant qu’il n’est pas rechargé dans
la mémoire (en détachant son interface et en utilisant les commandes rmdev –l
EtherChannel_device et mkdev –l EtherChannel_device ) ou tant que la
machine n’est pas redémarrée. Ceci est une manière pratique de s’assurer que l’attribut
est modifié au prochain démarrage de la machine, sans devoir interrompre
l’EtherChannel en cours d’exécution.
Pour modifier l’EtherChannel ou le Link Aggregation à l’aide de Dynamic Adapter
Membership, procédez comme suit :
1. Dans la ligne de commande, tapez smit etherchannel.
2. Sélectionnez Change / Show Characteristics of an EtherChannel / Link
Aggregation.
3. Sélectionnez l’EtherChannel ou le Link Aggregation à modifier.
4. Renseignez les zones requises en respectant les consignes suivantes :
– Dans la zone Ajouter la carte ou Supprimer la carte, sélectionnez la carte Ethernet
que vous voulez ajouter ou supprimer.
– Dans les zones Ajouter la carte de secours ou Supprimer la carte de secours,
sélectionnez la carte Ethernet que vous voulez ou ne voulez plus utiliser comme
carte de secours.
– Presque tous les attributs de l’EtherChannel peuvent être modifiés pendant la durée
d’exécution, bien que les attributs Enable Gigabit Ethernet Jumbo Frames ne
puissent pas l’être.
– Pour transformer un EtherChannel normal en un IEEE 802.3ad Link Aggregation,
modifiez l’attribut de Mode en 8023ad. Pour transformer un IEEE 802.3ad Link
Aggregation en un EtherChannel, modifiez l’attribut Mode en standard ou
round_robin.
5. Remplissez toutes les données requises et appuyez sur Entrée.
4-240
Guide de gestion du système – Communications et réseaux
Effectuer des modifications sur AIX 5.2 version 5200–01 et les versions antérieures
Procédez comme suit pour détacher l’interface avant d’effectuer les modifications :
1. Tapez ifconfig interface detach, où interface désigne votre interface
EtherChannel.
2. Sur la ligne de commande, tapez smit etherchannel.
3. Sélectionnez Change / Show Characteristics of an EtherChannel /Link Aggregation
et appuyez sur Entrée.
4. Sélectionnez l’EtherChannel ou le Link Aggregation à modifier.
5. Modifiez les attributs que vous voulez changer dans votre EtherChannel ou Link
Aggregation et appuyez sur Entrée.
6. Remplissez tous les champs requis et appuyez sur Entrée.
Suppression d’un EtherChannel ou d’un Link Aggregation
1. Tapez ifconfig interface detach, où interface désigne votre interface
EtherChannel.
2. Sur la ligne de commande, tapez smit etherchannel.
3. Sélectionnez Remove an Etherchannel et appuyez sur Entrée.
4. Sélectionnez l’ EtherChannel que vous souhaitez supprimer et appuyez sur Entrée.
Configuration ou suppression d’une carte de secours sur un EtherChannel
ou un Link Aggregation existant
La procédure suivante configure ou supprime une carte de secours sur un EtherChannel
ou Link Aggregation. L’option est disponible uniquement dans AIX 5.2 et les versions
supérieures.
1. Tapez ifconfig interface detach, où interface désigne votre interface
EtherChannel ou Link Aggregation.
2. Sur la ligne de commande, tapez smit etherchannel.
3. Sélectionnez Change / Show Characteristics of an EtherChannel / Link
Aggregation.
4. Sélectionnez l’EtherChannel ou Link Aggregation sur lequel vous ajoutez ou modifiez
la carte de secours.
5. Entrez la carte à utiliser comme carte de secours dans le champ Backup Adapter
ou sélectionnez NONE si vous voulez cesser d’utiliser la carte de secours.
Identification des incidents d’EtherChannel
En cas de problème avec l’EtherChannel, envisagez les points suivants :
Suivi d’EtherChannel
Utilisez tcpdump et iptrace pour identifier et résoudre les incidents liés à l’EtherChannel.
L’ID d’ancrage de trace pour les paquets de transmission est 2FA et 2FB pour les autres
événements. Vous ne pouvez pas effectuer le suivi de paquets sur l’EtherChannel tout
entier, mais pouvez suivre les points d’ancrage de suivi de réception de chaque carte.
Affichage des statistiques d’ EtherChannel
Utilisez la commande entstat pour obtenir l’agrégat des statistiques de toutes les cartes de
l’EtherChannel. Par exemple, entstat ent3 affichera l’agrégat des statistiques de ent3.
L’ajout de l’indicateur –d affiche également les statistiques de chaque carte. Par exemple,
la commande entstat –d ent3 affiche l’agrégat des statistiques de l’EtherChannel ainsi
que les statistiques de chaque carte de l’EtherChannel.
Protocole TCP/IP
4-241
Remarque :
Dans la section Statistiques générales, le chiffre indiqué dans
Adapter Reset Count est celui des prises de relais. Dans l’option de
secours d’EtherChannel, le retour à l’EtherChannel principal à partir de la
carte de secours n’est pas comptabilisé comme une prise de relais. Seule
une prise de relais à partir du canal principal au secours est comptabilisé.
Dans le champ Number of Adapters, la carte de secours est comptabilisée dans
le chiffre affiché.
Amélioration de la prise de relais lente
Si la prise de relais lorsque vous utilisez le mode Network Interface Backup ou l’option de
secours EtherChannel est lente, vérifiez que le commutateur n’exécute pas le protocole
STP (Spanning Tree Protocol). Lorsque le commutateur détecte une modification de son
équivalence port de commutateur/adresse MAC, il exécute l’algorithme STP pour voir s’il y a
des boucles dans le réseau. Network Interface Backup et l’option de secours EtherChannel
peuvent provoquer une modification de l’équivalence port/adresse MAC.
Les ports de commutation ont un compteur de retard de transmission qui détermine au bout
de combien de temps après l’initialisation chaque port doit commencer à retransmettre ou
envoyer des paquets. Pour cette raison, lorsque le canal principal est réactivé, il se produit
un retard avant le rétablissement de la connexion, tandis que la prise de relais par la carte
de secours est plus rapide. Vérifiez le compteur de retard de retransmission du
commutateur et indiquez une valeur aussi basse que possible afin de pouvoir revenir aussi
vite que possible au canal principal.
Pour que l’option de secours EtherChannel fonctionne correctement, le compteur de retard
de retransmission ne doit pas excéder 10 secondes ou le retour à l’EtherChannel principal
risque de ne pas se dérouler normalement. Il est conseillé d’affecter la valeur la plus basse
possible autorisée par le commutateur au compteur de retard de retransmission.
Les cartes ne prennent pas le relais
Si les défaillances des cartes ne déclenchent pas des prises de relais et si vous exécutez
AIX 5.2 version 5200–01 ou les versions antérieures, regardez si vos cartes ont besoin
d’activer le sondage de liaison pour détecter la défaillance de liaison. Certaines cartes ne
peuvent pas détecter automatiquement l’état de leur liaison. Pour détecter cet état, ces
cartes doivent activer un mécanisme de sondage de liaison qui démarre un compteur qui
vérifie régulièrement l’état de la liaison. Le sondage de liaison est désactivé par défaut.
Toutefois, pour qu’EtherChannel fonctionne correctement avec ces cartes, le mécanisme
de sondage de liaison doit être activé sur chaque carte avant que l’EtherChannel soit créé.
Si vous exécutez AIX 5L version 5200–03 et les versions supérieures, le mécanisme de
sondage est démarré automatiquement mais cela ne constitue pas une relance.
Les cartes possédant un mécanisme de sondage de liaison ont un attribut ODM appelé
poll_link, qui doit avoir la valeur yes pour que le sondage de liaison soit activé. Avant
de créer l’EtherChannel, lancez la commande suivante sur chaque carte à inclure :
smit chgenet
Remplacez la valeur de Enable Link Polling par yes puis appuyez sur Entrée.
Utilisation de trames jumbo
Pour que les options de trames jumbo fonctionnent correctement dans AIX 5.2 et les
versions antérieures, vous devez activer l’attribut use_jumbo_frame sur l’EtherChannel,
mais aussi les trames jumbo sur chaque carte avant de créer l’EtherChannel à l’aide
de la commande suivante :
smitty chgenet
Remplacez la valeur de Enable Jumbo Frames par yes, puis appuyez sur Entrée.
Sur AIX 5.2 et les versions antérieures, les trames jumbo sont activées automatiquement
dans chaque carte sous–jacente lorsqu’elle est définie sur yes.
4-242
Guide de gestion du système – Communications et réseaux
Vidage à distance
Le vidage à distance n’est pas pris en charge via un EtherChannel.
IEEE 802.3ad Link Aggregation
IEEE 802.3ad est une méthode standard permettant de créer un agrégat de liaisons. Sur le
plan conceptuel, il fonctionne de la même façon qu’EtherChannel : plusieurs cartes Ethernet
sont regroupées en une seule carte virtuelle, fournissant une bande passante plus élevée et
la protection contre les échecs. Par exemple, ent0 et ent1 peuvent être réunies dans un
IEEE 802.3ad Link Aggregation appelé interface ent3. L’interface en3 est alors configurée
avec une adresse IP. Le système considère cet agrégat de cartes comme une carte unique.
Par conséquent, IP est configuré via ces cartes comme s’il s’agissait d’une carte Ethernet
normale.
Comme EtherChannel, IEEE 802.3ad nécessite d’être pris en charge par le commutateur.
Toutefois, contrairement à EtherChannel, le commutateur n’a pas besoin d’être configuré
manuellement pour savoir quels ports appartiennent à la même agrégation.
Les avantages de IEEE 802.3ad Link Aggregation par rapport à EtherChannel sont le fait
qu’il créée automatiquement des agrégations de liaison dans le commutateur et qu’il
permette d’utiliser les commutateurs prenant en charge IEEE 802.3ad standard mais pas
EtherChannel.
Dans IEEE 802.3ad, le protocole Link Aggregation Control Protocol (LACP) indique
automatiquement au commutateur les ports qui doivent être regroupés en agrégat.
Lorsqu’un agrégat IEEE 802.3ad est configuré, des unités Link Aggregation Control
Protocol Data Units (LACPDU) sont échangées entre le serveur et le commutateur. LACP
prévient le commutateur que les cartes configurées dans l’agrégat doivent être considérées
comme une seule carte sur le commutateur sans autre intervention de l’utilisateur.
Bien que le spécification IEEE 802.3ad ne permette pas à l’utilisateur de choisir les cartes
qui doivent être regroupées en un agrégat, AIX permet à l’utilisateur de choisir les cartes.
Conformément à la spécification, LACP détermine de lui–même les cartes à regrouper en
un agrégat (en effectuant les agrégations de liaison de toutes les cartes ayant des vitesses
de liaison similaires et des paramètres doubles). Cela vous évite de décider des cartes à
utiliser de manière autonome et de déterminer les cartes à regrouper en un agrégat.
L’implémentation AIX vous permet de contrôler l’utilisation des cartes et ne crée jamais
d’agrégation de liaison arbitrairement.
Pour pouvoir être regroupées en un agrégat (c’est–à–dire que le commutateur leur
permettra d’appartenir au même agrégat), les cartes doivent avoir la même vitesse de ligne
(par exemple 100 Mbps ou tous les 1 Gbps) et utiliser toutes le mode de duplex intégral.
Si vous tentez de placer des cartes de vitesses différentes ou utilisant des modes duplex
différents, vous parviendrez à créer un agrégat sur le système, mais le commutateur risque
de ne pas créer l’agrégat des cartes. Si c’est le cas, vous remarquerez une baisse des
performances du réseau. Pour savoir si la création d’un agrégat a réussi, reportez–vous à
Identification des incidents IEEE 802.3ad, page 4-246.
Selon la spécification IEEE 802.3ad, les paquets envoyés à la même adresse IP sont tous
envoyés via la même carte. Ainsi, en mode 8023ad, les paquets seront toujours distribués
de façon standard, jamais circulaire (round–robin).
La carte de secours est disponible pour IEEE 802.3ad Link Aggregations de même que
pour EtherChannel. La carte de secours n’a pas besoin d’être connectée à un commutateur
IEEE 802.3ad, mais si elle l’est, la carte de secours continuera d’utiliser IEEE 802.3ad
LACP.
Vous pouvez aussi configurer un IEEE 802.3ad Link Aggregation si le commutateur prend
en charge EtherChannel mais pas IEEE 802.3ad. Dans ce cas, vous devrez configurer
manuellement les ports en tant qu’un EtherChannel sur le commutateur (tout comme si un
EtherChannel normal avait été créé). En définissant le mode à 8023ad, l’agrégat fonctionne
avec EtherChannel ainsi qu’avec les commutateurs IEEE 802.3ad–enabled.
Protocole TCP/IP
4-243
Pour plus d’informations sur l’interopérabilité, reportez–vous à la section Scénarios
d’interopérabilité, page 4-246.
Remarque :
Les étapes d’activation de l’utilisation de IEEE 802.3ad varient d’un
commutateur à l’autre. Consultez la documentation du commutateur pour
déterminer les étapes initiales, le cas échéant, qui doivent être effectuées
pour activer LACP sur le commutateur.
Pour plus d’informations sur la configuration et l’utilisation de IEEE 802.3ad Link
Aggregation, reportez–vous à Configuration de IEEE 802.3ad Link Aggregation,
page 4-244.
Remarques
Prenez en compte les éléments suivants avant de configurer IEEE 802.3ad Link
Aggregation :
• Bien qu’elle ne soit pas officiellement prise en charge, la mise en œuvre de IEEE
802.3ad sous AIX permet à Link Aggregation de contenir des cartes de différentes
vitesses de ligne ; toutefois, vous devez uniquement créer des agrégats de cartes ayant
la même vitesse et utilisant le mode duplex intégral. Ceci évite les problèmes potentiels
de configuration de Link Aggregation sur le commutateur. Reportez–vous à la
documentation du commutateur pour plus d’informations sur les types d’agrégats
autorisés par le commutateur.
• Si vous utilisez des cartes 10/100 Ethernet dans le Link Aggregation sur AIX 5.2 version
5200–01 et antérieures, vous devez activer le sondage de liaison sur ces cartes avant
de les ajouter à l’agrégat. Tapez smitty chgenet sur la ligne de commande.
Remplacez la valeur de Enable Link Polling par yes puis appuyez sur Entrée.
Procédez de cette façon pour chaque carte 10/100 Ethernet que vous ajoutez au Link
Aggregation.
Remarque :
Dans AIX 5L version 5200–03 et supérieures, l’activation du mécanisme
de sondage de liaison n’est pas nécessaire. Le sondeur de liaison est
démarré automatiquement.
Configuration de IEEE 802.3ad Link Aggregation
Procédez comme suit pour configurer un IEEE 802.3ad Link Aggregation :
1. Tapez smit etherchannel sur la ligne de commande.
2. Sélectionnez Add an EtherChannel / Link Aggregation dans la liste et appuyez
sur Entrée.
3. Sélectionnez les cartes Ethernet principales de Link Aggregation et appuyez sur Entrée.
Si vous prévoyez d’utiliser une carte de secours, ne sélectionnez pas la carte de secours
à ce stade. L’option de la carte de secours est disponible dans AIX 5.2 et les versions
supérieures.
Remarque :
Cartes réseau disponibles affiche toutes les cartes Ethernet.
Si vous sélectionnez une carte Ethernet déjà utilisée (dont l’interface
est définie), vous obtenez un message d’erreur. Vous devez d’abord
détacher ces interfaces si vous souhaitez les utiliser.
4. Entrez les informations dans les champs en respectant les consignes suivantes :
– Cartes EtherChannel / Link Aggregation : Vous devez voir s’afficher toutes les
cartes principales utilisées dans le Link Aggregation. Vous avez sélectionné ces
cartes à l’étape précédente.
– Enable Alternate Address : Ce champ est facultatif. Le choix de la valeur yes
vous permet de préciser une adresse MAC que le Link Aggregation doit utiliser. Si
vous définissez la valeur no pour cette option, le Link Aggregation utilisera l’adresse
MAC de la première carte indiquée.
4-244
Guide de gestion du système – Communications et réseaux
– Alternate Address : Si vous attribuez à Enable Alternate Address la valeur yes,
indiquez l’adresse MAC à utiliser ici. L’adresse indiquée doit commencer par 0x
et être une valeur hexadécimale à 12 chiffres (par exemple, 0x001122334455).
– Enable Gigabit Ethernet Jumbo Frames : Ce champ est facultatif. Pour l’utiliser, le
commutateur doit prendre en charge les trames jumbo. Ceci fonctionne uniquement
avec une interface Ethernet Standard (en) mais pas avec une interface IEEE 802.3.
Affectez la valeur yes si vous voulez l’activer.
– Mode : Entrez 8023ad.
– Mode Hash : Vous pouvez choisir parmi les modes hash celui qui va déterminer la
valeur de donnée utilisée par l’algorithme pour déterminer la carte sortante :
. default : Dans ce mode hash, l’adresse IP de destination du paquet est utilisée
pour déterminer la carte sortante. Pour le trafic non–IP (par exemple ARP), le
dernier octet de l’adresse MAC de destination est utilisé pour effectuer le calcul.
Ce mode garantit que les paquets sont envoyés via l’EtherChannel dans l’ordre
dans lequel ils ont été reçus, mais il peut ne pas utiliser toute la bande passante.
. src_port : Dans ce mode hash, la valeur de port UDP ou TCP source du paquet
est utilisée pour déterminer la carte sortante. Si le paquet n’est pas du trafic UDP
ou TCP, le dernier octet de l’adresse IP de destination est utilisé. Si le paquet n’est
pas du trafic IP, le dernier octet de l’adresse MAC de destination est utilisé.
. dst_port : Dans ce mode hash, la valeur de port UDP ou TCP de destination du
paquet est utilisée pour déterminer la carte sortante. Si le paquet n’est pas du
trafic UDP ou TCP, le dernier octet de l’IP de destination est utilisé. Si le paquet
n’est pas du trafic IP, le dernier octet de l’adresse MAC de destination est utilisé.
. src_dst_port : Dans ce mode hash, les valeurs de port UDP ou TCP source et de
destination du paquet sont utilisées pour déterminer la carte sortante (à savoir, les
ports source et de destination sont ajoutés puis divisés par deux avant d’être
entrés dans l’algorithme). Si le paquet n’est pas du trafic UDP ou TCP, le dernier
octet de l’IP de destination est utilisé. Si le paquet n’est pas du trafic IP, le dernier
octet de l’adresse MAC de destination est utilisé. Ce mode permet une bonne
distribution des paquets dans la plupart des situations, à la fois pour les clients
et les serveurs. Pour plus d’informations sur la distribution des paquets et
l’équilibrage de charge, reportez–vous aux options d’équilibrage de charge
page 4-235.
– Backup Adapter : Ce champ est facultatif. Indiquez la carte à utiliser comme carte
de secours. L’option de la carte de secours est disponible dans AIX 5.2 et les
versions supérieures.
– Internet Address to Ping : Ce champ est facultatif et n’est disponible que si vous
avez une seule carte dans l’agrégat et une carte de secours. Link Aggregation lance
une commande ping sur l’adresse IP ou le nom de l’hôte indiqué. Si Link Aggregation
ne parvient pas à lancer une commande ping sur cette adresse pour Number of
Retries dans les intervalles Retry Timeout, Link Aggregation effectue un
basculement des cartes.
– Number of Retries : Entrez le nombre d’échecs de réponses ping autorisés avant
que Link Aggregation ne change de cartes. La valeur par défaut est 3. Ce champ est
facultatif et valide uniquement si vous définissez Internet Address to Ping.
– Retry Timeout : Entrez le nombre de secondes entre les envois de commande ping
de Link Aggregation à Internet Address to Ping. La valeur par défaut est une
seconde. Ce champ est facultatif et valide uniquement si vous définissez Internet
Address to Ping.
5. Appuyez sur Entrée après avoir modifié les champs voulus pour créer le Link
Aggregation.
Protocole TCP/IP
4-245
6. Configurez IP via la nouvelle unité Link Aggregation en tapant smit chinet
sur la ligne de commande.
7. Sélectionnez votre nouvelle interface Link Aggregation dans la liste.
8. Remplissez tous les champs requis et appuyez sur Entrée.
Gestion de IEEE 802.3ad
Pour les tâches de gestion pouvant être exécutées sur un IEEE 802.3ad Link Aggregation
après la configuration, reportez–vous à Gestion d’EtherChannel et de IEEE 802.3ad Link
Aggregation, page 4-238.
Identification et résolution des incidents IEEE 802.3ad
Si des problèmes liés au IEEE 802.3ad Link Aggregation se produisent, lancez la
commande suivante pour vérifier le mode de fonctionnement de Link Aggregation :
entstat –d
device
où device est l’unité Link Aggregation.
Ceci permet également de déterminer le meilleur effort de l’état de la progression du LACP
basé sur les unités LACPDU reçues du commutateur. Les valeurs d’état possibles sont les
suivantes :
• Inactive: LACP n’a pas été initialisé. Dans cet état, un Link Aggregation n’a pas
encore été configuré, soit parce qu’il n’a pas encore reçu d’adresse IP soit parce que
son interface a été détachée.
• Negotiating: LACP est en cours, mais le commutateur n’a pas encore regroupé les
cartes en agrégat. Si le Link Aggregation conserve cet état plus d’une minute, vérifiez
que le commutateur est correctement configuré. Vérifiez par exemple que LACP est
activé sur les ports.
• Aggregated: LACP a réussi et le commutateur a regroupé les cartes dans un agrégat.
• Failed: LACP a échoué. Certaines des causes possibles sont que les cartes de
l’agrégat ont des vitesses de ligne ou des modes duplex différents ou qu’elles sont
connectées à des commutateurs différents. Vérifiez la configuration des cartes.
En outre, certains commutateurs permettent uniquement aux ports contigus d’être
regroupés et imposent parfois une limite au nombre de cartes pouvant être regroupées.
Consultez la documentation du commutateur pour connaître les limites éventuelles du
commutateur, puis vérifiez sa configuration.
Remarque :
L’état du Link Aggregation est une valeur de diagnostic et n’a pas
d’incidence sur le côté AIX de la configuration. Cette valeur d’état a été
calculée via une tentative de meilleur effort. Pour résoudre les autres
problèmes d’agrégat, il est conseillé de vérifier la configuration du
commutateur.
Scénarios d’interopérabilité
Le tableau suivant représente plusieurs scénarios d’interopérabilité. Prenez en compte
ces scénarios lorsque vous configurez un EtherChannel ou IEEE 802.3ad Link Aggregation.
Vous trouverez une explication supplémentaire de chaque scénario à la suite du tableau.
4-246
Guide de gestion du système – Communications et réseaux
Tableau 17. Différentes combinaisons de configuration d’AIX et de commutateur et résultats
obtenus pour chaque combinaison.
Mode EtherChannel
Configuration de
commutateur
Résultat
8023ad
IEEE 802.3ad LACP
OK – AIX lance des unités
LACPDU qui déclenchent un
IEEE 802.3ad Link
Aggregation sur le
commutateur.
standard ou round_robin
EtherChannel
OK – Résultats dans le
comportement
EtherChannel traditionnel.
8023ad
EtherChannel
OK – Résultats dans le
comportement
EtherChannel traditionnel.
AIX initialise des unités
LACPDU mais le
commutateur n’en tient pas
compte.
standard ou round_robin
IEEE 802.3ad LACP
Non souhaitable – Le
commutateur ne peut pas
former d’agrégat. Il peut en
résulter une performance
médiocre car le
commutateur transfère
l’adresse MAC entre les
ports du commutateur.
• 8023ad incluant IEEE 802.3ad LACP :
Il s’agit de la configuration IEEE 802.3ad la plus courante.
Ce commutateur peut être un LACP passif ou actif.
• standard ou round_robin avec EtherChannel :
Il s’agit de la configuration EtherChannel la plus courante.
• 8023ad avec EtherChannel :
Dans ce cas, AIX enverra les unités LACPDU mais elles n’obtiendront pas de réponse
car le commutateur opère comme un EtherChannel. Le fonctionnement sera cependant
correct car le commutateur continuera de traiter ces ports comme une liaison unique.
Remarque :
Dans ce cas, la commande entstat –d signalera toujours que
l’agrégat a l’état Negotiating.
• standard ou round_robin avec IEEE 802.3ad LACP :
Cette configuration est incorrecte. Si le commutateur utilise LACP pour créer un agrégat,
celui n’est jamais formé car AIX ne répond jamais aux unités LACPDU. Pour obtenir un
fonctionnement correct, définissez le mode 8023ad dans AIX.
Protocole TCP/IP
4-247
Protocole Internet (IP) par Fibre Channel
Les paquets IP peuvent être envoyés par connexion physique fibre–channel, en
commençant par AIX 5L avec 5200–03. Une fois qu’un système est configuré pour pouvoir
utiliser l’IP par Fibre Channel, son activité réseau fonctionne comme si une carte Ethernet
ou en anneau à jeton était utilisée.
Pour utiliser l’IP par Fibre Channel, votre système doit posséder un commutateur Fibre
Channel et la carte Fibre Channel 2 Gigabit pour bus PCI 64 bits ou la carte PCI–X 2
Gigabit Fibre Channel.
De plus, tous les fichiers suivants doivent être installés :
• devices.common.ibm.fc
• devices.pci.df1000f7
• devices.pci.df1080f9
• devices.pci.df1000f9
Configuration IP par Fibre Channel
La procédure suivante vous guide lors de la configuration d’une IP par Fibre Channel.
Le pilote d’unité IP Fibre Channel doit avant tout être désactivé. Après la désactivation,
la commande cfgmgr est activée afin de créer l’interface Fibre Channel. Après la création
de l’interface, il faut affecter les attributs réseau (tels son adresse IP, le masque réseau,
le nom du serveur et la passerelle).
Activer le pilote d’unité du Fibre Channel
L’unité IP Fibre Channel n’est pas activée par défaut. Pour activer l’unité,
procédez comme suit :
1. Sur la ligne de commande, entrez smit dev.
2. Sélectionnez carte FC.
3. Sélectionnez Unité de protocole réseau FC.
4. Sélectionnez Activer une unité réseau FC.
5. Sélectionnez la carte à activer.
6. Utilisez la commande cfgmgr pour créer l’interface Fibre Channel.
Voir cfgmgr dans le manuel AIX 5L Version 5.3 Commands Reference.
4-248
Guide de gestion du système – Communications et réseaux
Affectez les propriétés réseau à l’interface Fibre Channel.
Après avoir désactivé la carte, vous devez configurer l’IP via celle–ci.
Procédez comme suit pour configurer l’IP :
1. Sur la ligne de commande, entrez smit tcpip.
2. Sélectionnez Configuration minimale et lancement.
3. Sélectionnez l’interface que vous souhaitez configurer. Dans ce cas, il s’agit de fc x,
x étant le numéro mineur de l’interface.
4. Affectez tous les attributs requis.
Après avoir affecté les attributs IP, vérifiez que l’entrée en vigueur des modifications en
entrant la commande suivante sur la ligne de commande :
ifconfig –a
Si votre configuration a été effectuée correctement, des résultats similaires aux résultats
suivants sont obtenus :
fc1: flags=e000843
<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,PSEG,CHAIN
>
inet 11.11.11.18 netmask 0xffffff00 broadcast 11.11.11.255
Vous pouvez également exécuter la commande suivante :
ifconfig fc
x
x étant le numéro mineur de l’interface.
Protocole TCP/IP
4-249
Initiateur logiciel iSCSI
L’initiateur logiciel iSCSI permet à AIX d’accéder aux unités de stockage en utilisant TCP/IP
sur les cartes du réseau Ethernet. L’initiateur logiciel iSCSI implémente le protocole iSCSI
tel qu’il est défini dans iSCSI IETF draft–20.
L’utilisation de la technologie iSCSI, souvent désignée par SAN pour technologie IP,
permet le déploiement d’une zone de stockage gérant un réseau IP. iSCSI est une approche
ouverte, basée sur des standards, pour laquelle les informations SCSI sont encapsulées
par TCP/IP, afin de permettre le transport via des réseaux Ethernet et Gigabit Ethernet.
iSCSI permet à un réseau Ethernet existant de transférer des commandes et des données
SCSI en toute indépendance d’emplacement. Les solutions iSCSI utilisent les composantes
suivantes, différentes mais intégralement reliées entre elles :
• Initiateurs
Ce sont les pilotes d’unités résidant sur le client. Ils encapsulent les commandes SCSI
et les acheminent via le réseau IP à l’unité cible.
• Logiciel cible
Le logiciel reçoit les commandes SCSI encapsulées via le réseau IP. Le logiciel peut
aussi fournir le support de configuration et le support de gestion stockage.
• Matériel cible
Le matériel peut être un appareil de stockage contenant un stockage incorporé.
Le matériel peut également être une passerelle ou un produit pont ne contenant
aucun stockage interne par lui–même.
Configuration de l’initiateur logiciel iSCSI
L’initiateur de logiciel est configuré via SMIT comme suit :
1. Sélectionnez Unités.
2. Sélectionnez iSCSI.
3. Sélectionnez Configurer unité de protocole iSCSI.
4. Sélectionnez Modifier / Afficher les caractéristiques d’une unité de protocole iSCSI.
5. Vérifier que la valeur du Nom de l’initiateur est correcte. La valeur du Nom de
l’initiateur est utilisée par la cible iSCSI lors de la connexion.
Remarque :
Un nom d’initiateur par défaut est attribué lorsque le logiciel est installé.
Le nom de l’initiateur peut être modifié par l’utilisateur afin de le faire
correspondre à des conventions d’appellation d’un réseau local.
6. La zone Maximum de cibles autorisées correspond au nombre maximal de
cibles iSCSI pouvant être configurées. Si vous réduisez ce nombre, vous réduisez aussi
la capacité de mémoire du réseau, affectée au préalable au pilote du protocole iSCSI
lors de la configuration.
4-250
Guide de gestion du système – Communications et réseaux
Une fois l’initiateur du logiciel configuré, effectuez les actions suivantes :
1. Editez le fichier /etc/iscsi/targets pour inclure les cibles iSCSI nécessaires
à la configuration de l’unité.
Chaque ligne non commentée du fichier représente une cible iSCSI.
La configuration de l’unité iSCSI implique que les cibles iSCSI sont accessibles via une
interface réseau correctement configurée. Bien que l’initiateur de logiciel iSCSI puisse
fonctionner en utilisant 10/100 Ethernet LAN, il est conçu pour être utilisé avec un
réseau gigabit Ethernet séparé d’un autre trafic réseau.
Pour plus d’informations, reportez–vous au Fichier cibles dans AIX 5L Version 5.3
Files Reference.
2. Après édition du fichier /etc/iscsi/targets, saisissez la commande suivante :
cfgmgr –l iscsi0
Ceci reconfigure le pilote de l’initiateur du logiciel.
Cette commande active le pilote dans sa tentative de communiquer avec les cibles
listées dans le fichier /etc/iscsi/targets et de définir un nouveau hdisk pour chaque LUN
sur les cibles trouvées. Pour plus d’informations, reportez–vous à la description de la
commande cfgmgr dans AIX 5L Version 5.3 Commands Reference, Volume 1.
Remarque :
Si les disques appropriés ne sont pas définis, consultez la configuration
de l’initiateur, la cible, et toutes les passerelles iSCSI pour vous assurer
que tout est correct, puis réexécutez la commande cfgmgr.
Si vous souhaitez poursuivre la configuration des paramètres pour les unités du logiciel
iSCSI, utilisez SMIT comme suit :
1. Sélectionnez Unités.
2. Sélectionnez Disque fixe.
Un initiateur typique de logiciel est semblable à ce qui suit :
hdisk2
Disponible
Autre pilote disque iSCSI
Si le disque iSCSI prend en charge la mise en attente de la balise de commande et
NACA=1 dans l’octet de contrôle, modifiez la configuration de la profondeur de la mise en
attente du disque pour une valeur supérieure. Une valeur plus importante est susceptible
d’améliorer les performances de l’unité. La définition de la profondeur de mise en attente
optimale ne peut pas être supérieure à la mise en attente effective sur le pilote. Définir la
profondeur de mise en attente pour une valeur supérieure à la taille de mise en attente du
disque peut avoir des effets négatifs sur les performances. Pour déterminer la taille de la
mise en attente du disque, veuillez consulter la documentation.
Remarques supplémentaires
Veuillez tenir compte de ce qui suit pour toute utilisation de l’initiateur de logiciel SCSI :
• Détection de la cible
L’initiateur de logiciel iSCSI n’implémente pas de détection d’entrées iSCSI (par exemple
cibles canoniques iSCSI). Un fichier texte est utilisé pour configurer chaque cible.
• Capacité d’adressage Protocole Internet
IPv6 n’est pas implémenté
• Authentification iSCSI
Seul CHAP(MD5) peut être utilisé pour configurer l’authentification de l’initiateur.
L’authentification cible n’est pas implementée.
• Nombre de LUNs configurés
Protocole TCP/IP
4-251
Le nombre maximal de LUNs configurés et testés en utilisant l’initiateur de logiciel iSCSI
est 128 par cible iSCSI. L’initiateur de logiciel utilise une connexion TCP unique pour
chaque cible iSCSI (une connexion par session iSCSI). La connexion TCP est partagée
entre tous les LUN configurés pour une cible. L’espace de réception et l’espace d’envoi
de l’interface TCP de l’initiateur de logiciel sont tous deux définis à saturation du tampon
de l’interface système. Le maximum est défini par l’option réseau sb_max. La valeur par
défaut est 1 Mo.
• Groupes volumes
Pour éviter des problèmes de configuration et des erreurs d’entrées de connexion lors
de la création de groupe de volume utilisant les unités iSCSI, suivez les consignes
suivantes :
– Configurez les groupes de volume créés en utilisant des unités iSCSI pour les rendre
inactifs après le redémarrage. Après configuration des unités iSCSI, activez
manuellement les groupes de volume supportés par iSCSI. Puis montez tout système
de fichiers associé.
Les groupes de volume sont activés lors d’une phase d’amorçage différente du pilote
de logiciel iSCSI. C’est pourquoi il n’est pas possible d’activer les groupes de volume
iSCSI lors du processus d’amorçage.
– N’étendez pas les groupes de volume aux unités non–iSCSI.
• Echecs E/S
Si la connectivité aux unités cibles iSCSI est perdue, des échecs E/S se produisent.
Pour prévenir les échecs E/S et la corruption du système de fichiers, interrompez toute
activité E/S et démontez les systèmes de fichiers supportés par iSCSI avant
d’entreprendre quoi que ce soit qui puisse provoquer la perte de connectivité à long
terme pour activer les cibles iSCSI.
Si une perte de connectivité aux cibles iSCSI se produit lors des tentatives d’application
d’activités E/S avec des unités iSCSI, des erreurs E/S peuvent éventuellement se
produire. Il n’est pas toujours possible de démonter les systèmes de fichiers supportés
par iSCSI parce que l’unité sous–jacente de iSCSI est occupée.
La maintenance du système de fichiers doit être effectuée si les échecs E/S
se produisent en raison de la perte de connectivité pour activer les cibles iSCSI.
Pour exécuter la maintenance du système de fichiers, activez la commande fsck.
Remarques sur la sécurité
Le fichier /etc/iscsi/directorye et le fichier de configuration /etc/iscsi/targets sont protégés
des utilisateurs non privilégiés par un système d’autorisation et de propriété. Les secrets
CHAP sont sauvegardés dans le fichier /etc/iscsi/targets comme texte en clair.
Remarque :
4-252
Ne modifiez ni l’autorisation d’origine du fichier ni la propriété de
ces fichiers.
Guide de gestion du système – Communications et réseaux
Remarques sur les performances
Pour assurer de meilleures performances :
• Activer l’envoi large TCP, le contrôle de flux TCP envoyer/recevoir, et les fonctions
Jumbo Frame de la carte AIX Gigabit Ethernet ainsi que l’interface iSCSI cible.
• Harmonisez les options réseau et les paramètres d’interface pour un débit iSCSI E/S
maximum dans le système AIX
– Activez l’option réseau RFC 1323.
– Définissez les options réseau et les options interface réseau tcp_sendspace,
tcp_recvspace, sb_max, et mtu_size aux valeurs appropriées.
La taille du transfert maximal de l’initiateur de logiciel iSCSI est de 256KB. En
supposant que les maxima du système pour tcp_sendspace et tcp_recvspace
sont définis à 262144 octets, une commande ifconfig utilisée pour configurer une
interface gigabit Ethernet pourrait ressembler à ceci :
ifconfig en2 10.1.2.216 mtu 9000 tcp_sendspace 262144 tcp_recvspace
262144
– Définissez l’option réseau sb_max sur au moins 524288, et de préférence 1048576.
– Définissez le mtu_size sur 9000.
Remarque :
Pour plus d’informations sur les options réseau, reportez–vous à la
description de commande no in AIX 5L Version 5.3 Commands Reference,
Volume 4.
Pour plus d’informations et pour avoir davantage de paramètres d’harmonisation,
reportez–vous au Tuning TCP and UDP Performance dans AIX 5L Version 5.3
Performance Management Guide.
Protocole TCP/IP
4-253
Protocole de transmission du contrôle de flot
Stream Transmission Control Protocol (SCTP) est un protocole orienté connexion
semblable au TCP mais qui fournit un transfert de données orienté message semblable
à l’UDP. La table suivante met en surbrillance les différences générales dans le
comportement entre le SCTP et les protocoles de transport existants, le TCP et l’UDP.
Table 18. Différences entre le TCP, l’UDP, et le SCTP
Attribut
TCP
UDP
SCTP
Fiabilité
Fiable
Peu fiable
Fiable
Gestion de la
connexion
Orienté connexion
Connectionless
Orienté connexion
Transmission
Orienté octet
Orienté message
Orienté message
Contrôle de flux
Oui
Non
Oui
Régulation de
l’encombrement
Oui
Non
Oui
Tolérance aux
pannes
Non
Non
Oui
Remise des données Strictement ordonné
Désordonné
Partiellement
ordonné
Sécurité
Oui
Amélioré
Oui
SCTP fournit en règle générale une flexibilité accrue pour certaines applications comme
Voix sur IP (VoIP), nécessitant le transfert de données fiable mais orienté message.
Pour cette catégorie d’applications, SCTP est sans aucun doute plus approprié que le TCP
ou l’UDP.
• TCP fournit une remise des données fiable respectant strictement l’ordre de
transmission. Pour les applications nécessitant une certaine fiabilité mais pouvant tolérer
une remise des données désordonnée ou partiellement ordonnée, TCP peut engendrer
un retard inutile en raison d’un blocage en tête de ligne. Le concept de flots multiples
d’une connexion unique permet au SCTP d’effectuer une remise strictement ordonnée
au sein d’un flot en isolant de manière logique des données issues de différents flots.
• SCTP est orienté message, contrairement au TCP qui est orienté octet. Le caractère
orienté octet du TCP oblige l’application à ajouter son propre marquage
d’enregistrement visant à gérer les limites de message.
• SCTP fournit un certain degré de tolérance aux pannes en utilisant la fonction
rattachement multiréseau. Un hôte est multiréseau lorsqu’il est connecté à plus
d’une interface réseau, soit sur le même réseau, soit sur des réseaux différents.
Une association SCTP peut être établie entre deux hôtes multiréseau. Dans ce cas,
toutes les adresses IP des deux extrémités sont échangées au lancement de
l’association ; ceci permet à chaque extrémité d’utiliser chacune de ces adresses durant
la durée
de la connexion, si l’une des interfaces est hors service pour une raison quelconque,
à condition que l’homologue soit accessible via les interfaces secondaires.
• SCTP fournit des fonctions de sécurité supplémentaires que TCP et UDP ne proposent
pas. Dans SCTP, une attribution de ressources durant la configuration de l’association
est retardée jusqu’à la vérification de l’identité du client par un mécanisme d’échange de
témoins, ce qui réduit la possibilité d’attaques de déni de service.
4-254
Guide de gestion du système – Communications et réseaux
Lancement et interruption de l’association
L’association SCTP se compose d’un établissement de liaison quadri–niveau se présentant
dans l’ordre suivant :
1. Le client envoie un signal INIT au serveur pour lancer une association.
2. A réception du signal INIT, le serveur envoie une réponse INIT–ACK au client. Ce signal
INIT–ACK contient un témoin d’état. Ce témoin d’état doit contenir un code
d’authentification de message (MAC) avec un horodateur correspondant à la création du
témoin, la durée du vie du témoin d’état et les informations nécessaires à l’établissement
de l’association. Le code MAC est calculé par le serveur en fonction de la clé secrète
que lui seul connaît.
3. Après réception du signal INIT–ACK, le client envoie une réponse COOKIE–ECHO
indiquant le témoin d’état.
4. Après vérification de l’authenticité du témoin d’état utilisant la clé secrète, le serveur
attribue les ressources pour l’association, envoie une réponse COOKIE–ACK accusant
réception du signal COOKIE–ECHO et affecte l’état ESTABLISHED à l’association.
SCTP prend en charge également la fermeture normale d’une association active sur
demande de l’utilisateur SCTP. La séquence d’événements suivante se produit :
1. Le client envoie un signal SHUTDOWN au serveur, l’informant qu’il est prêt à se
déconnecter.
2. Le serveur répond en envoyant un accusé de réception SHUTDOWN–ACK.
3. Le client renvoie ensuite un signal SHUTDOWN–COMPLETE au serveur.
SCTP prend également en charge la fermeture subite (signal ABORT) d’une association
active à la demande du client SCTP ou en raison d’une erreur dans la pile SCTP. En
revanche, SCTP ne prend pas en charge les connexions semi–ouvertes. Pour plus
d’informations sur le protocole et ses internes, reportez–vous à la RFC 2960.
Outre les différences spécifiées ci–dessus existant entre SCTP et les protocoles de
transport, SCTP fournit les fonctions suivantes :
• Remise séquentielle au sein des flots : Un flot dans un contexte SCTP fait référence à
une séquence de messages utilisateur transférés entre des extrémités. Une association
SCTP peut gérer plusieurs flots de données. Au moment de la configuration de
l’association, l’utilisateur peut spécifier le nombre de flots de données. La valeur effective
du nombre de flots de données est déterminée après négociation avec l’homologue.
L’ordre de la remise des données est strictement maintenu au sein de chaque flot. En
revanche, la remise des données de flots est indépendante. Ainsi, la perte de données
d’un flot n’empêche pas la remise des données dans un autre flot. Ceci permet à
l’application utilisateur d’utiliser des flots différents pour des données indépendantes
d’un point de vue logique. La remise des donnée peut également être effectuée sans
ordre défini à l’aide d’une option spéciale. Elle s’avère utile pour l’envoi de données
urgentes.
• Fragmentation de données utilisateur : SCTP peut fragmenter des messages
utilisateur pour garantir que la taille du paquet transmise à la couche inférieure ne
dépasse pas la MTU d’accès. Au moment de la réception, les fragments sont
rassemblés dans un message complet et transmis à l’utilisateur. Bien que la
fragmentation puisse être également effectuée au niveau du réseau, la fragmentation
de la couche de transport fournit divers avantages via la fragmentation de la couche IP.
Certains de ces avantages incluent le fait de ne pas devoir (r)envoyer des messages
entiers lorsque des fragments sont perdus sur le réseau et de réduire la charge des
routeurs, qui autrement devraient effectuer la fragmentation IP.
Protocole TCP/IP
4-255
• Accusé de réception et régulation de l’encombrement : L’accusé de réception
du paquet est nécessaire pour une remise de données fiable. Lorsque SCTP n’obtient
pas l’accusé de réception d’un paquet qu’il envoie au cours d’une période spécifiée,
il déclenche la retransmission du même paquet. Le SCTP suit les mêmes algorithmes
de régulation de l’encombrement que ceux utilisés par le TCP. Outre l’utilisation
d’accusés de réception récapitulatifs comme le TCP, le SCTP utilise le mécanisme
d’accusé de réception sélectif (SACK), lui permettant de sélectionner les paquets
dont il accuse réception.
• Regroupement de tranches de mémoire : Une tranche de mémoire peut contenir
des données utilisateur ou des informations de contrôle SCTP. Plusieurs tranches de
mémoire peuvent être regroupées sous le même en–tête SCTP. Le regroupement de
tranches de mémoire nécessite leur assemblage dans le paquet SCTP à l’extrémité
émettrice puis le désassemblage du paquet en tranches de mémoire à l’extrémité
réceptrice.
• Validation de paquet : Chaque paquet SCTP a un champ de balise de vérification défini
durant la période de lancement de l’association par chaque extrémité. Tous les paquets
sont envoyés avec la même balise de vérification pendant la durée de vie de
l’association. Si, pendant la durée de l’association, un paquet est reçu avec une balise
de vérification inattendue, le paquet est supprimé. Le total de contrôle CRC–32 doit
également être activé par l’émetteur de chaque paquet SCTP afin de fournir une
protection accrue contre l’altération de données sur le réseau. Chaque paquet reçu
avec un total de contrôle CRC–32 invalide est supprimé.
• Gestion du chemin d’accès : Au moment de la configuration de l’installation, chaque
extrémité doit annoncer la liste d’adresses de transport qu’il détient. En revanche, seul
un chemin d’accès primaire est défini pour l’association SCTP et utilisé pour le transfert
normal des données. En cas de panne du chemin d’accès primaire, les autres adresses
de transport sont utilisées. Au cours de la durée de vie de l’association, des battements
de coeur sont envoyés à intervalle régulier via tous les chemins d’accès pour contrôler
le statut du chemin d’accès.
API de socket SCTP
Les API Socket SCTP ont été conçues pour offrir les fonctions suivantes :
• Maintien de la cohérence avec les API de socket existantes
• Fourniture d’une base pour l’accès à de nouvelles fonctions SCTP
• Compatibilité permettant la migration du maximum d’applications TCP et UDP vers le
SCTP avec peu de modifications.
Dans le but de faciliter la migration simple des applications TCP et UDP existantes, deux
styles distincts d’API SCTP ont été formulés :
• API style UDP : la sémantique est semblable à celle définie pour les protocoles sans
connexion tel UDP.
• API style TCP : la sémantique est semblable à celle définie pour les protocoles orientés
connexion tel TCP.
Bien que SCTP permette la définition et l’utilisation des deux styles d’API de socket TCP et
UDP, AIX 5.3 prend seulement en charge la syntaxe de socket de style UDP, car elle offre
une plus grande souplesse en terme d’accès aux nouvelles fonctions de SCTP. En utilisant
l’API de style UDP, un serveur type utilise la séquence suivante d’appels au cours de la
durée de vie de l’association.
1. socket()
2. bind ()
3. listen ()
4. recvmsg ()
4-256
Guide de gestion du système – Communications et réseaux
5. sendmsg ()
6. close ()
Un client type utilise la séquence suivante d’appels d’API de socket :
1. socket ()
2. sendmsg ()
3. recvmsg ()
4. close ()
Les associations créées employant la séquence ci–dessus sont des associations créées
explicitement. Une association peut être créée implicitement après la création d’un socket,
en appelant simplement sendmsg (), recvmsg () ou sendto () et recvto (). Dans le cas
d’une association implicite, les appels bind () et listen () sont inutiles. La syntaxe de tous
ces appels système sont similaires à ceux utilisés avec des sockets UDP. Pour la
sous–routine d’un socket, le champ Type doit être défini sur SOCK_SEQPACKET et le
champ Protocol doit prendre la valeur IPPROTO_SCTP. Outre ces API socket standard,
SCTP fournit deux nouvelles API : sctp_peeloff () et sctp_opt_info (). Pour plus
d’informations sur l’utilisation de l’API Socket pour SCTP, consultez le Draft API Socket
SCTP. SCTP a été implémenté comme l’extension de noyau dans AIX 5.3. Un utilisateur
peut utiliser la commande sctpctrl pour charger et décharger l’extension de noyau SCTP.
De plus, cette commande peut être utilisée pour visualiser et modifier diverses autres
statistiques et objets raccordables de l’extension de noyau SCTP à l’aide de différentes
options telles que obtenir et définir. Pour plus d’informations au sujet de la commande
sctpctrl, reportez–vous à la description de la commande sctpctrl dans le manuel AIX 5L
Version 5.3 Commands Reference, Volume 5.
Protocole TCP/IP
4-257
Recherche de MTU d’accès
Pour deux hôtes communiquant via un chemin d’accès à des réseaux multiples, les paquets
transmis sont fragmentés si leur taille dépasse celle de la plus petite MTU d’un réseau
quelconque du chemin d’accès. La fragmentation étant susceptible de réduire les
performances du réseau, il suffit, pour l’éviter, de transmettre des paquets de taille inférieure
ou égale à celle de la plus petite MTU du chemin d’accès du réseau : vous faites alors
appel à la MTU d’accès.
Un algorithme de recherche de MTU d’accès est pris en charge par ce système tel que
défini dans le RFC 1191. Pour l’activer pour les applications TCP et UDP, modifiez les
options tcp_pmtu_discover et udp_pmtu_discover de la commande no. Quand elle est
activée pour TCP, la recherche de MTU d’accès impose automatiquement aux paquets
transmis par les applications TCP une taille ne dépassant pas la MTU d’accès. Les
applications UDP déterminent elles-mêmes la taille de leurs paquets transmis : aussi
doivent-elles être configurées pour utiliser l’information de MTU d’accès via l’option socket
IP_FINDPMTU, même si l’option udp_pmtu_discover no est activée. Les options
tcp_pmtu_discover et udp_pmtu_discover sont désactivées par défaut de la version AIX
Version 4.2.1 à AIX Version 4.3.1, et activées sur la version AIX Version 4.3.2 et les
versions ultérieures.
Dans les versions antérieures à AIX 5.3, une fois la MTU d’accès trouvée pour une route de
réseau, une route hôte distincte est ”clonée” pour le chemin d’accès. Vous pouvez afficher
les routes hôte ”clonées” et la valeur MTU d’accès pour la route avec la commande netstat
–r. L’accumulation des routes ”clonées” peut être évitée en permettant l’expiration et la
suppression des routes inutilisées. L’option route_expire de la commande no contrôle
l’expiration des routes ; elle est désactivée par défaut. L’option de l’expiration des routes est
désactivée par défaut sous la version AIX 4.2.1 et définie à 1 minute sous AIX 4.3.2 et les
versions supérieures.
En commençant par AIX 5.3, lorsqu’une tentative de détection de la MTU d’accès est
effectuée pour une destination, une entrée pmtu est créée dans une table de la MTU
d’accès (PMTU). Cette table peut être affichée via la commande d’affichage pmtu.
L’accumulation des entrées pmtu peut être évitée en permettant l’expiration et la
suppression des entrées pmtu inutilisées. Le contrôle de l’expiration de l’entrée PMTU est
exécuté par l’option pmtu_expire de la commande no. pmtu_expire, défini par défaut à 10
minutes.
Les routes pouvant être modifiées dynamiquement, les valeurs MTU d’accès peuvent
également changer dans le temps. La diminution de ces valeurs étant susceptible de
provoquer la fragmentation de paquets, ces valeurs sont analysées régulièrement (toutes
les 10 minutes par défaut). Vous pouvez modifier la fréquence d’analyse avec l’option
pmtu_default_age de la commande no.
En commençant par la version AIX 5.3, les applications UDP nécessitent toujours la
définition de l’option de socket IP_DONTFRAG pour détecter les diminutions dans PMTU.
Cela active la détection immédiate de diminutions dans la MTU d’accès plutôt que l’analyse
des diminutions toutes les minutes pmtu_default_age.
L’augmentation des valeurs MTU d’accès peut accroître les performances du réseau.
Les valeurs trouvées sont donc analysées régulièrement pour y rechercher une
augmentation (toutes les 30 minutes par défaut). Vous pouvez modifier la fréquence
d’analyse avec l’option pmtu_rediscover_interval de la commande no.
4-258
Guide de gestion du système – Communications et réseaux
Si tous les routeurs du chemin d’accès au réseau n’admettent pas le RFC 1191, déterminer
la valeur MTU d’accès exacte peut s’avérer impossible. Dans ce cas, la commande mmtu
permet d’entériner ou non les valeurs testées.
Remarques :
1. La détection de la MTU d’accès ne peut pas être utilisée sur des routes en double, y
compris celles configurées pour le routage de groupe Limitation de l’utilisation de la
route, page 4-214). En commençant par AIX 5.3, la détection de la MTU d’accès peut
être utilisée sur des routes en double
2. Avec la recherche de MTU d’accès activée, l’option arpqsize de la commande no a sa
valeur minimale définie à 5. Si, par la suite, la recherche de MTU d’accès est désactivée,
cette valeur n’est pas diminuée.
Protocole TCP/IP
4-259
Normes QoS (Qualité du service) TCP/IP
Les normes QoS (Quality of Service) sont une famille de normes Internet qui offrent un
mode de traitement préférentiel de certains types de trafic IP. Ces normes peuvent réduire
les délais d’attente variables et la congestion ayant pour effet de limiter les performances du
réseau. Le système d’exploitation offre une prise en charge des normes QoS au niveau de
l’hôte afin de répartir le trafic vers l’extérieur en classes de service distinctes. Ces normes
permettent également d’indiquer et de faire des réservations de ressources telles que
l’exigent les applications clients.
Les normes QoS peuvent être utilisées par un organisme pour déployer et mettre en place
des politiques de gestion du réseau régissant l’utilisation de la largeur de bande du réseau.
Avec les normes QoS, un hôte peut procéder aux opérations suivantes :
• Réguler le volume d’un certain type de trafic au sein du réseau ;
• Marquer des paquets sélectionnés en fonction d’un certain type de politique afin que les
routeurs puissent par la suite fournir le service demandé ;
• Prendre en charge des services, tels que le service virtuel de lignes spécialisées avec
une prise en charge appropriée des normes QoS le long de la route ;
• Participer aux requêtes de réservation de ressources des destinataires et annoncer les
sessions expéditrices disponibles pour ces requêtes.
La prise en charge des normes QoS offre les fonctions suivantes :
• Services différenciés tels que définis dans la norme RFC 2474
• Politique de gestion du trafic
• Marquage des paquets à l’intérieur et hors du profil
• Conception du trafic
• Mesure
• Services intégrés pour applications client et serveur tels que définis dans la norme
RFC 1633
• Signalisation RSVP (RFC 2205)
• Service garanti (RFC 2212)
• Service de contrôle de charge (RFC 2211)
• Mise en réseau conformément à la politique en vigueur
• Bibliothèque RAPI partagée destinée aux applications
Le sous–système de normes QoS se compose de quatre éléments :
Extension du noyau QoS (/usr/lib/drivers/qos)
L’extension du noyau QoS réside dans le répertoire /usr/lib/drivers/qos ;
elle est chargée et déchargée à l’aide des méthodes de configuration
cfgqos et ucfgqos. Cette extension de noyau permet la prise en charge
QoS.
Agent de politique (/usr/sbin/policyd)
L’agent de politique est un démon de niveau utilisateur qui réside dans
/usr/sbin/policyd. Il prend en charge la gestion de la politique et sert
d’interface avec l’extension du noyau QoS afin d’installer, de modifier et
de supprimer les règles de politique. Les règles de politique peuvent
être définies dans le fichier de configuration local (/etc/policyd.conf),
récupérées dans le serveur de réseau central à l’aide de LDAP,
ou les deux.
4-260
Guide de gestion du système – Communications et réseaux
Agent RSVP (/usr/sbin/rsvpd)
L’agent RSVP est un démon de niveau utilisateur qui réside dans
/usr/sbin/rsvpd. Il met en œuvre la sémantique de protocole de
signalisation RSVP.
Bibliothèque partagée RAPI (/usr/lib/librapi.a)
Les applications peuvent utiliser la RSVP API (RAPI) pour une meilleure
qualité de service telle que définie par le modèle QoS Internet de services
intégrés (Integrated Services Internet QoS model). Cette bibliothèque
dialogue avec l’agent RSVP local afin de diffuser la requête QoS le long du
chemin emprunté par le flux de données à l’aide du protocole RSVP.
Cette API est une norme ouverte.
Remarque:
Cette mise en œuvre de QoS est basée sur un ensemble de normes
Internet en constante évolution et des ébauches de normes en cours
d’élaboration par l’Internet Engineering Task Force (IETF) ainsi que ses
divers groupes de travail. Les efforts de normalisation au sein de l’IETF
permettront d’améliorer la cohérence et la définition de cette technologie.
Il est également à noter que la QoS est une nouvelle technologie Internet
récemment déployée au sein de ce réseau. Elle présente de nombreux
avantages à tous les stades de son déploiement. Toutefois, les services
bout en bout ne peuvent être offerts qu’avec une prise en charge totale de
la technologie QoS.
Modèles QoS
Les modèles QoS pour Internet sont des normes ouvertes définies par l’IETF. Deux de ces
modèles sont en cours de normalisation au sein de l’IETF : Services intégrés et Services
différenciés. Ceux–ci renforcent le modèle traditionnel de service optimisé décrit dans la
norme RFC 1812.
Services intégrés
Le service IS (Services intégrés) est un modèle dynamique de réservation des ressources
pour Internet, tel que décrit dans la norme RFC 1633. Les hôtes utilisent un protocole de
signalisation appelé Resource ReSerVation Protocol (RSVP) pour demander au réseau,
de manière dynamique, une qualité de service spécifique. Les paramètres QoS sont
acheminés dans ces messages RSVP et chaque nœud de réseau le long du chemin installe
ces paramètres afin de disposer de la qualité de service requise. Ces paramètres QoS
décrivent l’un des deux services actuellement définis, à savoir le service garanti et le service
de contrôle de charge. L’IS se caractérise par le fait que cette signalisation porte sur chaque
flux de trafic et que les réservations s’appliquent à chaque bond sur le chemin. Bien que ce
modèle soit tout à fait à même de répondre à l’évolution constante des applications, il
persiste encore certains problèmes en termes d’évolutivité qui empêchent son déploiement
sur des réseaux au sein desquels des routeurs uniques gèrent plusieurs flux simultanés.
Services différenciés
Le service DS (Services différenciés) résout les problèmes d’évolutivité par flux et par bond
par le biais d’un mécanisme simple de classification des paquets. Plutôt qu’une approche
de signalisation dynamique, le service DS privilégie l’utilisation de bits dans l’octet TOS
(type de service) IP afin de répartir les paquets en classes. Ce modèle de bit particulier
dans l’octet TOS IP est appelé point de code DS. Il est utilisé par les routeurs pour définir la
qualité de service fournie au niveau de ce bond en particulier, se rapprochant par là–même
de leur mode d’acheminement IP par le biais de la consultation des tables de routage. Le
traitement d’un paquet avec un point de code DS particulier s’appelle le PHB (per–hop
behavior). Il est géré indépendamment à chaque nœud de réseau. La concaténation de ces
différents PHB indépendants offre un service bout en bout.
Protocole TCP/IP
4-261
Les services différenciés sont en cours de normalisation par un groupe de travail IETF, qui a
défini trois PHB : le PHB avec acheminement expéditif (EF : abréviation de Expedited
Forwarding), le groupe PHB avec acheminement assuré (AF : abréviation de Assured
Forwarding) et le PHB par défaut (DE : abréviation de par défaut). Le EF PHB peut être
utilisé pour la mise en œuvre d’un service bout en bout, telle qu’une ligne spécialisée (VLL)
offrant un délai d’attente et un taux d’instabilité faibles ainsi que des pertes réduites. L’AF
est une famille de PHB, appelé groupe de PHB. Il est utilisé pour classer des paquets en
fonction des différents niveaux de priorité. Le niveau de priorité attribué à un paquet
détermine son importance relative au sein de la classe AF. Par ce biais, il est possible de
bénéficier du service dit Olympique, à savoir bronze, argent et or. Le DE PHB est le modèle
traditionnel de service optimisé tel que normalisé par la RFC 1812.
Normes prises en charge et ébauches de normes
Les ébauches de normes Internet et les RFC suivants traitent des normes sur lesquelles
s’appuie cette mise en œuvre des modèles QoS.
RFC 2474
Définition du champ Services différenciés (champ DS)
dans les en–têtes IP versions 4 et 6
RFC 2475
Architecture des services différenciés
RFC 1633
Présentation des services intégrés au sein de l’architecture
Internet
RFC 2205
Protocole de réservation des ressources (RSVP)
RFC 2210
Utilisation du RSVP avec les services intégrés IETF
RFC 2211
Spécification du service d’éléments réseau avec contrôle
de charge
RFC 2212
Spécification de la qualité de service garantie
RFC 2215
Paramètres de définition généraux des éléments réseau
des services intégrés
draft–ietf–diffserv–framewor
k–01.txt, octobre 1998
Cadre des services différenciés
draft–ietf–diffserv–rsvp–01.t
xt, novembre 1998
Cadre d’utilisation du RSVP avec des réseaux DIFF–serv
draft–ietf–diffserv–phb–ef–0
1.txt
Groupe PHB d’acheminement expéditif
draft–ietf–diffserv–af–04.txt
Groupe PHB d’acheminement assuré
draft–rajan–policy–qossche
ma–00.txt, octobre 1998
Schéma des services différenciés et intégrés au sein des
réseaux
draft–ietf–rap–framework–0
1.txt, novembre 1998
Cadre pour contrôle d’admission [25] basé sur des règles
de politique
draft–ietf–rap–rsvp–ext–01.t
xt, novembre 1998
Extensions RSVP pour contrôle de politique
Remarque :
4-262
QoS est une technologie Internet émergente. Elle présente de nombreux
avantages à tous les stades de son déploiement. Toutefois, les services
bout en bout ne peuvent être offerts qu’avec une prise en charge totale de
la technologie QoS.
Guide de gestion du système – Communications et réseaux
Installation de QoS
QoS est livré avec bos.net.tcp.server. L’installation de ces fichiers est indispensable pour
utiliser QoS. Pour utiliser la bibliothèque RAPI partagée, installez aussi bos.adt.include.
Configuration de QoS
Arrêt et démarrage du sous–système QoS
QoS peut être lancé ou arrêté avec le raccourci SMIT (smit qos) ou les commandes
mkqos et rmqos.
Pour désactiver dès à présent le sous–système QoS et lors du prochain redémarrage du
système, procédez comme suit :
/usr/sbin/rmqos –B
Pour activer le sous–système QoS pour la période en cours seulement,
procédez comme suit :
/usr/sbin/mkqos –N
Reportez–vous à la description des commandes mkqos et rmqos pour le lancement et le
retrait des indicateurs de commande.
Les démons policyd et rsvpd sont configurés par les fichiers de configuration
/etc/policyd.conf et /etc/rsvpd.conf. Ces fichiers doivent être édités afin de personnaliser
le sous–système QoS en fonction de l’environnement local. QoS ne fonctionne pas
correctement avec les configurations type fournies.
Configuration de l’agent RSVP
L’agent RSVP est nécessaire si l’hôte doit prendre en charge le protocole du même nom.
Utilisez le fichier de configuration /etc/rsvpd.conf pour configurer l’agent RSVP. La syntaxe
de ce fichier est précisée dans le fichier de configuration type installé dans /etc/rsvpd.conf.
Configuration type
interface 1.2.30.1
interface 1.20.2.3 disabled
interface 1.2.3.3 disabled
interface 1.2.3.4
{
trafficControl
}
rsvp 1.2.30.1
{
maxFlows 64
}
rsvp 1.2.3.4
{
maxFlows 100
}
L’exemple ci–dessus illustre une possibilité de configuration RSVP au sein de laquelle l’hôte
a 4 interfaces (virtuelles ou physiques) représentées par les 4 adresses IP :
1.2.3.1, 1.2.3.2, 1.2.3.3 et 1.2.3.4.
L’interface 1.2.3.1 a été activée pour le RSVP. Toutefois, la fonction de contrôle du trafic
n’a pas été spécifiée et les messages RESV RSVP entrants n’entraînent pas la réservation
des ressources au sein du sous–système TCP. Cette interface peut prendre en charge un
maximum de 64 sessions RSVP simultanées.
Les interfaces 1.2.3.2 et 1.2.3.3 ont été désactivées. L’agent RSVP ne peut pas utiliser
cette interface pour transmettre ni recevoir des messages RSVP.
Protocole TCP/IP
4-263
L’interface 1.2.3.4 a été activée pour le RSVP. En outre, elle peut procéder à des
réservations de ressources au sein du sous–système TCP en réponse à un message RESV
RSVP. Cette interface peut prendre en charge jusqu’à 100 sessions RSVP.
Toutes les autres interfaces existantes sur l’hôte mais non reprises de manière explicite
dans /etc/rsvpd.conf sont désactivées.
Configuration de l’agent de politique
L’agent de politique est un composant indispensable du sous–système QoS. Utilisez le
fichier /etc/policyd.conf pour configurer l’agent de politique. La syntaxe de ce fichier est
précisée dans le fichier de configuration type installé dans /etc/policyd.conf.
Vous pouvez configurer l’agent de politique en éditant /etc/policyd.conf. En outre, les
commandes suivantes sont fournies pour faciliter la configuration des politiques :
• qosadd
• qosmod
• qoslist
• qosremove
Configurations type
Dans l’exemple suivant, une catégorie de service de qualité est créée et utilisée dans la
règle de politique tcptraffic. Cette catégorie de service a une vitesse de transmission
maximum de 110 000 Kbps, une profondeur de compartiment à jeton de 10 000 bits et une
valeur TOS IP sortante de 11100000 en système binaire. La règle de politique tcptraffic offre
ce service de qualité à l’ensemble du trafic pour lequel l’adresse IP source est fournie par
1.2.3.6, avec l’adresse de destination 1.2.3.3 et le port de destination compris entre 0
et 1024.
ServiceCategories premium
{
PolicyScope
DataTraffic
MaxRate
110000
MaxTokenBucket 10000
OutgoingTOS
11100000
}
ServicePolicyRules
tcptraffic
{
PolicyScope
DataTraffic
ProtocolNumber 6 # tcp
SourceAddressRange
1.2.3.6–1.2.3.6
DestinationAddressRange 1.2.3.3–1.2.3.3
DestinationPortRange
0–1024
ServiceReference
premium
}
4-264
Guide de gestion du système – Communications et réseaux
Les instructions suivantes définissent une catégorie de service par défaut et l’utilisent pour
réduire le trafic UDP entre les interfaces 1.2.3.1 à 1.2.3.4 et les adresses IP 1.2.3.6
à 1.2.3.10, port 8000.
ServiceCategories default
{
MaxRate
110000
MaxTokenBucket 10000
OutgoingTOS
00000000
}
ServicePolicyRules
udptraffic
{
ProtocolNumber 17 # udp
SourceAddressRange
1.2.30.1–1.2.30.4
DestinationAddressRange 1.20.60.10–1.2.3.3
DestinationPortRange
8000–8000
ServiceReference
default
}
La configuration type ci–après peut être utilisée pour télécharger des règles à partir d’un
serveur LDAP à l’aide du nom de sous–arborescence spécifique,
ReadFromDirectory
{
LDAP_Server
1.2.3.27
Base
ou=NetworkPolicies,o=myhost.mydomain.com,c=fr
}
Protocole TCP/IP
4-265
Identification des problèmes au niveau du QoS
La commande qosstat peut être utilisée pour afficher des informations d’état relatives aux
politiques actives installées dans le sous–système QoS. Ces informations peuvent vous être
utiles afin de détecter la présence d’un problème lors du débogage de la configuration QoS.
Utilisez qosstat pour produire le rapport suivant.
Action:
Token bucket rate (B/sec): 10240
Token bucket depth (B): 1024
Peak rate (B/sec): 10240
Min policied unit (B): 20
Max packet size (B): 1452
Type: IS–CL
Flags: 0x00001001 (POLICE,SHAPE)
Statistics:
Compliant packets: 1423 (440538 bytes)
Conditions:
Source address
192.168.127.39:8000
Dest address
192.168.256.29:35049
Protocol
tcp
(1 connection)
Action:
Token bucket rate (B/sec): 10240
Token bucket depth (B): 1024
Peak rate (B/sec): 10240
Outgoing TOS (compliant): 0xc0
Outgoing TOS (non–compliant): 0x00
Flags: 0x00001011 (POLICE,MARK)
Type: DS
Statistics:
Compliant packets: 335172 (20721355 bytes)
Non–compliant packets: 5629 (187719 bytes)
Conditions:
Source address
192.168.127.39:80
192.168.127.40:80
Dest address
*:*
*:*
Protocol
tcp (1 connection)
tcp (5 connections)
Spécification de politiques
Cette section décrit les classes et attributs d’objets utilisés par l’agent de politique pour
spécifier les politiques de qualité du service (QoS) sur le trafic sortant. Elle définit les
classes et attributs d’objets puis donne des instructions relatives au marquage, à la gestion
du trafic et à la conception.
Les conventions suivantes sont utilisées dans les explications ci–dessous :
p : Choisissez l’un des paramètres autorisés
B : Valeur d’entier d’un octet (0 =< B =< 255)
b : Chaîne de bit commençant par le bit le plus à gauche
(101 équivaut à 10100000 dans un champ d’octet)
i : Valeur d’entier
s : Une chaîne de caractères
a : Format d’adresse IP B.B.B.B
(R) : Paramètre requis
(O) : Paramètre facultatif
4-266
Guide de gestion du système – Communications et réseaux
ReadFromDirectory
Cette instruction spécifie les paramètres permettant d’établir une session LDAP.
Elle est utilisée dans le fichier /etc/policyd.conf pour établir la session LDAP.
ReadFromDirectory
{
LDAP_Server
a
# Adresse IP du serveur de répertoires
exécutant LDAP
LDAP_Port
i
# Numéro du port écouté par le serveur LDAP
Base
s
# Nom spécifique pour l’utilisation LDAP
LDAP_SelectedTag s # Balise correspondant à SelectorTag dans
les classes d’objets
}
où
LDAP_Server (R) : Adresse IP du serveur LDAP
LDAP_Port
(0) : Numéro de port unique, le port
par défaut est 389
Base
(R) : Exemple : o=ibm, c=fr où o est votre
organisation et c le pays
LDAP_SelectedTag (R) : Chaîne unique correspondant à
l’attribut
SelectorTag dans la classe d’objets
ServiceCategories
Cette instruction spécifie le type de service qu’un flux de paquets IP (d’une connexion TCP
ou de données UDP par exemple) doit recevoir de bout en bout lors de son passage sur le
réseau. Les instructions ServiceCategories peuvent être répétées, chacune ayant un
nom différent pour qu’il soit possible d’y faire référence à un stade ultérieur. Un objet
ServiceCategories exige une instruction ServicePolicyRules pour que la définition
de politique soit complète.
ServiceCategories
{
SelectorTag
s
MaxRate
i
s
MaxTokenBucket i
OutgoingTOS
b
FlowServiceType
p
# Balise requise pour la recherche LDAP
# Vitesse cible du trafic dans cette classe
de service
# La profondeur du compartiment
# Valeur TOS du trafic sortant pour cette
classe de service
# Type de trafic
}
où
s
(R)
SelectorTag (R)
: est le nom de cette catégorie de service
: Requis uniquement pour la recherche LDAP
dans les classes d’objets
MaxRate
(O)
: En Kbps (K bits par seconde), la valeur par
défaut est 0
MaxTokenBucket(O)
: En Kb, la valeur par défaut est définie par
le système au maximum
OutgoingTOS (O)
: La valeur par défaut est 0
FlowServiceType (O) : ControlledLoad | Guaranteed, la valeur
par défaut est ControlledLoad
Protocole TCP/IP
4-267
ServicePolicyRules
Cette instruction spécifie les caractéristiques des paquets IP pour la correspondance avec
une catégorie de service donnée. En d’autres termes, elle définit un jeu de datagrammes IP
qui doivent recevoir un service. Les instructions ServicePolicyRules sont associées à
des instructions ServiceCategories via l’attribut ServiceReference. Si deux règles
font référence à la même ServiceCategory, chacune d’entre elles est associée à une
instance unique de celle–ci.
ServicePolicyRules
{
SelectorTag
ProtocolNumber
s
s
i
# Balise requise pour la recherche LDAP
# Id du protocole de transport de la règle
de politique
SourceAddressRange
a1–a2
DestinationAddressRange a1–a2
SourcePortRange
i1–i2
DestinationPortRange
i1–i2
PolicyRulePriority i
# La valeur la plus élevée est
utilisée en premier
ServiceReference
s # Nom de la catégorie de service de
cette règle de politique
}
où
s
(R) : est le nom de cette règle de politique
SelectorTag (R) : Requis uniquement pour la recherche LDAP dans
la classe d’objet
ProtocolNumber
(R) : La valeur par défaut est 0
(aucune correspondance n’est trouvée). Spécification explicite requise
SourceAddressRange (O): de a1 à a2 où a2 >= a1, la valeur par
défaut est 0, n’importe quelle adresse source
SourcePortRange
(O) : de i1 à i2 où i2 >= i1, la valeur par
défaut est 0, n’importe quel port source
DestinationAddressRange (O) : Voir SourceAddressRange
DestinationPortRange
(O) : Voir SourcePortRange
PolicyRulePriority
(O) : Spécification importante en présence
de politiques superposées
ServiceReference
(R) : catégorie de service utilisée
par cette règle
Instructions relatives aux environnements DiffServ
Les instructions ci–dessous se rapportent à la spécification de politiques pour le marquage,
la conception et/ou la gestion du trafic dans un environnement DiffServ.
1. Marquage uniquement
OutgoingTOS
: Type de service souhaité
FlowServiceType : ControlledLoad
MaxRate
: Utilisez la valeur par défaut 0
2. Conception uniquement
OutgoingTOS
: Utilisez la valeur par défaut 0
FlowServiceType : Guaranteed
MaxRate
: Vitesse cible souhaitée pour le trafic sous
la forme d’un entier positif
3. Marquage et gestion (Voir remarque)
OutgoingTOS
: Type de service souhaité
FlowServiceType : ControlledLoad
MaxRate
: Vitesse cible souhaitée pour le trafic sous
la forme d’un entier positif
4-268
Guide de gestion du système – Communications et réseaux
4. Marquage et conception
OutgoingTOS
: Type de service souhaité
FlowServiceType : Guaranteed
MaxRate
: Vitesse cible souhaitée pour le trafic sous
la forme d’un entier positif
Remarque:
Le type de service des paquets ne correspondant pas au profil est défini sur
zéro pour la gestion.
Fichier de configuration policyd exemple
L’exemple ci–dessous reprend un fichier de configuration /etc/policyd.conf complet.
Fichier de configuration policyd
#loglevel
511
# Verbose logging
#####################################################################
#
#
# Mark rsh traffic on TCP source ports 513 and 514.
ServiceCategories
tcp_513_514_svc
{
MaxRate
0
# Mark only
OutgoingTOS
00011100
# binary
FlowServiceType
ControlledLoad
}
ServicePolicyRules
tcp_513_514_flt
{
ProtocolNumber
6 # TCP
SourceAddressRange
0.0.0.0–0.0.0.0 # Any IP src addr
DestinationAddressRange 0.0.0.0–0.0.0.0 # Any IP dst addr
SourcePortRange
513–514
DestinationPortRange
0–0
# Any dst port
ServiceReference
tcp_513_514_svc
}
#
#####################################################################
#
#
# Shape connected UDP traffic on source port 9000.
ServiceCategories
udp_9000_svc
{
MaxRate
8192
# kilobits
MaxTokenBucket
64
# kilobits
FlowServiceType
Guaranteed
}
ServicePolicyRules
udp_9000_flt
{
ProtocolNumber
17 # UDP
SourceAddressRange
0.0.0.0–0.0.0.0 # Any IP src addr
DestinationAddressRange 0.0.0.0–0.0.0.0 # Any IP dst addr
SourcePortRange
9000–9000
DestinationPortRange
0–0
# Any dst port
ServiceReference
udp_9000_svc
}
#
#####################################################################
#
#
# Mark and police finger traffic on TCP source port 79.
ServiceCategories
tcp_79_svc
Protocole TCP/IP
4-269
{
MaxRate
MaxTokenBucket
OutgoingTOS
FlowServiceType
8
# kilobits
32
# kilobits
00011100 # binary
ControlledLoad
}
ServicePolicyRules
tcp_79_flt
{
ProtocolNumber
6 # TCP
SourceAddressRange
0.0.0.0–0.0.0.0 # Any IP src addr
DestinationAddressRange 0.0.0.0–0.0.0.0 # Any IP dst addr
SourcePortRange
79–79
DestinationPortRange
0–0
# Any dst port
ServiceReference
tcp_79_svc
}
#
#####################################################################
#
#
# Mark and shape ftp–data traffic on TCP source port 20.
ServiceCategories
tcp_20_svc
{
MaxRate
81920
# kilobits
MaxTokenBucket
128
# kilobits
OutgoingTOS
00011101
# binary
FlowServiceType
Guaranteed
}
ServicePolicyRules
tcp_20_flt
{
ProtocolNumber
6 # TCP
SourceAddressRange
0.0.0.0–0.0.0.0 # Any IP src addr
DestinationAddressRange 0.0.0.0–0.0.0.0 # Any IP dst addr
SourcePortRange
20–20
DestinationPortRange
0–0
# Any dst port
ServiceReference
tcp_20_svc
}
#
#####################################################################
#
#
# LDAP server entry.
#ReadFromDirectory
#{
#
LDAP_Server
9.3.33.138 # IP address of LDAP server
#
Base
o=ibm,c=us # Base distinguished name
#
LDAP_SelectedTag
myhost
# Typically client hostname
#}
#
#####################################################################
#
Chargement de politiques dans le serveur de répertoires
SecureWay Directory
Si le démon de politique est utilisé avec le serveur de répertoires LDAP SecureWay
Directory, utilisez le schéma ci–dessous comme guide pour mettre à jour
/etc/ldapschema/V3.modifiedschema avant de démarrer le serveur LDAP. Pour plus
d’informations, reportez–vous à Planification et configuration pour la résolution de noms
LDAP (Schéma de répertoire SecureWay), page 4-92
4-270
Guide de gestion du système – Communications et réseaux
Schéma LDAP
objectClasses {
( ServiceCategories–OID NAME ’ServiceCategories’ SUP top MUST
( objectClass $ SelectorTag $ serviceName ) MAY
( description $ FlowServiceType $ MaxRate $ MaxTokenBucket $ OutgoingTos
) )
( ServicePolicyRules–OID NAME ’ServicePolicyRules’ SUP top MUST
( objectClass $ PolicyName $ SelectorTag ) MAY
( description $ DestinationAddressRange $ DestinationPortRange $
ProtocolNumber $ ServiceReference $ SourceAddressRange $ SourcePortRange
) )
}
attributeTypes {
( DestinationAddressRange–OID NAME ’DestinationAddressRange’ SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE–VALUE )
( DestinationPortRange–OID NAME ’DestinationPortRange’ SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE–VALUE )
( FlowServiceType–OID NAME ’FlowServiceType’
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE–VALUE )
( MaxRate–OID NAME ’MaxRate’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE–VALUE )
( MaxTokenBucket–OID NAME ’MaxTokenBucket’ SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE–VALUE )
( OutgoingTos–OID NAME ’OutgoingTos’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE–VALUE )
( PolicyName–OID NAME ’PolicyName’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE–VALUE )
( ProtocolNumber–OID NAME ’ProtocolNumber’ SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE–VALUE )
( SelectorTag–OID NAME ’SelectorTag’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE–VALUE )
( ServiceReference–OID NAME ’ServiceReference’ SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE–VALUE )
( SourceAddressRange–OID NAME ’SourceAddressRange’ SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE–VALUE )
( SourcePortRange–OID NAME ’SourcePortRange’ SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE–VALUE )
}
IBMattributeTypes {
( DestinationAddressRange–OID DBNAME ( ’DestinationAddressRange’
’DestinationAddressRange’ ) )
( DestinationPortRange–OID DBNAME ( ’DestinationPortRange’
’DestinationPortRange’ ) )
( FlowServiceType–OID DBNAME ( ’FlowServiceType’ ’FlowServiceType’ ) )
( MaxRate–OID DBNAME ( ’MaxRate’ ’MaxRate’ ) )
( MaxTokenBucket–OID DBNAME ( ’MaxTokenBucket’ ’MaxTokenBucket’ ) )
( OutgoingTos–OID DBNAME ( ’OutgoingTos’ ’OutgoingTos’ ) )
( PolicyName–OID DBNAME ( ’PolicyName’ ’PolicyName’ ) )
( ProtocolNumber–OID DBNAME ( ’ProtocolNumber’ ’ProtocolNumber’ ) )
( SelectorTag–OID DBNAME ( ’SelectorTag’ ’SelectorTag’ ) )
( ServiceReference–OID DBNAME ( ’ServiceReference’ ’ServiceReference’ ) )
( SourceAddressRange–OID DBNAME ( ’SourceAddressRange’
’SourceAddressRange’ ) )
( SourcePortRange–OID DBNAME ( ’SourcePortRange’ ’SourcePortRange’ ) )
}
ldapSyntaxes {
}
matchingRules {
}
Protocole TCP/IP
4-271
Configuration du système
Politiques superposées
Les politiques qui se superposent sont installées dans QoS Manager dans un ordre non
déterminant. En présence de politiques superposées, l’attribut PolicyRulePriority de
l’instruction ServicePolicyRules doit être spécifié pour déterminer l’ordre d’application
des politiques. Cet attribut prend un entier comme paramètre. En présence de politiques
superposées, la règle dont la valeur d’entier est la plus élevée est mise en application.
Utilisation de sockets UDP
Seules les sockets UDP connectées sont prises en charge pour QoS.
Conflits de politiques avec des réservations RSVP
Les agents de politiques et les agents RSVP sont indépendants. Il convient donc de prendre
garde de ne pas spécifier une politique en conflit avec une réservation RSVP existante ou
couverte par celle–ci. En présence de conflits, le système accepte la première politique ou
réservation et enregistre une violation pour les autres.
Spécification de la profondeur du compartiment à jeton
Pour un fonctionnement correct, l’attribut MaxTokenBucket doit être défini au moins sur le
MTU maximum de toutes les interfaces configurées dans le système.
Modification de politiques
Les modifications de politiques sont gérées par l’agent de politique via la suppression
automatique des politiques existantes et l’installation de nouvelles politiques. Elles peuvent
entraîner une courte période durant laquelle le trafic correspondant reçoit le service par
défaut (en général l’effort maximal).
Conformité aux normes
Cette version est compatible avec les normes IETF actuelles pour les services différenciés
(DiffServ) et les services intégrés (IntServ) sur Internet.
Modèle IntServ
Les normes RFC suivantes décrivent les divers composants du modèle IntServ :
• Utilisation du RSVP avec les services intégrés IETF (RFC 2210)
• Spécification du service d’éléments réseau avec contrôle de charge (RFC 2211)
• Spécification de la qualité de service garantie (RFC 2212)
Modèle DiffServ
Les normes RFC suivantes décrivent les divers composants du modèle DiffServ :
• Définition du champ Services différenciés (champ DS) dans les en–têtes IP versions 4
et 6 (RFC 2474)
• Architecture des services différenciés (RFC 2475)
La norme RFC suivante expose l’utilisation actuelle de l’octet TOS IP :
• Type de service dans la suite Internet Protocol (RFC 1349)
Les normes RFC suivantes exposent les pratiques futures relatives à l’utilisation de l’octet
TOS IP :
• Définition du champ Services différenciés (champ DS) dans les en–têtes IP versions 4
et 6 (RFC 2474)
• Groupe PHB d’acheminement assuré (RFC 2597)
• Groupe PHB d’acheminement expéditif (RFC 2598)
4-272
Guide de gestion du système – Communications et réseaux
Prise en charge de IPv6
QoS for AIX 5.2 prend en charge uniquement IPv4. IPv6 n’est pas pris en charge.
Contrôle du démon de politique
Le démon de politique peut être contrôlé à l’aide de SRC (contrôleur des ressources
système). Par exemple, la commande :
startsrc –s policyd –a ”–i 60”
lance l’agent de politique avec un intervalle d’actualisation de 60 secondes.
La commande
stopsrc –s policyd
arrête le démon de politique.
Remarque :
L’arrêt du démon de politique be supprime pas les politiques installées dans
le noyau. Lorsque vous redémarrez le démon de politique, les anciennes
politiques (déjà installées dans le noyau) sont supprimées et les politiques
définies dans le fichier /etc/policyd.conf sont réinstallées.
Référence QoS
Pour des mises à jour importantes de cette documentation, consultez le fichier README
dans /usr/samples/tcpip/qos.
Commandes
• qosadd
• qoslist
• qosmod
• qosremove
• qosstat
• mkqos
• rmqos
Méthodes
• cfgqos
• ucfgqos
Protocole TCP/IP
4-273
Identification des incidents TCP/IP
Cette section traite du diagnostic des incidents courants en environnement TCP/IP
(Transmission Control Protocol/Internet Protocol).
La commande netstat est très utile pour localiser un incident. Une fois la zone en cause
isolée, vous disposez d’outils plus précis : commandes netstat –i et netstat –v pour
déterminer la présence d’un problème au niveau d’une interface matérielle, puis
programmes de diagnostic pour mieux cerner les causes de l’incident. Ou bien, si la
commande netstat -s a détecté des erreurs de protocole, vous pouvez utiliser la
commande trpt ou iptrace.
Cette section traite des points suivants :
• Incidents de communication, page 4-274
• Incidents de résolution de noms, page 4-274
• Incidents de routage, page 4-276
• Incidents relatifs à la prise en charge SRC, page 4-277
• Incidents liés à telnet ou rlogin, page 4-278
• Incidents de configuration, page 4-280
• Incidents courants sur les interfaces de réseau, page 4-280
• Incidents de livraison de paquets, page 4-284
• Incidents au niveau du protocole DHCP, page 4-284
Incidents de communication
Si vous ne parvenez pas à communiquer avec un hôte de votre réseau :
• Essayez de contacter l’hôte à l’aide de la commande ping. Lancez la commande ping
sur l’hôte local pour vérifier que l’interface locale reliée au réseau est opérationnelle et
active.
• Tentez de résoudre le nom de l’hôte avec la commande host. Si vous n’y parvenez pas,
vous avez un problème de résolution de noms. Pour plus d’informations, reportez–vous
à Incidents de résolution de noms, page 4-274.
Si le nom est résolu et que l’hôte à contacter se trouve sur un autre réseau, il s’agit
peut–être de difficultés de routage. Pour plus d’informations, reportez–vous à Incidents de
routage, page 4-276.
• Sur un réseau en anneau à jeton, vérifiez si l’hôte cible réside sur un autre anneau. Dans
l’affirmative, il est probable que le champ allcast soit mal renseigné. Pour accéder au
menu des interfaces de réseau, vous pouvez utiliser wsm, Web-based System Manager
ou le raccourci SMIT smit chinet. Spécifiez ensuite no dans le champ Confine
Broadcast to Local Ring to, de la boîte de dialogue pour la définition de l’anneau à jeton.
• Si un grand nombre de paquets ARP transitent sur le réseau, vérifiez que votre masque
du sous–réseau est correctement défini. Faute de quoi, vous vous trouvez en présence
d’un conflit de diffusion pouvant affecter les performances de votre système.
Incidents de résolution de noms
Les routines de résolution exécutées sur des hôtes TCP/IP tentent de résoudre les noms en
faisant appel aux sources suivantes et dans l’ordre suivant :
1. au serveur de noms DOMAIN (named),
2. NIS (Network Information Services),
3. au fichier /etc/hosts local.
4-274
Guide de gestion du système – Communications et réseaux
Une fois que NIS + est installé, les préférences de recherche sont définies dans le fichier
irs.conf. Pour plus d’informations, reportez–vous au AIX 5L Version 5.3 Network
Information Services(NIS and NIS+) Guide.
Hôte client
En cas d’échec de résolution d’un nom d’hôte avec le fichier /etc/hosts (réseau plat),
vérifiez que ce fichier contient le nom d’hôte et l’adresse IP correcte.
En cas d’échec de résolution d’un nom d’hôte avec un serveur de noms :
1. Vérifiez que le fichier resolv.conf contient le nom du domaine et l’adresse Internet
d’un serveur de noms.
2. Vérifiez que le serveur de noms local est opérationnel en émettant la commande ping
avec l’adresse IP du serveur (relevée dans le fichier resolv.conf local).
3. Si le serveur de noms est opérationnel, vérifiez que le démon named sur votre serveur
de noms local est actif en émettant la commande lssrc –s named sur le serveur de
noms.
4. Si vous exécutez syslogd, recherchez les éventuels messages d’erreur journalisés.
(la sortie des messages est définie dans le fichier /etc/syslog.conf).
Si ces opérations ne permettent pas d’identifier l’incident, examinez l’hôte serveur de noms.
Hôte serveur de noms
En cas d’échec de résolution d’un nom d’hôte :
1. Vérifiez que le démon named est actif :
lssrc –s named
2. Vérifiez que l’adresse de l’hôte cible existe dans la base de données du serveur de
noms et qu’elle est correcte. Envoyez un signal SIGINT au démon named pour placer
un cliché de la base de données et de la mémoire cache dans le fichier
/var/tmp/named_dump.db. Vérifiez que l’adresse que vous tentez de résoudre s’y
trouve et est correcte.
Ajoutez ou corrigez les informations de résolution nom-adresse dans le fichier de
données hôte named du serveur de noms maître du domaine. Puis, exécutez la
commande SRC ci-dessous pour relire les fichiers de données :
refresh –s named
3. Vérifiez que les demandes de résolution de noms ont été traitées. Pour ce faire, lancez
le démon named à partir de la ligne de commande et spécifiez le niveau de mise au
point (de 1 à 9) sachant que plus le niveau est élevé, plus le mécanisme de mise au
point consigne d’informations.
startsrc –s named –a ”–d DebugLevel”
4. Recherchez d’éventuelles erreurs de configuration dans les fichiers de données named.
Pour en savoir plus, reportez–vous à Serveur de noms – Généralités, on page 4-76.
Vous pouvez aussi consulter “DOMAIN Data File Format,”, “DOMAIN Reverse Data File
Format,” “DOMAIN Cache File Format,” et “DOMAIN Local Data File Format” dans le
manuel AIX 5L Version 5.3 Files Reference.
Remarque :
le plus souvent, les erreurs proviennent d’une mauvaise utilisation du
point (.) et de l’arrobas (@) dans les fichiers de données DOMAIN.
Si des utilisateurs externes ne peuvent accéder à vos domaines :
• Vérifiez que tous vos serveurs de noms non maîtres (esclave, cache) sont définis avec
les mêmes délais TTL dans les fichiers de données DOMAIN.
Protocole TCP/IP
4-275
Si vos serveurs sont continuellement sollicités par des routines de résolution externes :
• Assurez–vous que vos serveurs diffusent des fichiers de données DOMAIN avec des
délais TTL suffisants. Si la valeur TTL est nulle ou négligeable, le délai accordé aux
données transférées s’écoule très rapidement. Pour y remédier, prévoyez au moins une
semaine comme valeur minimum dans vos enregistrements SOA.
Incidents de routage
Si vous ne parvenez pas à accéder à un hôte de destination, contrôlez les points suivants :
• Si vous recevez le message Network Unreachable, vérifiez la route vers l’hôte
passerelle. Lancez la commande netstat -r pour afficher la liste des tables de routage
noyau.
• Si vous recevez le message No route to host (hôte sans route), vérifiez que
l’interface de réseau local est opérationnelle en lançant la commande ifconfig
nom_interface. Le résultat doit indiquer ”up”. Lancez la commande ping pour tenter
d’atteindre un autre hôte du réseau.
• Si vous recevez le message Connection timed out :
– Vérifiez que la passerelle locale est opérationnelle à l’aide de la commande ping
assortie du nom ou de l’adresse Internet de la passerelle.
– Vérifiez qu’une route vers l’hôte passerelle a été correctement définie. Lancez la
commande netstat -r pour afficher la liste des tables de routage noyau.
– Vérifiez que l’hôte qui vous intéresse dispose d’une entrée de table de routage
renvoyant à votre machine.
• Si vous utilisez le routage statique, assurez–vous qu’une route vers l’hôte cible et l’hôte
passerelle a été définie. Lancez la commande netstat -r pour afficher la liste des tables
de routage noyau.
Remarque :
L’hôte qui vous intéresse doit disposer d’une entrée de table de routage
renvoyant à votre machine.
• En routage dynamique, vérifiez, à l’aide de la commande netstat –r, que la passerelle
est répertoriée dans les tables de routage noyau et qu’elle est correcte.
• Si l’hôte passerelle utilise le protocole RIP avec le démon routed, vérifiez qu’une route
statique d’accès à l’hôte cible est définie dans le fichier /etc/gateways.
Remarque :
Cette opération n’est requise que si le démon de routage ne parvient pas à
identifier la route vers l’hôte distant en interrogeant les autres passerelles.
• Si l’hôte passerelle utilise RIP avec le démon gated, vérifiez qu’une route statique
d’accès à l’hôte cible est définie dans le fichier gated.conf.
• En routage dynamique avec le démon routed :
– Si routed ne parvient pas à identifier la route par le biais de demandes (par exemple,
si l’hôte cible n’exécute pas le protocole RIP), vérifiez qu’une route d’accès à l’hôte
cible est définie dans le fichier /etc/gateways.
– Vérifiez que les passerelles chargées d’expédier les paquets à l’hôte sont
opérationnelles et exécutent RIP. Sinon, vous devez définir une route statique.
– Exécutez le démon routed avec l’option de mise au point pour journaliser les
anomalies (réception de paquets erronés par exemple). Appelez le démon à partir de
la ligne de commande, comme suit :
startsrc –s routed –a ”–d”
– Exécutez le démon routed avec l’indicateur –t pour envoyer tous les paquets entrants
et sortants vers la sortie standard. Exécuté dans ce mode, routed reste sous le
contrôle du terminal qui l’a lancé. Et il peut être arrêté depuis ce terminal.
4-276
Guide de gestion du système – Communications et réseaux
• En routage dynamique avec le démon gated :
– Vérifiez que le fichier /etc/gated.conf est correctement configuré et que vous
exécutez les protocoles adéquats.
– Vérifiez que les passerelles sur les réseaux source et cible utilisent le même
protocole.
– Vérifiez que la machine que vous tentez de contacter dispose d’une route retour vers
votre machine hôte.
– Vérifiez que les noms de passerelle des fichiers gated.conf et /etc/networks
correspondent.
• Si vous utilisez le protocole RIP ou HELLO et que les routes d’accès ne peuvent pas être
identifiées par des demandes de routage, vérifiez qu’une route d’accès à l’hôte cible est
définie dans le fichier gated.conf. Il est conseillé de définir des routes statiques si :
– L’hôte de destination n’exécute pas le même protocole que l’hôte source et ne peut
donc pas échanger d’informations de routage.
– L’accès à l’hôte doit se faire par une passerelle distante (c’est-à-dire sur un autre
système autonome que l’hôte source). Le protocole RIP peut être utilisé uniquement
entre des hôtes d’un même système autonome.
Autres possibilités
Si aucune des solutions proposées n’aboutit, vous pouvez activer le suivi du démon de
routage (routed ou gated). Exécutez la commande SRC traceson à partir de la ligne de
commande ou envoyez un signal au démon pour spécifier différents niveaux de suivi. Pour
en savoir plus, reportez-vous au démon gated ou routed.
Incidents SRC
• Si les modifications apportées au fichier /etc/inetd.conf ne sont pas prises en compte :
Mettez à jour le démon inetd via la commande refresh –s inetd ou kill –1 InetdPID.
• Si startsrc –s [sous_système] renvoie le message :
0513–00 The System Resource Controller is not active.
Le sous-système SRC (System Resource Controller) n’a pas été activé. Lancez la
commande srcmstr & pour lancer SRC, puis à nouveau la commande startsrc.
Vous pouvez tenter de lancer le démon à partir de la ligne de commande sans SCR.
• Si refresh –s [sous_système] ou lssrc –ls [sous_système] renvoie le message :
[nom sous système] does not support this option.
Le sous-système ne prend pas en charge l’option SRC émise. Consultez la
documentation relative au sous-système.
• Si le message ci-dessous s’affiche :
SRC was not found, continuing without SRC support.
Un démon a été appelé directement à partir de la ligne de commande et non via la
commande startsrc. Ceci ne constitue pas un incident. Toutefois les commandes SRC
(telles que stopsrc et refresh) ne peuvent pas être utilisées pour manipuler un
sous-système appelé directement.
Le démon inetd est installé, s’exécute correctement et le service approprié ne présente pas
de problème, mais la connexion est impossible ; analysez le démon inetd à l’aide d’un
programme de mise au point.
1. Arrêtez temporairement le démon inetd en tapant :
stopsrc –s inetd
La commande stopsrc arrête les sous–systèmes tel que le démon inetd.
Protocole TCP/IP
4-277
2. Modifiez le fichier syslog.conf pour ajouter une ligne relative à la mise au point à la fin.
Par exemple :
vi /etc/syslog.conf
a. Ajoutez la ligne ”*.debug /tmp/monfichier” à la fin du fichier, puis quittez.
b. Le fichier spécifié doit être un fichier existant (/tmp/monfichier dans cet
exemple). Pour valider l’existence du fichier, vous pouvez utiliser la commande
touch.
3. Rafraîchissez le fichier :
– Si vous utilisez SRC, entrez :
refresh –s syslogd
– Si vous n’utilisez pas SRC, arrêtez le démon syslogd :
kill –1 ‘ps –e | grep /etc/syslogd | cut –c1–7‘
4. Lancez la sauvegarde du démon inetd en y associant l’activation de la mise au point :
startsrc –s inetd –a ”–d”
L’indicateur –d active la mise au point.
5. Exécutez une connexion pour détecter les erreurs dans le fichier de mise au point
/tmp/monfichier. Par exemple :
tn bastet
Trying...
connected to bastet
login:>
Connection closed
6. Examinez le fichier de mise au point à la recherche d’éventuels problèmes.
Par exemple :
tail –f /tmp/monfichier
Incidents liés à telnet ou rlogin
Voici quelques indications sur les incidents liés aux commandes telnet et rlogin.
Distorsion de l’écran
Si vous rencontrez des problèmes de distorsion d’écran dans des applications plein écran :
1. Vérifiez la variable d’environnement TERM, via la commande :
env
OU
echo $TERM
2. Vérifiez que la valeur de TERM concorde avec le type d’écran de terminal utilisé.
Mise au point par telnet
Les sous-commandes telnet qui peuvent vous aider à résoudre des incidents sont :
display
Affiche les valeurs définies et les valeurs de commutation.
toggle
Affiche toutes les données réseau en hexadécimal.
toggle options Change l’affichage des options internes du process telnet.
4-278
Guide de gestion du système – Communications et réseaux
Mise au point du démon telnetd
Si le démon inetd exécute le service telnet, alors que vous n’êtes toujours pas en mesure
de vous connecter à l’aide de la commande telnet, cela signifie qu’il y a un problème au
niveau de l’interface telnet.
1. Vérifiez que telnet utilise le type de terminal correct.
a. Vérifiez la variable $TERM sur votre machine :
echo $TERM
b. Connectez–vous à la machine que vous souhaitez relier et vérifiez la variable
$TERM :
echo $TERM
2. Utilisez les fonctions de mise au point de l’interface telnet en utilisant la commande
telnet sans indicateur.
telnet
tn>
a. Entrez open hôte (hôte est le nom de la machine).
b. Appuyez sur Ctrl–T pour rappeler l’invite tn%gt;.
c. A l’invite tn>, entrez debug pour accéder au mode mise au point.
3. Essayez de vous connecter à une autre machine en utilisant l’interface telnet :
telnet bastet
Trying...
Connected to bastet
Escape character is ’^T’.
Observez le défilement des différentes commandes à l’écran. Par exemple :
SENT do ECHO
SENT do SUPPRESS GO AHEAD
SENT will TERMINAL TYPE (reply)
SENT do SUPPORT SAK
SENT will SUPPORT SAK (reply)
RCVD do TERMINAL TYPE (don’t reply)
RCVD will ECHO (don’t reply)
RCVD will SUPPRESS GO AHEAD (don’t reply)
RCVD wont SUPPORT SAK (reply)
SENT dont SUPPORT SAK (reply)
RCVD do SUPPORT SAK (don’t reply)
SENT suboption TELOPT_NAWS Width 80, Height 25
RCVD suboption TELOPT_TTYPE SEND
RCVD suboption TELOPT_TTYPE aixterm
...
4. Vérifiez la définition de aixterm dans les répertoires /etc/termcap ou /usr/lib/terminfo.
Par exemple :
ls –a /usr/lib/terminfo
5. Si la définition de aixterm est manquante, ajoutez–la en créant le fichier ibm.ti.
Par exemple :
tic ibm.ti
La commande tic est un compilateur d’informations de terminal.
Protocole TCP/IP
4-279
Programmes utilisant la bibliothèque curses étendue
Certains problèmes peuvent apparaître au niveau des touches de fonction et des touches
fléchées si vous utilisez les commandes rlogin et telnet avec des programmes faisant
appel à la bibliothèque curses étendue. En effet, ces touches génèrent des séquences
d’échappement, qui peuvent être dissociées si le temps imparti ne suffit pas à la séquence
complète. Après un certain délai, la bibliothèque curses décide si Echap doit être interprété
seul ou comme le début d’une séquence d’échappement multi-octets générée par d’autres
touches (touches fléchées, touches de fonction ou touche Action).
Si, dans le temps imparti, la touche Echap n’est suivie d’aucune donnée valide, curses
l’interprète comme la touche Echap seule et fractionne la séquence de touches. Le délai
associé aux commandes rlogin ou telnet dépend du réseau. C’est en fonction de sa
vitesse que les touches de fonction et les touches fléchées fonctionnent normalement ou
non. Pour résoudre efficacement le problème, attribuez une valeur élevée (entre 1000 et
1500) à la variable d’environnement ESCDELAY.
Incidents de configuration
Une fois la carte installée, les interfaces de réseau sont automatiquement configurées au
premier lancement du système. Il reste toutefois certaines valeurs initiales à définir pour
TCP/IP, telles que le nom de l’hôte, l’adresse Internet et le masque de sous–réseau. Pour
cela, vous pouvez utiliser wsm, Web-based System Manager ou l’interface SMIT comme
suit :
• Servez-vous du raccourci smit mktcpip pour définir les valeurs initiales pour le nom
d’hôte, l’adresse Internet et le masque de sous–réseau.
• Cette commande smit mktcpip permet également de spécifier un serveur pour la
résolution de noms. Cependant, smit mktcpip ne configure qu’une seule interface de
réseau.
• Pour définir d’autres attributs de réseau, utilisez le raccourci smit chinet.
Si vous souhaitez mettre en place des routes statiques pour que l’hôte puisse acheminer
des informations de transmission, par exemple une route d’accès à la passerelle locale,
définissez–les de façon permanente dans la base de configuration, avec Web-based
System Manager, wsm, ou le raccourci SMIT smit mkroute.
Si vous rencontrez d’autres problèmes de configuration, reportez–vous à Configuration
d’une liste de contrôle du réseau TCP/IP, page 4-4.
Incidents courants sur les interfaces de réseau
Une fois la carte installée, les interfaces de réseau sont automatiquement configurées au
premier lancement du système. Il reste toutefois certaines valeurs initiales à définir pour
TCP/IP. Par exemple, il est possible de définir le nom d’hôte et l’adresse Internet à l’aide de
wsm de Web-based System Manager ou du raccourci smit mktcpip de SMIT.
Si vous passez par SMIT, ayez recours au raccourci smit mktcpip pour définir ces valeurs
de façon permanente dans la base de configuration. Pour les modifier dans le système actif,
utilisez les raccourcis smit chinet et smit hostname. Le raccourci smit mktcpip permet
une configuration minimale de TCP/IP. Pour ajouter des cartes, passez par le menu Further
Configuration, accessible via le raccourci smit tcpip.
Si, malgré la validité des valeurs définies, vous avez toujours des difficultés à recevoir et
envoyer des données :
• Vérifiez que votre carte réseau dispose d’une interface de réseau en exécutant la
commande netstat –i. La sortie doit mentionner une interface, par exemple tr0, dans la
colonne Name. Dans le cas contraire, créez une interface de réseau via Web-based
System Manager ou via le raccourci smit mkinet de SMIT.
• Vérifiez que l’adresse IP de l’interface est correcte, en exécutant netstat –i. La sortie doit
afficher l’adresse IP dans la colonne Network. Si l’adresse est incorrecte, modifiez-la via
Web-based System Manager ou via le raccourci SMIT smit chinet.
4-280
Guide de gestion du système – Communications et réseaux
• Utilisez la commande arp pour vérifier que l’adresse IP de la machine cible est complète.
Par exemple :
arp –a
La commande arp recherche l’adresse physique de la carte. Cette commande risque de
renvoyer une adresse incomplète. Par exemple :
? (192.100.61.210) à (incomplète)
Les raisons peuvent être les suivantes : une machine débranchée, une adresse isolée
sans machine à l’adresse spécifique ou un problème matériel (par ex. une machine en
mesure de se connecter et de recevoir des paquets mais qui ne peut pas les renvoyer).
• Recherchez les erreurs au niveau de la carte. Par exemple :
netstat –v
La commande netstat –v affiche les données statistiques au niveau des pilotes des
périphériques Ethernet, Token Ring, X.25 et 802.3. Elle révèle également les données
relatives aux connexions au réseau et aux erreurs de connexion pour tous les pilotes de
périphériques actifs sur une interface, y compris :
No Mbufs Errors,No Mbuf Extension Errors,
Packets Transmitted et Adapter
Errors Detected.
• Consultez le journal des erreurs, en lançant la commande errpt, pour vérifier qu’aucun
incident de carte n’a été détecté.
• Vérifiez que la carte est fiable en exécutant les programmes de diagnostics. Pour cela,
utilisez l’application Devices de Web-based System Manager, le raccourci smit diag ou
la commande diag.
Si ces étapes ne permettent pas d’identifier le problème, reportez–vous à Problèmes
d’interface réseau SLIP, page 4-281,
Problèmes d’interface réseau Ethernet page 4-282, ou Problème d’interface réseau en
anneau jeton.
Incidents sur une interface de réseau SLIP
En général, la méthode la plus efficace pour résoudre ce type d’incident consiste à vérifier
pas à pas la configuration de votre système. Vous pouvez également :
• Vérifiez que le process slattach s’exécute sur le port tty approprié, via la commande ps
–ef. Si ce n’est pas le cas, lancez la commande slattach. (Pour la syntaxe à utiliser,
reportez–vous à Configuration de SLIP pour modem, page 8-70 ou à Configuration de
SLIP pour câble de modem nul, page 8-72.)
• Vérifiez les adresses point-à-point spécifiées via la commande smit chinet.
Sélectionnez l’interface SLIP. Vérifiez l’adresse Internet et l’adresse de destination.
Si le modem ne fonctionne pas correctement :
• Vérifiez son installation. Reportez-vous au manuel opérateur du modem.
• Vérifiez que les contrôles de flux que le modem peut effectuer sont désactivés.
Si le tty ne fonctionne pas correctement, vérifiez le débit (en bauds) correspondant ainsi
que les caractéristiques du modem, dans la base de données de configuration, via la
commande smit tty.
Protocole TCP/IP
4-281
Incidents sur l’interface de réseau Ethernet
Si une interface réseau est initialisée, les adresses définies et la carte installée correcte :
• Vérifiez qu’un connecteur en T est directement branché sur l’émetteur-récepteur
(intégré ou non).
• Assurez–vous que vous utilisez un câble Ethernet. Le câble Ethernet est de 50 OHM.
• Assurez–vous que vous utilisez des terminaisons Ethernet. Les terminaisons Ethernet
sont de 50 OHM.
• Les cartes Ethernet peuvent fonctionner avec un émetteur-récepteur interne ou externe.
Un cavalier, installé sur la carte, définit le type d’émetteur-récepteur utilisé. Vérifiez la
position de ce cavalier (reportez-vous à la documentation de la carte).
• Vérifiez le type de connecteur utilisé (BNC pour câble fin et DIX pour câble épais).
Si vous changez ce type de connecteur, vous devez définir le champ Apply Change to
Database Only (appliquer les modifications uniquement à la base de données) ; pour ce
faire, utilisez wsm de Web-based System Manager ou le raccourci smit chgenet de
SMIT. Ce champ doit être coché dans Web-based System Manager ou défini à yes dans
SMIT. Réamorcez ensuite la machine pour appliquer la nouvelle configuration.
(Reportez-vous à “Configuration et gestion des cartes”, page 4-39.)
Incidents liés à une interface de réseau en anneau à jeton
Si vous ne parvenez pas communiquer avec certaines machines, alors que l’interface de
réseau est initialisée, les adresses convenablement définies et la carte installée correcte :
• Vérifiez si les machines en cause se trouvent sur un autre anneau. Si tel est le cas,
utilisez wsm de Web-based System Manager ou le raccourci smit chinet de SMIT pour
cocher le champ Confine BROADCAST to Local Token–Ring (limiter la diffusion à
l’anneau à jeton local). Ce champ ne doit pas être coché dans Web-based System
Manager ou défini à no dans SMIT.
• Vérifiez que la carte de réseau en anneau à jeton est configurée pour fonctionner à la
bonne vitesse d’anneau. Si sa configuration est incorrecte, utilisez l’application
Web–based System Manager Network ou SMIT pour modifier l’attribut de vitesse de
l’anneau à jeton (reportez–vous à Configuration et gestion des cartes, page 4-39).
Une fois TCP/IP redémarré, la vitesse d’anneau de la carte de réseau en anneau à jeton
sera identique à celle du réseau.
Incidents avec un pont anneau à jeton/Ethernet
Si la communication entre un réseau en anneau à jeton et un réseau Ethernet reliés par un
pont est défaillante alors que le pont fonctionne normalement, il est probable que la carte
Ethernet rejette des paquets. Ce rejet a lieu lorsque le nombre de paquets entrants
(en-têtes compris) est supérieur à la valeur MTU (Maximum Transmission Unit) de la carte.
Par exemple, un paquet de 1500 octets envoyé par une carte en anneau à jeton via un
pont, totalise 1508 octets, avec un en-tête LLC de 8 octets. Si la valeur MTU de la carte
Ethernet est fixée à 1500, le paquet est rejeté.
Vérifiez les valeurs MTU (Maximum Transmission Unit) des deux cartes de réseau.
Pour autoriser l’adjonction, par la carte en anneau à jeton, d’en-têtes LLC de 8 octets aux
paquets sortants, la valeur MTU de cette carte doit être inférieure d’au moins 8 octets à
celle de la carte Ethernet. Par exemple, pour qu’une carte en anneau à jeton puisse
communiquer avec une carte Ethernet avec une MTU de 1500 octets, sa MTU doit être
fixée à 1492.
4-282
Guide de gestion du système – Communications et réseaux
Incidents sur un pont reliant deux réseaux en anneau à jeton
Lorsque la communication transite par un pont, la valeur MTU par défaut (de 1500 octets)
doit être ramenée à 8 octets en-dessous de la valeur maximum I-frame déclarée par le pont
dans le champ de contrôle de routage.
Pour retrouver la valeur du contrôle de routage, exécutez le démon iptrace qui permet
d’examiner les paquets entrants. Les bits 1, 2 et 3 de l’octet 1 constituent les bits de trames
maximales (Largest Frame Bit). Ils déterminent le maximum d’informations transmissibles
entre deux stations de communication sur une route spécifique. Pour le format du champ de
contrôle de routage, consultez la figure ci-dessous :
Figure 27. Champ de contrôle de routage Cette illustration représente l’octet 0 et l’octet 1
d’un champ de contrôle de routage. Les 8 bits de l’octet zéro sont B, B, B, B, L, L, L, L.
Les 8 bits de l’octet 1 sont T D, F, F, F, r, r, r, r.
Les valeurs possibles des bits de trames maximales sont :
000
516 octets maximum dans le champ d’information.
001
1500 octets maximum dans le champ d’information.
010
2052 octets maximum dans le champ d’information.
011
4472 octets maximum dans le champ d’information.
100
8144 octets maximum dans le champ d’information.
101
Réservé.
110
Réservé.
111
Utilisé dans les trames de diffusion générale (toute route).
Par exemple, si la valeur de ”maximum I-frame” est 5 212.08 cm dans le champ de contrôle
de routage, celle de MTU doit être fixée à 2044 (pour les interfaces anneau à jeton
seulement).
Remarque :
Lorsque vous utilisez iptrace, le fichier de sortie ne doit pas résider sur un
système de fichiers NFS.
Protocole TCP/IP
4-283
Incidents de livraison de paquets
Communication avec un hôte distant
Si vous ne parvenez pas à établir la communication avec un hôte distant :
• Lancez la commande ping sur l’hôte local pour vérifier que l’interface locale reliée au
réseau est opérationnelle et active.
• Appliquez la commande ping successivement aux hôtes et passerelles par lesquelles
l’information transite, pour localiser la défaillance.
Si vous constatez des pertes de paquet ou des retards de livraison :
• Lancez la commande trpt pour effectuer un suivi des paquets au niveau socket.
• Lancez la commande iptrace pour effectuer le suivi de toutes les couches de protocole.
Si vous ne parvenez pas à établir la communication entre un réseau en anneau à jeton et
un réseau Ethernet reliés par un pont qui fonctionne normalement :
• Vérifiez les valeurs MTU (Maximum Transmission Unit) des deux cartes de réseau.
Elles doivent être compatibles pour autoriser la communication. En effet, si la taille du
paquet entrant (en-têtes compris) est supérieure à la valeur MTU (Maximum
Transmission Unit) de la carte, la machine rejette le paquet. Par exemple, un paquet de
1500 octets envoyé via un pont récupère un en-tête LLC de 8 octets pour atteindre une
taille de 1508 octets. Si la valeur MTU de la machine réceptrice est fixée à 1500,
le paquet est rejeté.
Réponses snmpd
Si snmpd ne répond pas et qu’aucun message d’erreur n’est transmis, il est probable que
la taille du paquet est trop grande pour le gestionnaire de paquets UDP noyau. Dans ce
cas, augmentez la valeur des variables du noyau udp_sendspace et udp_recvspace :
no –o udp_sendspace=64000
no –o udp_recvspace=64000
La taille maximum d’un paquet UPD est de 64 Ko. La requête est rejetée si elle dépasse
64 Ko. Pour éviter ce type d’incident, le paquet doit être fractionné.
Incidents au niveau du protocole DHCP
Si vous ne pouvez pas obtenir une adresse IP ou d’autres paramètres de configuration :
• Assurez–vous qu’une interface à configurer a été spécifiée. Pour cela, éditez le fichier
/etc/dhcpcd.ini à l’aide de l’application Network de Web-based System Manager ou à
l’aide du raccourci smit dhcp de SMIT.
• Vérifiez qu’il existe un serveur sur le réseau local ou un agent relais configuré
pour acheminer vos requêtes hors du réseau local.
• Vérifiez que le programme dhcpcd est actif. Dans la négative, lancez-le via la
commande startsrc –s dhcpcd.
4-284
Guide de gestion du système – Communications et réseaux
Informations de référence TCP/IP
Les thèmes relatifs au protocole TCP/IP abordés dans cette section sont les suivants :
•
Liste des commandes TCP/IP, page 4-285
•
Liste des démons TCP/IP, page 4-286
•
Liste des méthodes, page 4-286
•
Liste des fichiers TCP/IP, page 4-286
•
Liste des RFC, page 4-287
Liste des commandes TCP/IP
chnamsv
Modification sur un hôte de la configuration du service de noms
TCP/IP.
chprtsv
Modification de la configuration d’un service d’impression sur une
machine client ou serveur.
hostent
Manipulation directe des entrées d’équivalence d’adresse dans la
base de données de configuration du système.
ifconfig
Configuration/affichage des paramètres d’interface d’un réseau
TCP/IP.
mknamsv
Configuration sur un hôte du service de noms TCP/IP pour un client.
mkprtsv
Configuration sur un hôte d’un service d’impression TCP/IP.
mktcpip
Définition des valeurs requises pour le lancement de TCP/IP sur un
hôte.
no
Configuration des options de réseau.
rmnamsv
Déconfiguration sur un hôte du service de noms TCP/IP.
rmprtsv
Déconfiguration de la configuration d’un service d’impression sur une
machine client ou serveur.
slattach
Raccordement des lignes série comme interfaces de réseau.
arp
Affichage/modification des tables de traduction d’adresse Internet en
adresse matérielle, utilisées par ARP (Address Resolution Protocol).
gettable
Récupération à partir d’un hôte des tables d’hôte au format NIC
Informations relatives au matériel ESCALA Power5.
hostid
Définition ou affichage de l’identificateur de l’hôte local courant.
hostname
Définition ou affichage du nom du système hôte courant.
htable
Conversion des fichiers hôtes au format utilisé par les routines de
bibliothèque de réseau.
ipreport
Génération d’un rapport de suivi de paquet à partir du fichier spécifié.
iptrace
Suivi des paquets au niveau interface pour les protocoles Internet.
lsnamsv
Affichage des informations du service de noms stockées dans la base
de données.
lsprtsv
Affichage des informations du service d’impression stockées dans la
base de données.
mkhosts
Génération du fichier de tables hôte.
namerslv
Manipulation directe des entrées de serveur de noms de domaine
pour les routines de résolution dans la base de données de
configuration.
netstat
Affichage de l’état du réseau.
Protocole TCP/IP
4-285
route
Manipulation directe des tables de routage.
ruser
Manipulation directe des entrées de trois bases de données système
distinctes contrôlant l’accès des hôtes étrangers aux programmes
locaux.
ruptime
Affichage de l’état de chaque hôte d’un réseau.
securetcpip
Activation de la fonction de sécurité réseau.
setclock
Définition de la date et de l’heure d’un hôte sur un réseau.
timedc
Informations sur le démon timed.
trpt
Suivi des prises TCP (Transmission Control Protocol).
Liste des démons TCP/IP
fingerd
Affichage des informations sur un utilisateur distant.
ftpd
Fonction serveur pour le protocole FTP (File Transfer Protocol) d’Internet.
gated
Apport des fonctions de routage de passerelles aux protocoles RIP (Routing
Information Protocol), HELLO, EGP (Exterior Gateway Protocol), BGP
(Border Gateway Protocol) et SNMP (Simple Network Management
Protocol).
inetd
Gestion du service Internet pour un réseau.
named
Apport de la fonction serveur au protocole DOMAIN.
rexecd
Apport de la fonction serveur à la commande rexec.
rlogind
Apport de la fonction serveur à la commande rlogin.
routed
Gestion des tables de routage de réseau.
rshd
Apport de la fonction serveur pour l’exécution de commandes à distance.
rwhod
Apport de la fonction serveur aux commandes rwho et ruptime.
syslogd
Lecture et consignation des messages système.
talkd
Apport de la fonction serveur à la commande talk.
telnetd
Apport de la fonction serveur au protocole TELNET.
tftpd
Assure la fonction serveur pour le protocole TFTP (Trivial File Transfer
Protocol).
timed
Appel au démon timeserver au lancement du système.
Liste des méthodes
Les méthodes d’unité sont des programmes associés à une unité qui exécutent des
opérations de base de configuration d’unité. Pour en savoir plus sur les méthodes TCP/IP,
reportez-vous à la liste des références de programmation TCP/IP dans le manuel AIX 5L
Version 5.3 Communications Programming Concepts.
Liste des fichiers TCP/IP
/etc/rc.bsdnet
Pour en savoir plus sur les méthodes et les formats de fichier TCP/IP, reportez-vous à la
liste des références de programmation TCP/IP dans le manuel AIX 5L Version 5.3
Communications Programming Concepts.
4-286
Guide de gestion du système – Communications et réseaux
Liste des RFC
Pour connaître la liste des RFC (Request for Comments) pris en charge par ce système,
reportez-vous à la liste des références de programmation TCP/IP dans le manuel AIX 5L
Version 5.3 Communications Programming Concepts.
• RFC 1359 Connecting to the Internet: What connecting institutions should anticipate
• RFC 1325 FYI on questions and answers: Answers to commonly asked ’new Internet
user’ questions
• RFC 1244 Site Security Handbook
• RFC 1178 Choosing a Name for Your Computer
• RFC 1173 Responsibilities of host and network managers: A summary of the ‘oral
tradition’ of the Internet
Protocole TCP/IP
4-287
4-288
Guide de gestion du système – Communications et réseaux
Chapitre 5. Administration du réseau
Administrer un réseau consiste à gérer globalement des réseaux systèmes,
via le protocole SNMP, permettant aux hôtes d’échanger des informations de gestion.
SNMP (Simple Network Management Protocol) est un protocole conçu pour les
interréseaux basés sur TCP/IP. Ce chapitre traite des points suivants :
• Administration de réseau avec SNMP, page 5-2
• SNMPv3, page 5-3
• SNMPv1, page 5-13
Lorsque AIX 5.2 est installé, la version non chiffrée de SNMPv3 est installée par défaut
et démarrée lors de l’amorçage du système. Si vous avez configuré vos propres
communautés, vos interruptions et vos entrées smux dans le fichier /etc/snmpd.conf,
vous devez les faire migrer manuellement vers le fichier /etc/snmpdv3.conf. Pour plus
d’informations sur la migration des communautés, reportez–vous à Migration de SNMPv1
vers SNMPv3, page 1-10.
Vous pouvez également consulter ces informations dans SNMP Overview for Programmers
dans le manuel AIX 5L Version 5.3 Communications Programming Concepts.
Administration du réseau
5-1
Administration de réseau avec SNMP
L’administration de réseau SNMP repose sur le modèle client/serveur, largement exploité
dans les applications basées sur TCP/IP. Chaque hôte à gérer exécute un processus
appelé un agent. L’agent est un processus serveur qui maintient la base de données MIB
(Management Information Base) pour l’hôte. Les hôtes impliqués dans les décisions
d’administration du réseau peuvent exécuter un processus appelé un gestionnaire.
Un gestionnaire est une application client qui génère les requêtes d’informations à la MIB
et traite les réponses. Un gestionnaire peut en outre envoyer des requêtes aux serveurs
de l’agent pour modifier les informations MIB.
SNMP sous AIX prend en charge les RFC suivants :
5-2
RFC 1155
Structure et identification des données de gestion (SMI) pour
les interréseaux TCP/IP
RFC 1157
SNMP (Simple Network Management Protocol)
RFC 1213
Base MIB pour l’administration des interréseaux basés sur TCP/IP :
MIB–II
RFC 1227
Protocole SNMP (Simple Network Management Protocol),
protocole SMUX (single multiplexer) et base MIB (Management
Information Base).
RFC 1229
Extensions à l’interface générique MIB
(Management Information Base)
RFC 1231
MIB (Management Information Base) anneau à jeton IEEE 802.5
RFC 1398
Définitions des objets gérés pour les types d’interface Ethernet
RFC 1512
Base MIB FDDI
RFC 1514
Base MIB des ressources hôte
RFC 1592
SNMP–DPI (Simple Network Management Protocol–Distributed
Program Interface) Version 2
RFC 1905
Opérations de protocole pour la Version 2 de Simple Network
Management Protocol (SNMPv2)
RFC 1907
Base MIB pour la Version 2 de Simple Network Management
Protocol (SNMPv2)
RFC 2572
Traitement et envoi des messages pour Simple Network
Management Protocol (SNMP)
RFC 2573
Applications SNMP
RFC 2574
Modèle de sécurité utilisateur USM (User–based Security Model)
pour la version 3 de Simple Network Management Protocol
(SNMPv3)
RFC 2575
Modèle VACM (View–based Access Control Model) pour Simple
Network Management Protocol (SNMP)
Guide de gestion du système – Communications et réseaux
SNMPv3
Les informations de cette section concernent uniquement SNMPv3.
Cette section traite des points suivants :
• Présentation de SNMPv3, page 5-4
• Architecture de SNMPv3, page 5-5
• Clés d’utilisateur SNMPv3, page 5-7
• Envoi de requêtes SNMPv3, page 5-10
• Identification des incidents SNMPv3, page 5-11
En outre, les tâches SNMPv3 suivantes sont aussi traitées :
• Migration de SNMPv1 vers SNMPv3, page 1-10
• Création d’utilisateurs dans SNMPv3, page 1-14
• Mise à jour dynamique des clés d’authentification et de confidentialité dans SNMPv3,
page 1-19
Administration du réseau
5-3
Présentation de SNMPv3
Avant la version AIX 5.2, SNMPv1 était la seule version disponible de SNMP pour AIX.
SNMPv3 est fourni avec AIX 5.2. SNMPv3 fournit une structure puissante et souple à la
sécurité des messages et au contrôle de sécurité. La sécurité des message fournit les
fonctionnalités suivantes :
• Le contrôle d’intégrité des données qui évite la corruption des données en transit
• La vérification de l’origine des données qui garantit que la requête ou la réponse est bien
envoyée par la source revendiquée
• La vérification des dates des messages et facultativement, la confidentialité des données
contre les accès non autorisées
L’architecture SNMPv3 met en œuvre le modèle USM (User–based Security Model) pour
la sécurité des messages et le modèle VACM (View–based Access Control Model) pour le
contrôle des accès. L’architecture prend en charge l’utilisation simultanée de différents
modèles de sécurité, de contrôle des accès et de traitement des messages. Par exemple,
la sécurité basée sur la communauté peut être utilisée simultanément avec USM.
USM fait appel au concept d’un utilisateur pour lequel les paramètres de sécurité (niveaux
de sécurité, authentification et protocoles de confidentialité, et clés) sont configurés sur
l’agent et le gestionnaire. Les messages envoyés via USM sont mieux protégés que ceux
utilisant une sécurité basée sur la communauté, dans lesquels les mots de passe sont
envoyés en clair et affichés dans les fichiers de traces. Avec USM, les messages échangés
entre le gestionnaire et l’agent bénéficient de l’intégrité des données et de l’authentification
de l’origine des données. Les retards et les renvois répétés de messages (hormis leurs
occurrences normales en cas de protocole de transmission sans connexion) sont évités
grâce à des indicateurs d’horodatage et des ID de requête. La confidentialité des données,
ou le chiffrement, est également disponible, si cela est autorisé, sous la forme d’un produit
installable séparément. La version SNMP chiffrée est fournie avec AIX Expansion Pack.
L’utilisation de VACM consiste à définir des collections de données (appelées des vues),
des groupes d’utilisateurs des données et des instructions d’accès qui définissent les vues
qu’un groupe d’utilisateurs particulier peut employer pour une opération de lecture,
d’écriture ou de réception dans une interruption.
SNMPv3 permet également de configurer dynamiquement l’agent SNMP en lançant les
commandes SNMP SET sur les objets MIB représentant la configuration de l’agent. Cette
configuration dynamique prend en charge l’ajout, la suppression et la modification des
entrées de configuration, localement ou à distance.
Les politiques d’accès SNMPv3 et les paramètres de sécurité sont spécifiés dans le fichier
/etc/snmpdv3.conf sur l’agent SNMP et le fichier /etc/clsnmp.conf dans le gestionnaire
SNMP. Vous trouverez un scénario sur la configuration des fichiers dans Création des
utilisateurs dans SNMPv3, page 1-14. Vous pouvez aussi consulter les formats des fichiers
/etc/snmpdv3.conf et /etc/clsnmp.conf dans AIX 5L Version 5.3 Files Reference.
5-4
Guide de gestion du système – Communications et réseaux
Architecture SNMPv3
L’architecture SNMPv3 comporte quatre parties comme le montre le graphique suivant.
Cette section décrit la façon dont ces systèmes interagissent l’un avec l’autre pour fournir
les données requises.
Figure 28. Les parties principales de l’architecture SNMPv3 Cette illustration représente
un exemple de l’architecture SNMPv3. Le sous–agent DPI2, le pair smux, le gestionnaire
SNMP et l’agent SNMP sont représentés. La communication entre eux est également
représentée.
Agent SNMP
L’agent SNMP reçoit des requêtes du gestionnaire SNMP et lui répond. En outre, l’agent
SNMP communique avec tous les agents DPI2 et les homologues smux sur le système.
L’agent SNMP gère certaines variables MIB et tous les sous–agents DPI2 et homologues
smux enregistrent leurs variables MIB avec l’agent SNMP.
Lorsque clsnmp (le gestionnaire SNMP) émet une requête, elle est envoyée à UDP 161
sur l’agent SNMP. Si la requête est une requête SNMPv1 ou SNMPv2c, l’agent SNMP
vérifie le nom de communauté et traite la requête. Si la requête est une requête SNMPv3,
l’agent SNMP tente d’authentifier l’utilisateur demandant les données et vérifie qu’il possède
les droits d’accès requis pour exécuter la requête en utilisant les clés d’authentification, et,
si la version chiffrés s’exécute, les clés de confidentialité. Si l’agent SNMP ne peut pas
authentifier l’utilisateur, ou si l’utilisateur n’a pas les droits d’accès adéquats pour exécuter
la requête, l’agent SNMP n’honore pas la requête. Pour savoir comment créer des
utilisateurs dans SNMPv3, reportez–vous à Création d’utilisateurs dans SNMPv3,
page 1-14.
Si l’utilisateur est authentifié et possède les droits d’accès adéquats, l’agent SNMP exécute
la requête. L’agent SNMP recherche les variables MIB demandées. Si l’agent SNMP
lui–même gère les variables MIB demandées, il traite la requête et envoie une réponse au
gestionnaire SNMP. Si un sous–agent DPI2 ou un homologue smux gère les variables MIB
demandées, l’agent SNMP retransmet la requête au sous–agent DPI2 ou à l’homologue
smux sur lequel les variables MB sont gérées, lui permet de traiter la requête et répond
alors au gestionnaire SNMP.
Sous–agents DPI2
Un sous–agent tel que hostmibd communique avec l’agent DPI2 qui, dans SNMPv3, fait
partie de l’agent SNMP. Le sous–agent DPI2 envoie des réponses et des interruptions à
l’agent DPI2 via dpiPortForTCP.0. Comme il ne s’agit pas d’un port identifié, le sous–agent
DPI2 doit d’abord lancer une requête pour connaître le numéro de port de dpiPortForTCP.0.
La requête est envoyée à UDP 161 sur l’agent SNMP, qui répond au sous–agent DPI2 en
indiquant le numéro de port de dpiPortForTCP.0. Une fois le numéro de port reçu, le
sous–agent DPI2 établit une connexion à l’agent DPI2 en utilisant le numéro de port
Administration du réseau
5-5
indiqué. Le sous–agent DPI2 enregistre alors ses sous–arborescences MIB avec l’agent
DPI2.
Remarque :
Pour permettre à l’agent SNMP d’écouter un port différent de UDP 161,
vous devez définir l’environnement SNMP_PORT. Vous disposez de deux
méthodes pour définir cette variable :
. Méthode 1 : Interrompez le sous–agent DPI2 et entrez les commandes suivantes :
– SNMP_PORT=< port_number > /usr/sbin/aixmibd –d 128
– SNMP_PORT=< port_number > /usr/sbin/hostmibd –d 128
– SNMP_PORT=< port_number > /usr/sbin/snmpmibd –d 128,
port_number étant le nombre de ports que vous souhaitez utiliser.
Après l’exécution complète des commandes, lancez le sous–agent DPI2.
. Méthode 2 : Insérez la variable SNMP_PORT dans le fichier /etc/environment et
affectez–lui une nouvelle valeur de port. Permettre aux démons aixmibd,
hostmibd, snmpmibd, et snmpd de s’exécuter à partir de /etc/rc.tcpip en tant
que tels. Dans cette méthode, il n’est pas nécessaire d’exécuter les commandes
aixmibd, hostmibd, et snmpmibd à partir de la ligne des commandes.
Une fois la connexion établie et les sous–arborescences MIB enregistrées, le sous–agent
DPI2 est prêt à répondre aux requêtes reçues de l’agent DPI2. Lorsqu’une requête est
reçue, le sous–agent DPI2 traite la requête et renvoie les informations requises.
Le sous–agent DPI2 est également prêt à envoyer des interruptions si nécessaire.
Lorsqu’une interruption est envoyée, l’agent SNMP vérifie son fichier /etc/snmpdv3.conf
pour déterminer la ou les adresses IP à laquelle l’interruption doit être envoyée, et leur
envoie l’interruption.
Homologues smux
Un homologue smux tel que gated, une fois démarré, établit la connexion à TCP 199
et initialise l’association smux. Suite à l’initialisation, l’homologue smux enregistre les
sous–arborescences MIB qu’il va gérer.
Après l’enregistrement, l’homologue smux est prêt à accepter toute requête entrante du
serveur smux et à renvoyer des réponses. Lorsque l’homologue smux reçoit une requête,
il la traite et renvoie une réponse au serveur smux.
L’homologue smux peut aussi envoyer une interruption au serveur smux. Lorsqu’une
interruption est envoyée, l’agent SNMP vérifie son fichier /etc/snmpdv3.conf pour
déterminer la ou les adresses IP à laquelle l’interruption doit être envoyée, et leur envoie
l’interruption.
Gestionnaire SNMP
Le gestionnaire SNMP exécute clsnmp, qui est compatible avec SNMPv1, SNMPv2c,
et SNMPv3. Utilisez la commande clsnmp pour envoyer une requête, par exemple get,
get–next, get–bulk, ou set. La requête est envoyée à UDP 161 sur l’agent SNMP,
puis attend la réponse de l’agent SNMP.
Remarque :
Pour permettre au gestionnaire SNMP d’utiliser un port différent de UDP
161, vous devez indiquer le numéro de port, que vous souhaitez utiliser,
et l’adresse IP dans la zone targetAgent du fichier /etc/clsnmp.conf.
Pour obtenir des informations sur le fichier /etc/clsnmp.conf,
reportez–vous au fichier fclsnmp.conf File dans AIX 5L Version 5.3 Files
Reference.
Variables MIB
Pour plus d’informations sur les variables MIB, reportez–vous à Management Information
Base, Terminology Related to Management Information Base Variables, Working with
Management Information Base Variables, et Management Information Base Database dans
le manuel AIX 5L Version 5.3 Communications Programming Concepts.
5-6
Guide de gestion du système – Communications et réseaux
Clés utilisateur SNMPv3
Clés d’authentification
L’authentification est en général requise pour permettre le traitement des requêtes SNMPv3
(sauf si le niveau de sécurité demandé est noAuth). Lors de l’authentification d’une
requête, l’agent SNMP vérifie que la clé d’authentification envoyée dans une requête
SNMPv3 peut être utilisée pour créer un résumé de message correspondant à celui créé
par la clé d’authentification définie par l’utilisateur.
Lorsque le gestionnaire SNMP envoie une requête, la commande clsnmp utilise la clé
d’authentification trouvée dans une entrée dans le fichier /etc/clsnmp.conf du gestionnaire
SNMP. Il doit établir une corrélation avec la clé d’authentification indiquée dans une entrée
USM_USER de cet utilisateur dans le fichier /etc/snmpdv3.conf de l’agent SNMP. Les clés
d’authentification sont générées à l’aide de la commande pwtokey.
La clé d’authentification est générée à partir de deux éléments :
• Le mot de passe indiqué
• L’identification de l’agent SNMP sur lequel la clé sera utilisée. Si l’agent est un agent
Bull, et que son engineID (ID moteur) a été généré avec une formule engineID
spécifique au fournisseur, l’agent peut être identifié par une adresse IP ou un nom
d’hôte. Sinon, l’engineID doit être fourni en tant qu’identification de l’agent.
Une clé incorporant l’identification de l’agent sur lequel il sera utilisé est appelée une clé
localisée. Elle peut uniquement être utilisée sur cet agent. Une clé n’incorporant pas
l’engineID de l’agent sur lequel il sera utilisé est appelée une clé non localisée.
Les clés stockées dans le fichier de configuration de la commande clsnmp,
/etc/clsnmp.conf, sont normalement des clés non localisées. Les clés stockées dans le
fichier configuration de l’agent SNMP, /etc/snmpdv3.conf, peuvent être localisées ou non
localisées, mais il est considéré comme plus sûr d’utiliser des clés localisées.
Au lieu de stocker les clés d’authentification dans le fichier de configuration client, la
commande clsnmp permet de stocker les mots de passe utilisateur. Sil a commande
clsnmp est configurée avec un mot de passe, le code génère une clé d’authentification
(et une clé de confidentialité si nécessaire, et si la version chiffrée est installée) pour
l’utilisateur. Ces clés doivent produire les mêmes valeurs d’authentification que les clés
configurées pour USM_USER dans le fichier /etc/snmpdv3.conf de l’agent ou être configuré
dynamiquement avec les commandes SNMP SET. Toutefois, l’utilisation de mots de passe
dans le fichier de configuration client est considérée comme moins sûre que celles de clés
dans le fichier de configuration.
Clés de confidentialité
Le chiffrement est proposé en tant que produit distinct dans AIX Expansion Pack lorsque la
législation sur l’exportation l’autorise. Les clés utilisées pour le chiffrement sont générées
avec les mêmes algorithmes que ceux utilisés pour l’authentification. Toutefois, les
longueurs de clés diffèrent. Par exemple, une clé d’authentification HMAC–SHA a une
longueur de 20 octets, mais une clé de chiffrement localisée utilisée avec HMAC–SHA n’a
que 16 octets.
La version chiffrée est activée automatiquement après l’installation. Pour revenir à la
version non chiffrée, lancez la commande snmpv3_ssw.
Administration du réseau
5-7
Génération de clés
AIX utilise la commande pwtokey pour générer des clés d’authentification et, le cas
échéant, des clés de confidentialité. La commande pwtokey permet de convertir les
mots de passe en clés d’authentification et de confidentialité localisées et non localisées.
La procédure pwtokey choisit un mot de passe et un ID pour l’agent et génère des clés
d’authentification et de confidentialité. Comme la procédure utilisée par la commande
pwtokey est le même algorithme utilisé par la commande clsnmp, la personne configurant
l’agent SNMP peut générer des clés appropriées d’authentification (et de confidentialité) à
placer dans le fichier /etc/clsnmp.conf sur le gestionnaire SNMP pour un utilisateur,
avec un mot de passe et l’adresse IP sur laquelle la cible va s’exécuter.
Lorsque vous avez généré les clés d’authentification (et de confidentialité si vous exécutez
la version chiffrée), vous devez entrer ces clés dans le fichier /etc/snmpdv3.conf sur
l’agent SNMP et dans le fichier /etc/clsnmp.conf sur le gestionnaire SNMP.
Dans SNMPv3, il existe neuf configurations d’utilisateur possibles. Chaque configuration
possible, ainsi qu’un exemple, est indiquée ci–après. Ces clés particulières ont été
générées avec le mot de passe defaultpassword et l’adresse IP 9.3.149.49.
La commande suivante a été utilisée :
pwtokey –u all –p all defaultpassword 9.3.149.49
Les clés d’authentification et de confidentialité suivantes ont été générées :
Affichage de la clé d’authentification 16 octets HMAC–MD5 authKey :
18a2c7b78f3df552367383eef9db2e9f
Affichage de la clé d’authentification 16 octets HMAC–MD5 localized
authKey :
a59fa9783c04bcbe00359fb1e181a4b4
Affichage de la clé de confidentialité 16 octets HMAC–MD5 privKey :
18a2c7b78f3df552367383eef9db2e9f
Affichage de la clé de confidentialité localisée 16 octets HMAC–MD5
privKey :
a59fa9783c04bcbe00359fb1e181a4b4
Affichage de la clé d’authentification 20 octets HMAC–SHA authKey :
754ebf6ab740556be9f0930b2a2256ca40e76ef9
Affichage de la clé d’authentification localisée 20 octets HMAC–SHA
localized authKey :
cd988a098b4b627a0e8adc24b8f8cd02550463e3
Affichage de la clé de confidentialité 20 octets HMAC–SHA privKey :
754ebf6ab740556be9f0930b2a2256ca40e76ef9
Affichage de la clé de confidentialité localisée 16 octets HMAC–SHA :
cd988a098b4b627a0e8adc24b8f8cd02
Ces entrées apparaîtront dans le fichier /etc/snmpdv3.conf. Les neuf configurations
possibles sont les suivantes :
• Clés d’authentification et de confidentialité localisées utilisant le protocole HMAC–MD5 :
USM_USER user1 – HMAC–MD5 a59fa9783c04bcbe00359fb1e181a4b4 DES
a59fa9783c04bcbe00359fb1e181a4b4 L – –
• Clés d’authentification et de confidentialité non localisées utilisant le protocole
HMAC–MD5 :
USM_USER user2 – HMAC–MD5 18a2c7b78f3df552367383eef9db2e9f DES
18a2c7b78f3df552367383eef9db2e9f N – –
5-8
Guide de gestion du système – Communications et réseaux
• Clé d’authentification localisée utilisant le protocole HMAC–MD5 :
USM_USER user3 – HMAC–MD5 a59fa9783c04bcbe00359fb1e181a4b4 – – L –
• Clé d’authentification non localisée utilisant le protocole HMAC–MD5 :
USM_USER user4 – HMAC–MD5 18a2c7b78f3df552367383eef9db2e9f – – N –
• Clés d’authentification et de confidentialité localisées utilisant le protocole HMAC–SHA :
USM_USER user5 – HMAC–SHA cd988a098b4b627a0e8adc24b8f8cd02550463e3 DES
cd988a098b4b627a0e8adc24b8f8cd02 L –
• Clés d’authentification et de confidentialité non localisées utilisant le protocole
HMAC–SHA :
USM_USER user6 – HMAC–SHA 754ebf6ab740556be9f0930b2a2256ca40e76ef9 DES
754ebf6ab740556be9f0930b2a2256ca40e76ef9 N –
• Clé d’authentification localisée utilisant le protocole HMAC–SHA :
USM_USER user7 – HMAC–SHA cd988a098b4b627a0e8adc24b8f8cd02550463e3 – – L
–
• Clé d’authentification non localisée utilisant le protocole HMAC–SHA :
USM_USER user8 – HMAC–SHA 754ebf6ab740556be9f0930b2a2256ca40e76ef9 – – N
–
• Aucune clé d’authentification ou de confidentialité utilisée (SNMPv1)
USM_USER user9 – none – none – – –
La configuration des utilisateurs dans SNMPv3 nécessite la configuration des deux fichiers
/etc/snmpdv3.conf et /etc/clsnmp.conf. Pour consulter un scénario sur la génération des
clés utilisateur et l’édition des fichiers de configuration requis, reportez–vous à la section
Création d’utilisateurs dans SNMPv3, page 1-14. En outre, reportez–vous aux descriptions
des commandes pwtokey et clsnmp dans le manuel AIX 5L Version 5.3 Commands
Reference, et aux formats de fichier des fichiers /etc/clsnmp.conf et /etc/snmpdv3.conf
dans le manuel AIX 5L Version 5.3 Files Reference. Vous pouvez aussi vous reporter aux
exemples de fichiers de configuration snmpdv3.conf et clsnmp.conf situés dans le
répertoire /usr/samples/snmpdv3.
Mise à jour des clés
SNMPv3 offre la possibilité de mettre à jour dynamiquement des clés utilisateur en fonction
des nouveaux mots de passe. Pour ce faire, vous devez lancer la commande pwchange
pour générer de nouvelles clés utilisateur basées sur un mot de passe mis à jour, puis
lancer la commande clsnmp pour mettre à jour dynamiquement la clé utilisateur dans le
fichier /etc/snmpdv3.conf et éditer le fichier /etc/clsnmp.conf en indiquant les nouvelles
clés. Pendant ce processus, le nouveau mot de passe n’est jamais communiqué entre les
machines.
Pour obtenir des instructions pas à pas sur la mise à jour des clés utilisateur, reportez–vous
à Mise à jour dynamique des clés d’authentification et de confidentialité dans SNMPv3
page 1-19. En outre, reportez–vous aux descriptions des commandes pwchange et
clsnmp dans AIX 5L Version 5.3 Commands Reference et aux formats de fichiers
/etc/clsnmp.conf et /etc/snmpdv3.conf dans AIX 5L Version 5.3 Files Reference
Administration du réseau
5-9
Emission de requêtes SNMPv3
La commande clsnmp permet d’envoyer des requêtes SNMP aux agents SNMP sur les
hôtes locaux ou distants. Il peut s’agir de requêtes SNMPv1, SNMPv2c ou SNMPv3.
Pour que les requêtes puissent être traitées, le fichier /etc/clsnmp.conf doit être configuré.
La commande clsnmp peut lancer des requêtes get, getnext, getbulk, set, walk, et
findname. Chacune de ces requêtes est décrite brièvement ci–dessous :
get
permet à l’utilisateur de collecter les données d’une variable MIB
getnext
indique la variable MIB suivante dans la sous–arborescence MIB
getbulk
indique toutes les variables MIB de plusieurs sous–arborescences MIB
set
permet à l’utilisateur de définir une variable MIB
walk
indique toutes les variables MIB d’une seule sous–arborescence
findname
établit une équivalence entre l’OID et le nom de la variable
trap
permet à clsnmp d’écouter les interruptions sur le port 162
Pour plus de détails sur l’émission de requêtes clsnmp, reportez–vous à la description
de commande clsnmp dans AIX 5L Version 5.3 Commands Reference.
5-10
Guide de gestion du système – Communications et réseaux
Identification des incidents SNMPv3
Les problèmes suivants peuvent se présenter.
• Après une mise à niveau pour passer d’une ancienne version d’AIX à AIX 5.2,
SNMP ne fonctionne plus de la même façon qu’avant la migration.
Vous devez faire migrer les entrées de communauté et smux définies dans le fichier
/etc/snmpd.conf vers le fichier /etc/snmpdv3.conf. Pour plus d’informations sur la
migration de ces informations, reportez–vous à Migration de SNMPv1 vers SNMPv3,
page 1-10.
• Mes requêtes ne reçoivent aucune réponse.
La cause la plus probable de ce problème est une erreur de configuration dans les
fichiers /etc/snmpdv3.conf ou /etc/clsnmp.conf ou les deux. Examinez soigneusement
ces fichiers pour vérifier que toutes les informations sont entrées correctement.
Pour plus d’informations sur l’édition de ces fichiers lors de la création de nouveaux
utilisateurs, reportez–vous à Création d’utilisateurs dans SNMPv3, page 1-14.
• J’ai configuré un nouvel utilisateur à l’aide de clés d’authentification et de confidentialité,
mais j’obtiens un message d’erreur lorsque je l’utilise.
La cause la plus probable est que vous n’exécutez pas la version chiffrée de SNMPv3.
Procédez comme suit pour déterminer la version que vous exécutez :
1. Exécutez ps –e|grep snmpd.
. Si vous n’avez pas reçu de résultat, démarrez le démon snmpd.
Exécutez startsrc –s snmpd.
. Si votre résultat comprend snmpdv1, vous exécutez SNMPv1. Vous pourrez
lancer des requêtes SNMPv1 lors de l’exécution de cette version.
. Si votre résultat comprend snmpdv3ne, vous exécutez la version non chiffrée de
SNMPv3. Une fois installé AIX 5.2, cette version fonctionnera correctement. Elle
ne vous permet pas d’utiliser les clés de confidentialité.
. Si votre résultat inclut snmpdv3e, vous exécutez la version chiffrée de SNMPv3,
qui est un produit installable séparément. La version chiffrée de SNMPv3 est
disponible dans AIX Expansion Pack si cela est autorisé. La version chiffrée de
SNMPv3 permet d’utiliser des clés de confidentialité.
2. Déterminez si la version que vous exécutez est la version voulue. Si ce n’est
pas le cas, la commande snmpv3_ssw pour modifier la version comme suit :
. snmpv3_ssw –1 bascule vers SNMPv1
. snmpv3_ssw –n bascule vers la version non chiffrée de SNMPv3
. snmpv3_ssw –e bascule vers la version chiffrée de SNMPv3 si elle est installée
• J’ai modifié le fichier /etc/snmpdv3.conf et régénéré le démon, mais mes modifications
ne sont pas appliquées.
Après avoir modifié le fichier /etc/snmpdv3.conf, arrêtez et démarrez le démon SNMP.
La régénération du démon ne donne pas de résultat. Utilisez la procédure suivante :
1. Arrêtez le démon SNMP en exécutant stopsrc –s snmpd.
2. Démarrez le démon SNMP en exécutant startsrc –s snmpd.
• Le sous–agent DPI2 est démarré mais je ne peux pas interroger les variables MIB à
partir de celui–ci.
Administration du réseau
5-11
La cause la plus probable est que la communauté public n’est pas configuré dans le
fichier /etc/snmpdv3.conf. Par défaut, le sous–agent DPI2 livré avec AIX utilise le nom
de communauté public pour se connecter à l’agent SNMP. La communauté public
est configurée dans le fichier /etc/snmpdv3.conf par défaut. Si vous avez supprimé la
communauté public du fichier /etc/snmpd.conf, ajoutez les lignes suivantes au
fichier :
VACM_GROUP group1 SNMPv1 public –
VACM_VIEW defaultView 1.3.6.1.4.1.2.2.1.1.1.0 – included –
VACM_ACCESS group1 – – noAuthNoPriv SNMPv1 defaultView – defaultView –
COMMUNITY public
public
noAuthNoPriv 0.0.0.0
0.0.0.0
–
1.3.6.1.4.1.2.2.1.1.1.0 est l’OID de dpiPortForTCP.0.
• Je ne peux pas interroger des variables MB gérées par l’homologue smux alors que cela
était possible avant la migration.
Vérifiez que votre entrée smux est présente dans les fichiers /etc/snmpdv3.conf et
/etc/snmpd.peers. Si vous configurez de nouveaux homologues smux, vérifiez qu’ils
sont entrés aussi dans ces deux fichiers.
• J’ai implémenté mon propre groupe de variables MIB, mais je ne peux pas les inclure
ou les exclure des vues des utilisateurs.
Dans l’entrée VACM_VIEW du fichier /etc/snmpdv3.conf, vous devez spécifier l’OID
de la variable MIB à la place du nom de variable MIB.
• Je ne reçois pas d’interruptions.
Vérifiez que vous avez correctement configuré les entrées d’interruption dans le fichier
/etc/snmpdv3.conf. En outre, si l’interruption est une interruption SNMPv3, le fichier
/etc/clsnmp.conf doit aussi être configuré. Pour plus d’instructions sur la configuration
des interruptions, reportez–vous à Création d’utilisateurs dans SNMPv3, page 1-14.
En outre, vérifiez que la machine devant recevoir les interruptions (dans le fichier
/etc/snmpdv3.conf) est à leur écoute. Vous pouvez démarrer ce processus en
exécutant clsnmp trap sur la ligne de commande.
• Pourquoi le serveur DPI2 ne s’exécute–t–il pas dans l’environnement SNMPv3 ?
Dans l’architecture SNMPv3, l’agent SNMPv3 exécute lui–même le serveur DPI2.
Pour plus d’informations, reportez–vous à Architecture SNMPv3, page 5-5.
5-12
Guide de gestion du système – Communications et réseaux
SNMPv1
Les informations de cette section sont spécifiques à SNMPv1.
• Politiques d’accès SNMPv1, page 5-14
• Démon SNMP, page 5-15
• Configuration du démon SNMP, page 5-16
• Fonctionnement du démon SNMP, page 5-17
• Support du démon SNMP pour la famille EGP de variables MIB, page 5-22
• Identification des incidents du démon SNMP, page 5-35
Administration du réseau
5-13
Politiques d’accès SNMPv1
Lorsque SNMPv1 est utilisé, l’agent snmpd utilise un schéma d’authentification simple
pour connaître les stations du gestionnaire SNMP (Simple Network Management Protocol)
peuvent accéder à ses variables MIB (Management Information Base). Le schéma
d’authentification suppose de spécifier les politiques d’accès SNMP pour SNMPv1. Une
politique d’accès SNMP est un ensemble de relations administratives impliquant une
association au sein d’une communauté SNMP, un mode d’accès et une vue MIB.
On appelle communauté SNMP un groupe d’hôtes doté d’un nom. Un nom de communauté
est une chaîne d’octets qu’un gestionnaire SNMP doit imbriquer dans un paquet de
requêtes SNMP à des fins d’authentification.
Le mode d’accès spécifie l’accès accordé aux hôtes de la communauté, en ce qui concerne
la récupération et la modification des variables MIB à partir d’un agent SNMP spécifique.
Le mode d’accès peut être : none, read–only, read–write ou write–only.
Une vue MIB définit une ou plusieurs sous–arborescences MIB accessibles par une
communauté SNMP donnée. Il peut s’agir de toute l’arborescence MIB ou d’un
sous–ensemble de cette arborescence.
Lorsque l’agent SNMP reçoit une requête, il compare le nom de la communauté à l’adresse
IP de l’hôte demandeur pour savoir si ce dernier est un membre de la communauté SNMP.
Si oui, il détermine ensuite si l’hôte demandeur a le droit d’accès spécifié aux variables MIB
voulues, tel que défini dans la politique d’accès associée à cette communauté. Si tous les
critères sont vérifiés, l’agent SNMP tente de répondre à la demande. Sinon, il génère une
interruption d’échec d’authentification (authenticationFailure) ou envoie un message
d’erreur à l’hôte demandeur.
Les politiques d’accès de SNMPv1 pour l’agent snmpd sont configurables par l’utilisateur
et sont spécifiées dans le fichier /etc/snmpd.conf. Pour configurer les politiques d’accès
SNMP pour l’agent snmpd, reportez–vous au fichier /etc/snmpd.conf.
5-14
Guide de gestion du système – Communications et réseaux
Démon SNMP
Le démon SNMP (Simple Network Management Protocol) est un processus serveur
d’arrière-plan exécutable sur n’importe quel hôte station de travail TCP/IP (Transmission
Control Protocol/Internet Protocol). Ce démon, qui sert d’agent SNMP, reçoit, authentifie
et traite les requêtes SNMP issues des applications du gestionnaire. Pour en savoir plus,
reportez-vous aux sections “Simple Network Management Protocol,” “How a Manager
Functions” et “How an Agent Functions” AIX 5L Version 5.3 Communications
Programming Concepts.
Remarque :
Les termes démon SNMP, agent SNMP et agent sont synonymes.
Pour une configuration minimale, il faut que l’interface TCP/IP de boucle soit active
pour le démon snmpd. Avant de lancer TCP/IP, entrez la commande :
ifconfig lo0 loopback up
Administration du réseau
5-15
Configuration du démon SNMP
Le démon SNMP (Simple Network Management Protocol) tente de lier les sockets à certain
ports UDP (User Datagram Protocol) et TCP (Transmission Control Protocol) identifiés,
qui doivent être définis dans le fichier /etc/services, comme suit :
snmp
snmp–trap
smux
161/udp
162/udp
199/tcp
Le service snmp doit être affecté du port 161, conformément à RFC 1157. Le fichier
/etc/services assigne les ports 161, 162 et 199 à ces services. Si le fichier /etc/services
est mis à disposition à partir d’une autre machine, ces ports assignés doivent être rendus
disponibles dans le fichier /etc/services servi pour que le démon SNMP puisse s’exécuter.
Le démon SNMP lit le fichier de configuration sur la version SNMP en cours d’exécution au
lancement et lors de l’émission d’une commande refresh (si le démon snmpd est appelé
sous le contrôle SRC) ou d’un signal kill–1.
fichier /etc/snmpd.conf
Le fichier de configuration /etc/snmpd.conf spécifie les noms de communauté et les vues
et droits d’accès associés, les hôtes pour la notification d’interruption, les attributs
de connexion, les paramètres spécifiques de snmpd et les configurations SMUX
(single multiplexer) pour le démon SNMP. Pour en savoir plus, consultez le fichier
/etc/snmpd.conf.
5-16
Guide de gestion du système – Communications et réseaux
Fonctionnement du démon SNMP
Le démo, SNMP (Simple Network Management Protocol) traite les requêtes SNMP issues
des applications du gestionnaire. Pour en savoir plus, consultez les sections “Simple
Network Management Protocol (SNMP),” “How a Manager Functions” et “How an Agent
Functions” AIX Communications Programming Concepts.
Traitement d’un message et authentification
Toutes les requêtes, interruptions et réponses sont transmises sous la forme de messages
codés en ASN.1. Un message, tel que défini par RFC 1157, a la structure suivante :
Version Communauté PDU
Version étant la version de SNMP (actuellement la version 1), Communauté, le nom de la
communauté et PDU, l’unité des données de protocole contenant les données de requête,
de réponse ou d’interruption SNMP. Un PDU est également codé selon les règles ASN.1.
Figure 29. Les parties principales de l’architecture SNMPv1 Cette illustration représente
un exemple de l’architecture SNMPv1. Le sous–agent DPI2, le pair smux, le gestionnaire
SNMP et l’agent SNMP sont représentés. La communication entre eux est également
représentée.
Le démon SNMP reçoit et transmet tous les messages du protocole SNMP via UDP
(User Datagram Protocol) TCP/IP (Transmission Control Protocol/Internet Protocol).
Les requêtes sont acceptées sur le port identifié 161. Les interruptions sont transmises aux
hôtes répertoriés dans les entrées d’interruption du fichier /etc/snmpd.conf qui écoutent le
port identifié 162.
A réception d’une requête, l’adresse IP source et le nom de la communauté sont comparés
à la liste des adresses IP, des noms de communauté, des droits et des vues, spécifiés dans
le fichier /etc/snmpd.conf. L’agent snmpd lit ce fichier au lancement et à l’émission d’une
commande refresh ou d’un signal kill –1. En l’absence d’entrée correspondante, la requête
est ignorée. Dans le cas contraire, l’accès est accordé, en fonction des droits spécifiés pour
cette association (adresse IP, communauté et nom de vue) dans le fichier /etc/snmpd.conf.
Le message et le PDU doivent être codés conformément aux règles ASN.1.
Ce schéma d’authentification n’est pas censé garantir une sécurité totale. Si le démon
SNMP n’est utilisé que pour les requêtes “get” et ”get-next”, la sécurité n’est pas forcément
très importante. En revanche, si des requêtes ”set” sont autorisées, il est possible de
restreindre le privilège ”set”.
Pour en savoir plus, consultez le fichier /etc/snmpd.conf. Pour en savoir plus,
reportez-vous à ”Management Information Base (MIB)” AIX Communications
Programming Concepts.
Administration du réseau
5-17
Traitement d’une requête
Le démon SNMP peut recevoir trois types de requêtes PDU. Les types de requêtes,
définies dans RFC 1157, et les PDU ont tous le format suivant :
Format de PDU de requête
ID requête
état-erreur
index-erreur
liaisons-variable
GET
0
0
VarBindList
GET–NEXT
0
0
VarBindList
SET
0
0
VarBindList
Le champ ID-requête indique la nature de la requête ; les champs état-erreur et
index-erreur sont inutilisés et doivent être définis à 0 (zéro) ; le champ liaisons-variable
contient une liste de longueur variable des ID d’instance, au format numérique, dont les
valeurs sont demandées. Si la valeur du champ ID requête est SET, le champ
liaisons-variable est une liste de paires ID d’instance/valeur.
Pour en savoir plus, consultez la section ”Using the Management Information Base (MIB)
Database” AIX Communications Programming Concepts.
Traitement d’une réponse
Les PDU de réponse ont presque le même format que les PDU de requête :
Format de PDU de réponse
ID requête
état-erreur
index-erreur
liaisons-variable
GET–RESPONSE
ErrorStatus
ErrorIndex
VarBindList
Si la requête a abouti, la valeur des champs état-erreur et index-erreur est 0 (zéro),
et le champ liaisons-variable contient la liste complète des paires ID d’instance/valeur.
Si un ID d’instance du champ liaisons-variable du PDU de requête n’a pas abouti, l’agent
SNMP interrompt le traitement, entre l’index de l’ID d’instance défaillant dans le champ
index-erreur, enregistre un code d’erreur dans le champ état-erreur et copie la liste de
résultats partiellement complétée dans le champ liaisons-variable.
5-18
Guide de gestion du système – Communications et réseaux
RFC 1157 définit les valeurs suivantes pour le champ état-erreur :
Valeurs du champ état-erreur
Valeur
Valeur
Explication
noError
0
Traitement réussi (index d’erreur = 0).
tooBig
1
La taille du PDU de réponse dépasse une limite définie
par l’implémentation (index d’erreur = 0).
noSuchName
2
Un ID d’instance n’existe pas dans la vue MIB
appropriée pour les types de requête GET et SET ou
n’a pas de successeur dans l’arborescence MIB dans
la vue MIB appropriée pour les requêtes GET-NEXT
(index d’erreur différent de zéro).
badValue
3
Pour les requêtes SET uniquement, une valeur
spécifiée est syntaxiquement incompatible avec
l’attribut de type de l’ID d’instance correspondant
(index d’erreur différent de zéro).
readOnly
4
Non défini.
genErr
5
Une erreur définie par l’implémentation s’est produite
(index d’erreur différent de zéro) ; par exemple, une
tentative d’assignation d’une valeur dépassant les
limites d’implémentation.
Administration du réseau
5-19
Traitement d’une interruption
Les PDU d’interruption sont définis par RFC 1157 de façon à avoir le format suivant :
Format de PDU d’interruption
entreprise
ID Objet
agent
générique
spécifique
adresse
interruption
interruption
Entier
Entier
Entier
horodate
variable
liaisons
Tics
d’horloge
VarBindList
Les champs sont utilisés comme suit :
entreprise
Identificateur d’objet assigné au fournisseur implémentant
l’agent. Valeur de la variable sysObjectID, unique pour
chaque metteur en oeuvre d’un agent SNMP. La valeur
assignée à cette implémentation de l’agent est
1.3.6.1.4.1.2.3.1.2.1.1.3 ou risc6000snmpd.3.
adresse-agent
Adresse IP de l’objet générateur de l’interruption.
interruption générique
Entier, comme suit :
0
coldStart
1
warmStart
2
linkDown
3
linkUp
4
authenticationFailure
5
egpNeighborLoss
6
enterpriseSpecific
5-20
interruption spécifique
Inutilisé, réservé à un usage ultérieur.
horodate
Temps écoulé, en centièmes de seconde, depuis la
dernière réinitialisation de l’agent jusqu’à l’événement
générant l’interruption.
liaisons-variable
Informations supplémentaires, fonction du type
d’interruption-générique.
Guide de gestion du système – Communications et réseaux
Les valeurs d’interruption générique suivantes indiquent que certains événements système
ont été détectés :
coldStart
L’agent est en cours de réinitialisation. Les données de
configuration et/ou la valeur des variables MIB peuvent
avoir changé. Les epochs de mesure doivent être relancés.
warmStart
L’agent est en cours de réinitialisation, mais les données de
configuration ou la valeur des variables MIB n’ont pas
changé. Dans cette mise en oeuvre de l’agent SNMP, une
interruption warmStart est générée à la relecture du fichier
/etc/snmpd.conf. Les informations de configuration dans le
fichier /etc/snmpd.conf concernent la configuration de
l’agent sans effets sur les bases de données du
gestionnaire SNMP. Les epochs de mesure ne doivent pas
être relancés.
linkDown
L’agent a détecté qu’une interface de communication
identifiée a été désactivée.
linkUp
L’agent a détecté qu’une interface de communication
identifiée a été activée.
authenticationFailure
Un message reçu n’a pu être authentifié.
egpNeighborLoss
Un neighbor EGP (Exterior Gateway Protocol) est perdu.
Cette valeur n’est générée que lorsque l’agent s’exécute
sur un hôte exécutant le démon gated, avec le protocole
EGP (Exterior Gateway Protocol).
enterpriseSpecific
Non implémenté, réservé à un usage ultérieur.
Les interruptions linkDown et linkUp contiennent une paire ID d’instance/valeur unique dans
la liste des liaisons de variable. L’ID d’instance identifie l’ifIndex de la carte désactivée ou
activée, et la valeur est celle de ifIndex. L’interruption pour egpNeighborLoss contient
également une liaison consistant en l’ID d’instance et la valeur de egpNeighAddr pour le
voisin perdu.
Administration du réseau
5-21
Support du démon SNMP pour la famille EGP de variables MIB
Si l’hôte de l’agent exécute le démon gated alors que le protocole EGP (Exterior Gateway
Protocol) est activé, plusieurs variables MIB (Management Information Base) du groupe
EGP sont acceptées par le démon gated et accessibles par l’agent snmpd.
Les variables MIB EGP suivantes ont une instance unique :
egpInMsgs
Nombre de messages EGP reçus sans erreur.
egpInErrors
Nombre de messages EGP reçus avec erreur.
egpOutMsgs
Nombre total de messages EGP transmis par le démon gated actif
sur l’hôte de l’agent.
egpOutErrors Nombre de messages EGP qui n’ont pas pu être envoyés au démon
gated de l’hôte de l’agent, par suite de limitations des ressources.
egpAs
Numéro système autonome du démon gated de l’hôte de l’agent.
Les variables MIB EGP suivantes ont une instance pour chaque homologue ou voisin EGP
acquis par le démon gated de l’hôte de l’agent :
egpNeighState
État de cet homologue EGP :
1
idle
2
acquisition
3
down
4
up
5
cease
egpNeighAddr
Adresse IP de cet homologue EGP.
egpNeighAs
Numéro système autonome de cet homologue EGP.
Zéro (0) indique que ce numéro n’est pas encore connu.
egpInNeighMsgs
Nombre de messages EGP reçus sans erreur de cet
homologue EGP.
egpNeighInErrs
Nombre de messages EGP reçus avec erreur de cet
homologue EGP.
egpNeighOutMsgs
Nombre de messages EGP générés localement pour cet
homologue EGP.
egpNeighOutErrs
Nombre de messages EGP générés en local, non envoyés à
cet homologue EGP par suite de limitations des ressources.
egpNeighInErrMsgs
Nombre de messages d’erreur définis par EGP reçus de cet
homologue EGP.
egpNeighOutErrMsgs
Nombre de messages d’erreur définis par EGP envoyés à cet
homologue EGP.
egpNeighStateUp
Nombre de transitions de l’état EGP jusqu’à l’état UP avec cet
homologue EGP.
egpNeighStateDowns
Nombre de transitions de l’état EGP à partir de l’état UP jusqu’à
n’importe quel état avec cet homologue EGP.
egpNeighIntervalHello Intervalle entre les retransmissions de la commande Hello
d’EGP, en centièmes de seconde.
5-22
Guide de gestion du système – Communications et réseaux
egpNeighIntervalPoll
Intervalle entre les retransmissions de la commande
d’interrogation d’EGP, en centièmes de seconde.
egpNeighMode
Mode d’interrogation de cet homologue EGP. Il peut être actif
(1) ou passif (2).
egpNeighEventTrigger Une variable de contrôle déclenche des événements de
lancement et d’arrêt initiés par l’opérateur sur cet homologue
EGP. Cette variable MIB peut alors être définie pour le
lancement (1) ou l’arrêt (2).
Si le démon gated n’est pas actif, que le démon gated n’est pas configuré pour
communiquer avec l’agent snmpd ou que le démon gated n’est pas configuré pour EGP,
les requêtes get et set pour les valeurs de ces variables renvoient le code d’erreur
noSuchName.
Le fichier de configuration du démon gated, /etc/gated.conf, doit contenir l’instruction :
snmp
yes;
Le démon gated est configuré en interne pour être un homologue du protocole SMUX
(SNMP multiplexing), ou un agent mandataire (proxy) du démon snmpd. A son lancement,
le démon gated enregistre l’arborescence de la variable MIB ipRouteTable avec l’agent
snmpd. Si le démon gated est configuré pour EGP, le démon gated enregistre également
l’arborescence de la variable MIB EGP. Une fois l’enregistrement terminé, un gestionnaire
SNMP peut envoyer des requêtes à l’agent snmpd concernant les variables MIB
ipRouteTable d’un EGP, prises en charge par le démon gated de l’hôte de cet agent. Ainsi,
lorsque le démon gated s’exécute, toutes les informations de routage MIB sont obtenues
via le démon gated. Dans ce cas, les requêtes set pour ipRouteTable ne sont pas
autorisées.
La communication SMUX entre les démons gated et snmpd s’effectue via le port TCP
(Transmission Control Protocol) identifié 199. Si le démon gated doit s’arrêter, snmpd
désenregistre immédiatement les arborescences précédemment enregistrées par gated.
Si gated démarre avant snmpd, gated contrôle régulièrement le démon snmpd jusqu’à
établissement de l’association SMUX.
Pour configurer l’agent snmpd pour qu’il reconnaisse et autorise l’association SMUX avec
le client du démon gated, il faut ajouter une entrée SMUX dans le fichier /etc/snmpd.conf.
L’identificateur et le mot de passe de l’objet client spécifiés dans cette entrée SMUX pour le
démon gated doivent correspondre à ceux du fichier /etc/snmpd.peers.
L’agent snmpd prend en charge les requêtes set pour les variables en lecture-écriture MIB I
et MIB II suivantes :
sysContact
Identification textuelle de la personne à contacter pour l’hôte de cet agent.
Cette information contient le nom de la personne et comment la contacter :
par exemple, “Bob Smith, 555–5555, ext 5.” La valeur est limitée à
256 caractères. Si, pour une requête set, cette chaîne dépasse
256 caractères, l’agent snmpd renvoie l’erreur badValue, et l’opération
set n’est pas exécutée. La valeur initiale de sysContact est définie dans
/etc.snmp.conf. Valeur par défaut : chaîne nulle.
Instance
Valeur
Action
0
“chaîne”
La variable MIB est définie comme “chaîne”.
atN0etAddress Adresse IP correspondant à l’adresse matérielle ou physique spécifiée
dans atPhysAddress. Il s’agit de la même variable MIB que
ipNetToMediaNetAddress.
Administration du réseau
5-23
Instance
Valeur
Action
f.1.n.n.n.n
m.m.m.m
Pour l’interface avec ifIndex f, une entrée de
table ARP existante pour l’adresse IP
n.n.n.n est remplacée par l’adresse IP
m.m.m.m.
ipForwarding Indique si l’hôte de l’agent achemine les datagrammes.
Instance
Valeur
Action
0
1
Si l’hôte de l’agent possède plusieurs
interfaces actives, le noyau TCP/IP est
configuré pour l’acheminement des
paquets. S’il ne possède qu’une seule
interface active, la requête set échoue.
2
Le noyau TCP/IP sur l’hôte de l’agent est
configuré de sorte qu’il n’achemine pas les
paquets.
ipDefaultTTL
Durée de vie (TTL) par défaut, insérée dans l’en-tête IP des datagrammes
générés par l’hôte de l’agent.
Instance
Valeur
Action
0
n
La valeur de durée de vie par défaut,
utilisée par le support de protocole IP, est
définie comme l’entier n.
ipRouteDest
Adresse IP de destination d’une route dans la table des routes.
Instance
Valeur
Action
n.n.n.n
m.m.m.m
La route de destination pour la route n.n.n.n
est définie à l’adresse IP m.m.m.m.
ipRouteNextHop
Passerelle par laquelle une adresse IP de destination peut être atteinte par
l’hôte de l’agent (entrée de la table des routes).
Instance
Valeur
Action
n.n.n.n
m.m.m.m
Une entrée de la table des routes pour
atteindre le réseau n.n.n.n via la passerelle
m.m.m.m est ajoutée à la table des routes.
La portion hôte de l’adresse IP n.n.n.n doit
être égale à 0 pour indiquer une adresse de
réseau.
sysName
Instance
Valeur
Action
0
“chaîne”
La variable MIB est définie comme “chaîne”.
sysLocation
5-24
Nom de l’hôte de cet agent. Il s’agit généralement du nom qualifié complet
du domaine. La valeur est limitée à 256 caractères. Si, pour une requête
set, cette chaîne dépasse 256 caractères, l’agent snmpd renvoie l’erreur
badValue, et l’opération set n’est pas exécutée.
Chaîne textuelle indiquant l’emplacement physique de la machine sur
laquelle se trouve l’agent snmpd : par exemple, “Site Austin, building 802,
lab 3C–23.” La valeur est limitée à 256 caractères. Si, pour une requête
set, cette chaîne dépasse 256 caractères, l’agent snmpd renvoie l’erreur
Guide de gestion du système – Communications et réseaux
badValue, et l’opération set n’est pas exécutée. La valeur initiale de
sysLocation est définie dans /etc/snmp.conf. Valeur par défaut : chaîne
nulle.
Instance
Valeur
Action
0
“chaîne”
La variable MIB est définie comme “chaîne”.
ifAdminStatus État souhaité d’une carte d’interface sur l’hôte de l’agent. Les états
possibles sont actif/inactif. Un état “test” peut également être défini, mais
cette valeur est sans effet sur l’état effectif de l’interface.
Instance
Valeur
Action
f
1
La carte d’interface avec ifIndex f est
activée.
Remarque :
Il est possible que, même si l’état ifAdminStatus est défini comme actif ou
inactif, le changement effectif d’état n’ait pas eu lieu. Dans ce cas, une
requête get de ifAdminStatus peut indiquer un état up (actif), et un
ifOperStatus un état down (inactif) pour cette interface. Il faut alors que
l’administrateur de réseau réémette une requête set de passage de
ifAdminStatus à l’état actif pour retenter l’opération.
atPhysAddress
Partie matérielle de l’adresse d’une liaison de table d’adresses sur l’hôte de
l’agent (entrée de la table ARP (Address Resolution Protocol)). Même
variable MIB que ipNetToMediaPhysAddress.
Instance
Valeur
Action
f.1.n.n.n.n
hh:hh:hh:hh:hh:hh
Pour l’interface avec ifIndex f, toute liaison
de table ARP existante pour l’adresse IP
n.n.n.n est remplacée par la liaison (n.n.n.n,
hh:hh:hh:hh:hh:hh). S’il n’y en a pas, la
nouvelle liaison est ajoutée.
hh:hh:hh:hh:hh:hh est une adresse
matérielle hexadécimale à douze chiffres.
ipRouteType
Etat d’une entrée de la table des routes sur l’hôte de l’agent
(utilisé pour supprimer des entrées).
Instance
Valeur
Action
h.h.h.h
1
Toute route à destination de l’adresse IP de
l’hôte h.h.h.h est supprimée.
n.n.n.n
2
Toute route à destination de l’adresse IP de
l’hôte n.n.n.n est supprimée.
ipNetToMediaPhysAddress
Partie matérielle de l’adresse d’une liaison de table d’adresses sur l’hôte de
l’agent (entrée de la table ARP). Même variable MIB que atPhysAddress.
Instance
Valeur
Action
f.1.n.n.n.n
hh:hh:hh:hh:hh:hh
Pour l’interface avec ifIndex f, toute liaison
de table ARP existante pour l’adresse IP
n.n.n.n est remplacée par la liaison (n.n.n.n,
hh:hh:hh:hh:hh:hh). S’il n’y en a pas, la
nouvelle liaison est ajoutée.
hh:hh:hh:hh:hh:hh est une adresse
matérielle hexadécimale à douze chiffres.
Administration du réseau
5-25
ipNetToMediaNetAddress
Adresse IP correspondant à l’adresse matérielle ou physique spécifiée
dans ipNetToMediaPhysAddress. Même variable MIB que atNetAddress.
Instance
Valeur
Action
f.1.n.n.n.n
m.m.m.m
Pour l’interface avec ifIndex f, une entrée
de table ARP existante pour l’adresse IP
n.n.n.n est remplacée par l’adresse IP
m.m.m.m.
ipNetToMediaType
Type de mappage de l’adresse IP vers l’adresse physique.
Instance
Valeur
Action
f.1.n.n.n.n
1
Pour l’interface avec ifIndex f, pour une
liaison ARP existante de l’adresse IP vers
l’adresse physique, le type de mappage a la
valeur 1, ou autre.
2
Pour l’interface avec ifIndex f, pour une
liaison ARP existante de l’adresse IP vers
l’adresse physique, le type de mappage a la
valeur 2, ou n’est pas valide. Un effet
secondaire est que l’entrée correspondante
de ipNetMediaTable est invalidée,
c’est-à-dire que l’interface est dissociée de
cette entrée ipNetToMediaTable.
3
Pour l’interface avec ifIndex f, pour une
liaison ARP existante de l’adresse IP vers
l’adresse physique, le type de mappage a la
valeur 3, ou dynamique.
4
Pour l’interface avec ifIndex f, pour une
liaison ARP existante de l’adresse IP vers
l’adresse physique, le type de mappage a la
valeur 4, ou statique.
snmpEnableAuthenTraps
Indique si l’agent snmpd est configuré de façon à générer des interruptions
authenticationFailure.
Instance
Valeur
Action
0
1
L’agent snmpd générera des interruptions
“authentication failure”.
2
L’agent snmpd ne générera pas
d’interruptions “authentication failure”.
smuxPstatus Etat d’un homologue de protocole SMUX
(utilisé pour supprimer des homologues SMUX).
Instance
Valeur
Action
n
1
L’agent snmpd ne fait rien.
2
L’agent snmpd arrête de communiquer
avec l’homologue SMUX n.
smuxTstatus
5-26
Etat d’une arborescence SMUX (utilisé pour supprimer des montages
d’arborescence MIB).
Guide de gestion du système – Communications et réseaux
Instance
Valeur
Action
l.m.m.m._ _ _ .p
1
L’agent snmpd ne fait rien.
2
Démonte le montage SMUX de
l’arborescence MIB m.m.m... avec / comme
longueur d’une instance d’arborescence
MIB et p la valeur de smuxTpriority.
Les variables ci–après sont définissables via le démon snmpd, conformément à RFC 1229.
L’unité sous–jacente peut ne pas autoriser leur définition. Vérifiez ce qui est admis dans
chaque cas.
ifExtnsPromiscuous
Etat du mode promiscuous sur une unité. Cette opération permet d’activer
ou de désactiver le mode promiscuous sur une unité donnée. L’action
snmpd est finalisée et terminée. Lorsque snmpd est instruit de s’arrêter, le
mode promiscuous est complètement désactivé, quelles que soient les
autres applications sur la machine.
Instance
Valeur
Action
n
1
Active le mode promiscuous pour l’unité n.
2
Désactive le mode promiscuous pour
l’unité n.
ifExtnsTestType
Variable d’initiation de test. Lorsqu’elle est définie, le test approprié est
lancé pour cette unité. La valeur de cette variable est un identificateur
d’objet. La valeur spécifique dépend du type d’unité et du test à exécuter.
Actuellement, FullDiplexLoopBack est le seul test défini que snmpd sait
exécuter.
Instance
Valeur
Action
n
oid
Lance le test spécifié par oid.
ifExtnsRcvAddrStatus
Variable d’état d’adresse. Lorsqu’elle est définie, l’adresse spécifiée est
créée avec un niveau de durée approprié. snmpd permet la définition d’une
adresse temporaire uniquement, car il est incapable de définir des
enregistrements ODM d’unité et qu’il n’est autorisé qu’à définir des
adresses multidestinataires/multidiffusion.
Instance
Valeur
Action
n.m.m.m.m.m.m
1
Ajoute l’adresse à titre ni temporaire ni
permanent.
2
Empêche l’utilisation de l’adresse.
3
Ajoute l’adresse à titre temporaire.
4
Ajoute l’adresse à titre permanent.
Les variables ci–après sont définissables via le démon snmpd, conformément à RFC 1231.
L’unité sous–jacente peut ne pas autoriser leur définition. Vérifiez ce qui est admis dans
chaque cas.
Administration du réseau
5-27
dot5Commands
Commande que l’unité token-ring doit exécuter.
Instance
Valeur
Action
n
1
Ne fait rien. Renvoyé.
2
Demande à l’unité token-ring de s’ouvrir.
3
Demande au token-ring de se réinitialiser.
4
Demande à l’unité token-ring de se fermer.
dot5RindSpeed
Vitesse ou largeur de bande de l’anneau actuel.
Instance
Valeur
Action
n
1
Vitesse inconnue.
2
Vitesse d’anneau de 1 mégabits.
3
Vitesse d’anneau de 4 mégabits.
4
Vitesse d’anneau de 16 mégabits.
dot5ActMonParticipate
L’objet indique si l’unité doit participer ou non au processus de sélection
active du moniteur.
Instance
Valeur
Action
n
1
Doit participer.
2
Ne doit pas participer.
dot5Functional
Masque fonctionnel permettant à l’unité token-ring de spécifier les adresses
à partir desquelles elle recevra des trames.
Instance
Valeur
Action
n
m.m.m.m.m.m
Masque fonctionnel à définir.
Les variables suivantes sont définies dans la consigne RFC comme étant en lecture seule,
mais nous vous conseillons de leur affecter des droits en lecture-écriture. Elles concernent
des manipulations d’horloge complexes. Etudiez-les attentivement dans RFC pour bien
comprendre leurs interactions. snmpd permet au demandeur de les définir, mais l’unité ne
le pourra peut-être pas. Pour plus d’informations, consultez la documentation relative au
pilote de l’unité. Les variables sont :
• dot5TimerReturnRepeat
• dot5TimerHolding
• dot5TimerQueuePDU
• dot5TimerValidTransmit
• dot5TimerNoToken
• dot5TimerActiveMon
• dot5TimerStandbyMon
• dot5TimerErrorReport
• dot5TimerBeaconTransmit
• dot5TimerBeaconReceive
5-28
Guide de gestion du système – Communications et réseaux
Les variables ci–après sont définissables via le démon SNMP conformément à RFC 1512.
Le démon se sert de la norme de protocole FDDI Station Management (SMT) 7.2 pour
obtenir des informations. Ceci est déterminé au niveau du microcode. Contrôlez le
microcode dans la documentation FDDI pour vérifier que le microcode SMT 7.2 est utilisé.
fddimibSMTUserData
Variable contenant 32 octets d’informations utilisateur.
Instance
Valeur
Action
n
chaîne
Stocke 32 octets d’informations utilisateur.
fddimibSMTConfigPolicy
Etat des politiques de configuration, notamment l’utilisation de la politique
”hold” de maintien en l’état.
Instance
Valeur
Action
n
0
Ne pas utiliser la politique “hold”.
1
Utiliser la politique “hold”.
fddimibSMTConnectionPolicy
Etat des politiques de connexion dans le noeud FDDI. Voir RFC 1512 pour
plus d’informations sur les valeurs définissables spécifiques.
Instance
Valeur
Action
n
k
Définit les politiques de connexion.
fddimibSMTTNotify
Horloge, exprimée en secondes, utilisée dans le protocole Neighbor
Notification. Sa valeur est comprise entre 2 et 30 secondes
(30 secondes par défaut).
Instance
Valeur
Action
n
k
Définit la valeur de l’horloge.
fddimibSMTStatRptPolicy
Etat de la génération de trames de compte rendu d’état.
Instance
Valeur
Action
n
1
Le noeud génère des trames de compte
rendu d’état pour les événements
implémentés.
2
Le noeud ne crée pas de trames de compte
rendu d’état.
fddimibSMTTraceMaxExpiration
Cette variable définit la valeur maximale d’expiration de l’horloge pour le suivi.
Instance
Valeur
Action
n
k
Définit l’expiration maximale de l’horloge
(en millisecondes).
Administration du réseau
5-29
fddimibSMTStationAction
Cette variable provoque l’exécution par l’entité SMT d’une action
spécifique. Pour en savoir plus, voir la RFC.
Instance
Valeur
Action
n
k
Définit une action sur l’entité SMIT. Valeurs
comprises entre 1 et 8.
fddimibMACRequestedPaths
Définit les chemins dans lesquels le MAC (medium access control) doit être
inséré.
Instance
Valeur
Action
n.n
k
Définit le chemin demandé pour le MAC.
fddimibMACFrameErrorThreshold
Seuil au-delà duquel un compte rendu d’état du MAC doit être généré.
Définit le nombre d’erreurs à partir duquel générer un compte rendu.
Instance
Valeur
Action
n.n
k
Définit le nombre d’erreurs à partir duquel
générer un compte rendu d’état MAC.
fddimibMACMAUnitdataEnable
Cette variable détermine la valeur de l’indicateur MA_UNITDATA_Enable
dans RMT. La valeur initiale et par défaut de cet indicateur est ”vrai” (1).
Instance
Valeur
Action
n.n
1
Marque l’indicateur MA_UNITDATA_Enable
comme vrai (true).
2
Marque l’indicateur MA_UNITDATA_Enable
comme faux (false).
fddimibMACNotCopiedThreshold
Seuil déterminant à quel moment est généré un compte rendu de condition
de MAC.
Instance
Valeur
Action
n.n
k
Définit le nombre d’erreurs à partir duquel
générer un compte rendu de condition de
MAC.
Les trois variables suivantes, interdépendantes, concernent l’horloge. Avant de les modifier,
assurez-vous que vous avez bien assimilé leur fonction, telle que définie dans RFC 1512.
• fddimibPATHTVXLowerBound
• fddimibPATHTMaxLowerBound
• fddimibPATHMaxTReq
5-30
Guide de gestion du système – Communications et réseaux
fddimibPORTConnectionPolicies
Spécifie les politiques de connexion pour le port spécifié.
Instance
Valeur
Action
n.n
k
Définit les politiques de con–
nexion pour le port spécifié.
fddimibPORTRequestedPaths
Cette variable est la liste des chemins permis du port. Le premier octet
correspond à “aucun”, le deuxième, à “arborescence”, et le troisième, à
“homologue”.
Instance
Valeur
Action
n.n
ccc
Définit les chemins du port.
fddimibPORTLerCutoff
Estimation du taux d’erreur de liaison au-delà duquel une connexion de liaison
sera rompue. La valeur est comprise entre 10**-4 et 10**-15, et est rapportée
comme la valeur absolue du logarithme à base 10 (valeur par défaut : 7).
Instance
Valeur
Action
n.n
k
Définit le LerCutoff du port.
fddimibPORTLerAlarm
Estimation du taux d’erreur de liaison au-delà duquel une connexion de
liaison génère une alarme. La valeur est comprise entre 10**-4 et 10**-15
et est rapportée comme la valeur absolue du logarithme à base 10 de
l’estimation (valeur par défaut : 8).
Instance
Valeur
Action
n.n
k
Définit le LerAlarm du port.
fddimibPORTAction
Cette variable entraîne l’exécution d’une action spécifique par le PORT.
Pour en savoir plus, voir la RFC.
Instance
Valeur
Action
n
k
Définit une action sur le port défini. Valeurs
comprises entre 1 et 6.
Remarque :
RFC 1213 décrit toutes les variables des tables atEntry et
ipNetToMediaEntry comme étant en lecture-écriture. Le support de set n’est
assuré que pour les variables atEntry aux adresses atPhysAddress et
atNetAddress, et pour les variables ipNetToMediaEntry aux adresses
ipNetToMediaPhysAddress, ipNetToMediaNetAddress, et de type
ipNetToMediaType. Les requêtes set acceptées qui spécifient les autres
attributs non acceptés dans ces deux tables sont : atIfIndex et
ipNetToMediaIfIndex. Aucune réponse d’erreur n’est renvoyée à l’émetteur
de la requête set, mais la requête get suivante montrera que les valeurs
originales sont retenues.
RFC 1213 décrit toutes les variables de la table ipRouteEntry comme étant en
lecture-écriture, sauf ipRouteProto. Comme mentionné ci-dessus, le support de set n’est
assuré que pour les variables ipRouteDest, ipRouteNextHop et ipRouteType. Pour
accepter des requêtes set pouvant spécifier plusieurs attributs de route non pris en
charge, les requêtes set pour les autres variables de la table ipRouteEntry sont
acceptées : ipRouteIfIndex, ipRouteMetric1, ipRouteMetric2, ipRouteMetric3,
ipRouteMetric4, ipRouteMetric5, ipRouteAge et ipRouteMask. Aucune réponse d’erreur
Administration du réseau
5-31
n’est renvoyée à l’émetteur de la requête set, mais la requête get suivante montrera que
les valeurs originales sont retenues. Le démon snmpd ne coordonne pas le routage
avec le démon routed. Si le démon gated s’exécute et a enregistré la variable
ipRouteTable avec le démon snmpd, les requêtes set sur ipRouteTable ne sont pas
autorisées.
RFC 1229 décrit les variables définissables ; snmpd permet leur définition.
Pour les exceptions, reportez-vous aux entrées précédentes.
Exemples
Les exemples suivants utilisent la commande snmpinfo. Le nom de communauté par défaut
de snmpinfo, public, est supposé avoir accès en lecture-écriture à la sous-arborescence
MIB correspondante :
snmpinfo –m set sysContact.0=”Primary contact: Bob Smith, office phon
e: 555–5555,
beeper: 9–123–4567. Secondary contact: John Harris, phone: 555–1234.”
Cette commande affecte à sysContact.0 la valeur de la chaîne spécifiée. S’il existe déjà
une entrée pour sysContact.0, elle est remplacée.
snmpinfo –m set sysName.0=”bears.austin.ibm.com”
Cette commande affecte à sysName.0 la valeur de la chaîne spécifiée. S’il existe déjà une
entrée pour sysName.0, elle est remplacée.
snmpinfo –m set sysLocation.0=”Austin site, building 802, lab 3C–23
, southeast
corner of the room.”
Cette commande affecte à sysLocation.0 la valeur de la chaîne spécifiée.
S’il existe déjà une entrée pour sysLocation.0, elle est remplacée.
snmpinfo –m set ifAdminStatus.2=2
Désactive la carte d’interface réseau dont l’ifIndex a la valeur 2. Si la valeur affectée est
égale à 1, la carte d’interface est activée.
snmpinfo –m set atPhysAddress.2.1.192.100.154.2=02:60:8c:2e:c2:00
snmpinfo –m set ipNetToMediaPhysAddress.2.1.192.100.154.2=02:60:8c:
2e:c2:00
Changent l’adresse matérielle dans l’entrée de la table ARP de 192.100.154.2 en
02:60:8c:2e:c2:00. Elles affectent la même entrée de table ARP. La variable
MIB atPhysAddress est une variable dépréciée, remplacée par la variable
MIB ipNetToMediaPhysAddress. Donc, atPhysAddress et ipNetToMediaPhysAddress ont
accès à la même structure dans la table ARP du noyau TCP/IP.
snmpinfo –m set atNetAddress.2.1.192.100.154.2=192.100.154.3
snmpinfo –m set ipNetToMediaNetAddress.2.1.192.100.154.2=192.100.154.3
Changent l’adresse IP dans l’entrée de la table ARP de 192.100.154.2 en
192.100.154.3. Elles affectent la même entrée de table ARP. La variable MIB
atNetAddress est une variable dépréciée, remplacée par la variable MIB
ipNetToMediaNetAddress. Ainsi, atNetAddress et ipNetToMediaNetAddress ont accès à la
même structure dans la table ARP du noyau TCP/IP.
snmpinfo –m set ipForwarding.0=1
Définit le noyau TCP/IP de sorte qu’il puisse acheminer les paquets si l’hôte de l’agent a
plusieurs interfaces actives. S’il n’en a qu’une, la requête set échoue et l’agent snmpd
renvoie l’erreur badValue.
snmpinfo –m set ipDefaultTTL=50
5-32
Guide de gestion du système – Communications et réseaux
Permet à un datagramme IP utilisant la durée de vie (TTL) par défaut de passer par des
passerelles (50 maximum) avant d’être rejeté. A chaque traitement du datagramme par une
passerelle, cette dernière décrémente de 1 le champ de durée de vie. En outre, chaque
passerelle décrémente ce champ du nombre de secondes qu’a attendu le datagramme pour
être traité avant d’être transmis à la destination suivante.
snmpinfo –m set ipRouteDest.192.100.154.0=192.100.154.5
Définit l’adresse IP de destination de la route associée à 192.100.154.0 comme étant
192.100.154.5 (en supposant que la route 192.100.154 existait déjà).
snmpinfo –m set ipRouteNextHop.192.100.154.1=129.35.38.47
Définit une route vers l’hôte 192.100.154.1 via la passerelle hôte 129.35.38.47
(en supposant que la route 192.100.154.1 existait déjà).
snmpinfo –m set ipRouteNextHop.192.100.154.0=192.100.154.7
Définit une route vers le serveur de classe C 192.100.154 via la passerelle hôte
192.100.154.7 (en supposant que la route 192.100.154.0 existait déjà).
Remarquez que la partie hôte de l’adresse doit être 0 pour indiquer une adresse de réseau.
snmpinfo –m set ipRouteType.192.100.154.5=2
Supprime toute route pour l’hôte 192.100.154.5.
snmpinfo –m set ipRouteDest.129.35.128.1=129.35.128.1
ipRouteType.129.35.128.1=3
ipRouteNextHop.129.35.128.1=129.35.128.90
Crée une nouvelle route depuis l’hôte 129.35.128.90 jusqu’à
passerelle.
129.35.128.1 comme
snmpinfo –m set ipNetToMediaType.2.1.192.100.154.11=4
Définit l’entrée de la table ARP en 192.100.154.11 comme statique.
snmpinfo –m set snmpEnableAuthenTraps=2
Indique à l’agent snmpd sur l’hôte spécifié de ne pas générer d’interruptions de type
authenticationFailure.
snmpinfo –m set smuxPstatus.1=2
Annule la validité de l’homologue SMUX 1. L’effet secondaire est que la connexion entre
l’agent snmpd et cet homologue SMUX prend fin.
snmpinfo –m set smuxTstatus.8.1.3.6.1.2.1.4.21.0=2
Annule la validité ou supprime le montage de l’arborescence SMUX 1.3.6.1.2.1.4.21,
la table ipRoute. Le premier nombre de l’instance indique le nombre de niveaux dans
l’identificateur d’arborescence SMUX. Le dernier nombre indique la priorité smuxTpriority.
Dans cet exemple, il y a 8 niveaux dans l’identificateur d’arborescence SMUX :
1.3.6.1.2.1.4.21. La priorité, 0, est la plus haute.
snmpinfo –m set ifExtnsPromiscuous.1=1 ifExtnsPromiscuous.2=2
Active le mode ”promiscuous” pour la première unité de la table d’interfaces et le désactive
pour la deuxième unité.
snmpinfo –m set ifExtnsTestType.1=testFullDuplexLoopBack
Administration du réseau
5-33
Lance le test testFullDuplexLoopBack sur l’interface 1.
snmpinfo –m set ifExtnsRcvAddrStatus.1.129.35.128.1.3.2=2
Indique à l’interface 1 de supprimer l’adresse physique 129.35.128.1.3.2 de la liste des
adresses acceptables.
snmpinfo –m set dot5Commands.1=2
Demande à la première interface d’exécuter une ouverture.
snmpinfo –m set dot5RingSpeed.1=2
Indique à la première interface de définir sa vitesse d’anneau à 1 mégabit.
snmpinfo –m set dot5ActMonParticipate.1=1
Indique à la première interface de participer au processus de sélection du moniteur actif.
snmpinfo –m set dot5Functional.1=255.255.255.255.255.255
Définit le masque d’adresse fonctionnel de sorte que tout soit autorisé.
snmpinfo –m set fddimibSMTUserData.1=”Greg’s Data”
Définit les données utilisateur sur la première entité SMT comme ”Greg’s Data”.
snmpinfo –m set fddimibMACFrameErrorThreshold.1.1=345
Définit le seuil des erreurs de trame à 345 sur le premier MAC de la première entité SMT.
Remarque :
Toutes les variables décrites sont définissables par l’une ou l’autre des
méthodes indiquées précédemment.
Pour en savoir plus sur les protocoles et les adresses Internet, reportez–vous à Protocole
ARP, page 4-22 et à Adresses Internet, page 4-60.
5-34
Guide de gestion du système – Communications et réseaux
Identification et résolution des incidents liés au démon SNMP
Si l’agent snmpd ne se comporte pas comme il le devrait, voici quelques indices pour vous
aider à diagnostiquer et corriger le problème. Il est fortement recommandé de démarrer
l’agent snmpd en spécifiant une journalisation. En cas d’incidents suite à l’appel du démon
snmpd, il est vivement recommandé de configurer le démon syslogd pour une
journalisation au niveau de l’utilitaire du démon et de la gravité DEBUG. Reportez–vous à la
commande snmpd et au fichier snmpd.conf pour plus d’informations sur la journalisation
snmpd.
Interruption prématurée
Si le démon snmpd s’arrête dès son appel :
• La cause de l’arrêt est enregistrée dans le fichier journal snmpd ou syslogd configuré.
Consultez ce fichier pour prendre connaissance du message d’erreur FATAL.
Solution : Corrigez le problème et relancez le démon snmpd.
• La syntaxe de la ligne de commande snmpd est incorrecte. Si vous avez appelé la
commande snmpd sans SRC (System Resource Controller), la syntaxe requise s’affiche
à l’écran. Si vous avez appelé le démon snmpd sous SRC (System Resource
Controller), la syntaxe requise ne s’affiche pas à l’écran. Consultez le fichier journal pour
connaître la syntaxe appropriée.
Solution : Corrigez la syntaxe de la commande snmpd.
• Seul l’utilisateur racine doit appeler le démon snmpd. L’agent snmpd n’est pas exécuté
s’il n’est pas appelé par l’utilisateur racine.
Solution : Ouvrez une session utilisateur racine et relancez le démon snmpd.
• Le fichier snmpd.conf doit appartenir à l’utilisateur racine. L’agent snmpd vérifie la
propriété du fichier de configuration. Si le fichier n’appartient pas à l’utilisateur racine,
l’agent snmpd s’arrête, ceci étant considéré comme une erreur fatale.
Solution : Vérifiez que vous êtes connecté en tant qu’utilisateur racine, changez le
propriétaire du fichier de configuration et relancez le démon snmpd.
• Le fichier snmpd.conf doit exister. Si vous n’avez pas spécifié le fichier de journalisation
sur la ligne de commande snmpd via l’indicateur –c, c’est le fichier /etc/snmpd.conf qui
doit exister. Si vous avez accidentellement supprimé le fichier /etc/snmpd.conf,
réinstallez l’image bos.net.tcp.client ou reconstituez le fichier avec les entrées de
configuration adéquates, telles que définies dans la page man du fichier snmpd.conf.
Si vous aviez vraiment spécifié le fichier de configuration sur la ligne de commande
snmpd via l’indicateur –c, vérifiez que ce fichier existe et qu’il appartient à l’utilisateur
racine. Vous devez spécifier le chemin d’accès complet et le nom du fichier de
configuration si vous ne voulez pas utiliser le fichier /etc/snmpd.conf par défaut.
Solution : Assurez-vous de l’existence du fichier de configuration spécifié et de son
appartenance à l’utilisateur racine. Relancez le démon snmpd.
• Il y a déjà une liaison avec le port udp 161. Vérifiez que le démon snmpd n’est pas déjà
en cours d’exécution. Lancez la commande ps –eaf | grep snmpd pour déterminer si un
processus du démon snmpd est déjà en cours. Un seul agent snmpd peut effectuer la
liaison au port udp 161.
Solution : Tuez l’agent snmpd existant ou n’essayez pas de démarrer un autre
processus du démon snmpd.
Administration du réseau
5-35
Défaillance du démon
Si le démon snmpd échoue lorsque vous émettez un signal refresh ou kill -1 :
• La cause de l’arrêt est enregistrée dans le fichier journal snmpd ou syslogd configuré.
Recherchez dans l’un ou l’autre le message d’erreur FATAL.
Solution : Corrigez le problème et relancez le démon snmpd.
• Vérifiez que vous avez spécifié le chemin d’accès complet et le nom du fichier de
configuration à l’appel du démon snmpd. Le démon snmpd ”bifurque”, passant au
répertoire racine lorsqu’il est appelé. Si vous n’avez pas spécifié le nom complet du
fichier, l’agent snmpd ne peut pas le trouver lors d’un rafraîchissement. Il s’agit d’une
erreur fatale qui entraîne l’arrêt prématuré de l’agent snmpd.
Solution : Spécifiez le chemin d’accès complet et le nom du fichier de configuration
snmpd. Vérifiez qu’il appartient à l’utilisateur racine. Relancez le démon snmpd.
• Vérifiez que le fichier de configuration du snmpd existe encore. Il peut avoir été
malencontreusement supprimé après l’appel de l’agent snmpd. Si l’agent snmpd ne
peut pas l’ouvrir, l’agent snmpd s’arrête prématurément.
Solution : Recréez le fichier de configuration snmpd, assurez-vous qu’il appartient à
l’utilisateur racine et relancez le démon snmpd.
Accès impossible aux variables MIB
Si l’agent snmpd ne peut accéder aux variables MIB, ou s’il s’exécute mais que l’application
du gestionnaire SNMP (Simple Network Management Protocol) dépasse le délai d’attente
d’une réponse de l’ agent snmpd :
• Vérifiez la configuration réseau de l’hôte sur lequel s’exécute l’agent snmpd à l’aide de la
commande netstat –in. Vérifiez que l’unité lo0, en boucle, est active. Si l’unité n’est pas
active, un * (astérisque) est affiché en regard de lo0. Pour que l’agent snmpd serve les
requêtes, lo0 doit être active.
Solution : Emettez la commande suivante pour démarrer l’interface de boucle :
ifconfig lo0 inet up
• Vérifiez que le démon snmpd a une route conduisant à l’hôte sur lequel vous avez émis
les requêtes.
Solution : Sur l’hôte sur lequel s’exécute le démon snmpd, ajoutez une route conduisant
à l’hôte sur lequel la requête SNMP a émis la commande route add. Reportez-vous à la
commande route.
• Vérifiez que le nom de l’hôte et son adresse IP sont les mêmes.
Solution : Redéfinissez le nom de l’hôte pour le faire correspondre à son adresse IP.
• Vérifiez si localhost (hôte local) est défini comme adresse IP de lo0.
Solution : Définissez que localhost est à la même adresse que celle utilisée par l’adresse
IP de lo0 (généralement 127.0.0.1).
5-36
Guide de gestion du système – Communications et réseaux
Accès impossible aux variables MIB dans une entrée de communauté
Si une entrée de communauté est spécifiée dans le fichier de configuration avec un nom de
vue MIB, mais qu’il est impossible d’accéder aux variables MIB :
• Vérifiez l’entrée de communauté. Si vous y avez indiqué un nom de vue, tous les champs
de cette entrée sont obligatoires.
Solution : Spécifiez tous les champs de l’entrée de la communauté dans le fichier de
configuration. Rafraîchissez l’agent snmpd et relancez la requête.
• Assurez-vous que le mode d’accès défini dans l’entrée de la communauté correspond à
votre type de requête. Si vous émettez une requête get ou get–next, vérifiez que la
communauté est dotée de droits en lecture seule ou en lecture-écriture. Si vous émettez
une requête set, vérifiez qu’elle est dotée de droits en lecture-écriture.
Solution : Corrigez le mode d’accès dans l’entrée de la communauté. Rafraîchissez
l’agent snmpd et relancez la requête.
• Assurez-vous que vous avez spécifié une entrée de vue correspondant au nom de vue
indiqué dans l’entrée de communauté. Faute de quoi, l’agent snmpd interdit l’accès à
cette communauté. Il est impératif de spécifier une entrée de vue pour une entrée de
communautée dans le fichier de configuration.
Solution : Spécifiez une entrée de vue correspondant au nom de vue indiqué dans
l’entrée de la communauté. Rafraîchissez l’agent snmpd et relancez la requête.
• Si vous avez spécifié iso comme sous-arborescence MIB pour votre entrée de vue,
assurez-vous d’avoir indiqué iso.3. L’instance de 3 est requise pour que l’agent snmpd
ait accès à la portion org de l’arborescence iso.
Solution : Spécifiez iso.3 comme sous-arborescence MIB dans l’entrée de vue.
Rafraîchissez l’agent snmpd et relancez la requête.
• Vérifiez l’adresse IP et le masque de réseau dans l’entrée de la communauté. Vérifiez
que l’hôte à partir duquel vous émettez la requête SNMP est inclus dans la communauté
spécifiée.
Solution : Modifiez les champs IP address (adresse IP) et network mask (masque de
réseau) dans l’entrée de communauté du fichier de configuration pour y inclure l’hôte à
partir duquel vous émettez la requête SNMP.
Absence de réponse de l’agent
Si l’adresse IP de la communauté est 0.0.0.0, mais que l’agent snmpd ne répond pas :
• Vérifiez le champ network mask (masque de réseau) dans l’entrée de la communauté.
Pour donner un accès général à ce nom de communauté, le champ network mask doit
avoir la valeur 0.0.0.0. Si vous avez affecté au champ network mask la valeur
255.255.255.255, vous avez configuré l’agent snmpd de façon à interdire toute requête
avec le nom de communauté spécifié.
Solution : Donnez la valeur 0.0.0.0 au champ network mask (masque de réseau) de
l’entrée de la communauté. Rafraîchissez l’agent snmpd et relancez la requête.
• Assurez-vous que le mode d’accès défini dans l’entrée de la communauté correspond à
votre type de requête. Si vous émettez une requête get ou get–next, vérifiez que la
communauté est dotée de droits en lecture seule ou en lecture-écriture. Si vous émettez
une requête set, vérifiez qu’elle est dotée de droits en lecture-écriture.
Solution : Corrigez le mode d’accès dans l’entrée de la communauté.
Rafraîchissez l’agent snmpd et relancez la requête.
Administration du réseau
5-37
Message noSuchName
Si, lors d’une tentative de définition d’une variable MIB que l’agent snmpd est censé
prendre en charge, le message d’erreur noSuchName est renvoyé :
La requête set émise n’incluait peut-être pas de nom de communauté correspondant à une
communauté autorisée avec un accès en écriture. Le protocole SNMP spécifie qu’une
requête set mentionnant une communauté avec des droits d’accès inadéquats doit recevoir
en réponse le message d’erreur noSuchName.
Solution : Emettez la requête set avec le nom d’une communauté dotée de droits d’accès
en écriture et comprenant l’hôte à partir duquel est émise la requête set.
5-38
Guide de gestion du système – Communications et réseaux
Chapitre 6. Système de fichiers NFS
Ce chapitre fournit des informations sur NFS (Network File System),
mécanisme de stockage des fichiers sur le réseau. Il traite des points suivants :
• Système de fichiers NFS : généralités, page 6-2
• Installation et configuration de NFS, page 6-16
• PC–NFS, page 6-32
• Gestion des mappes LDAP Automount, page 6-35
• WebNFS, page 6-36
• Gestionnaire NLM (Network Lock Manager), page 6-37
• Sécurité NFS, page 6-41
• Identification des incidents NFS, page 6-42
• Informations de référence NFS, page 6-52
Système de fichiers NFS
6-1
Système de fichiers NFS : généralités
Le système NFS (Network File System) est un système de fichiers distribués, donnant aux
utilisateurs accès aux fichiers et répertoires sur des ordinateurs distants - ils ont ainsi la
possibilité de les traiter comme s’il s’agissait de fichiers et répertoires locaux. Les
utilisateurs, par exemple, peuvent utiliser les commandes du système d’exploitation pour
créer, supprimer, lire, écrire des fichiers et définir des attributs sur les fichiers et les
répertoires distants.
Le module NFS contient les commandes et démons de NFS, NIS (Network Information
Service) et d’autres services. Mais, bien qu’ils soient installés simultanément, NFS et NIS
constituent deux modules distincts, configurés et administrés indépendamment. Pour plus
d’informations sur NIS et NIS+, consultez le manuel AIX 5L Version 5.3 Network Information
Services (NIS and NIS+).
AIX 5.3 et les versions ultérieures prennent en charge les protocoles NFS version 2, 3 et 4.
NFS version 4 est la dernière version de NFS et est décrite par les spécifications RFC 3530.
Nous discuterons plus en détail de la compatibilité AIX avec la NFS version 4 plus loin dans
cette section. Les clients NFS utilisent le protocole NFS version 3 par défaut.
Cette section traite des points suivants :
•
Services NFS, page 6-2
•
Liste de contrôle d’accès (ACL) sous NFS, page 6-3
•
Système de fichiers cache (CacheFS), page 6-5
•
Mappage de fichiers sous NFS, page 6-7
•
Types de montage NFS, page 6-7
•
Exportation et montage NFS, page 6-8
•
Fichiers NFS, page 6-10
•
Implémentation de NFS, page 6-12
•
Contrôle de NFS, page 6-13
•
Prise en charge de NFS version 4, page 6-15
Services NFS
Les services NFS sont fournis via une relation client-serveur. Les ordinateurs qui rendent
leurs systèmes de fichiers, leurs répertoires et d’autres ressources accessibles à distance
sont appelés des serveurs. Le fait de rendre ces ressources disponibles est appelé
exportation. Les ordinateurs et leurs processus qui tirent parti des ressources du serveur
sont considérés comme des clients. Lorsqu’un client monte un système de fichiers exporté
par un serveur, il a accès aux fichiers du serveur (l’accès aux répertoires peut être limité à
certains clients).
Les principaux services NFS sont les suivants :
6-2
Service
Description
Service Mount
Via le démon /usr/sbin/rpc.mountd sur le serveur et la commande
/usr/sbin/mount sur le client. Ce service est disponible uniquement
avec NFS version 2 et version 3.
Remote File
access
Via le démon /usr/sbin/nfsd sur le serveur et la commande
/usr/sbin/biod sur le client.
Service Remote
execution
Via le démon /usr/sbin/rpc.rexd sur le serveur et la commande
/usr/sbin/on sur le client.
Guide de gestion du système – Communications et réseaux
Service
Description
Service Remote
System Statistics
A partir du démon /usr/sbin/rpc.rstatd sur le serveur et la
commande /usr/bin/rup sur le client.
Service Remote
User Listing
A partir du démon /usr/lib/netsvc/rusers/rpc.rusersd sur le
serveur et la commande /usr/bin/rusers sur le client.
Service Boot
Parameters
Fournit des paramètres de démarrage aux clients sans disque
SunOS via le démon /usr/sbin/rpc.bootparamd sur le serveur.
Service Remote
Wall
À partir du démon /usr/lib/netsvc/rwall/rpc.rwalld sur le serveur
et de la commande /usr/sbin/rwall sur le client.
Service Spray
Envoie un flot unilatéral de paquets RPC via le démon
/usr/lib/netsvc/spray/rpc.sprayd sur le serveur et la commande
/usr/sbin/spray sur le client.
Service PC
authentication
Fournit un service d’authentification utilisateur pour PCNFS via le
démon /usr/sbin/rpc.pcnfsd sur le serveur.
Service Enhanced
security
Fournit au client et au serveur un accès à des services de sécurité
plus évolués, tels que Kerberos 5. Le démon /usr/sbin/gssd
donne à NFS un accès aux services de sécurité fournis par le
service d’authentification réseau (NAS). L’ensemble des fichiers
du service d’authentification réseau (NAS) et de la bibliothèque
cryptographique (krb5.client.rte, krb5.server.rte et
modcrypt.base) doivent être installés. Ces ensembles de fichiers
peuvent être installés depuis le module d’extension AIX (AIX
Expansion Pack).
Service Identity
translation
Procède à la traduction entre les principaux de sécurité, les chaînes
d’identité NFS version 4 et les ID correspondants de leurs système
numériques. Ce fichier assure, en outre, un mappage des
informations d’identité provenant des domaines NFS version 4
étrangers. Ces services sont fournis par le démon
/usr/sbin/nfsrgyd .
Remarque :
Un ordinateur peut être simultanément serveur NFS et client NFS.
Les serveurs NFS version 2 et 3 sont sans état, c’est–à–dire que le serveur ne conserve
aucune information de transaction sur ses clients. Une transaction NFS correspond à une et
une seule opération complète sur un fichier. Pour NFS, c’est le client qui doit mémoriser les
informations requises pour les usages ultérieurs de NFS.
Un serveur NFS version 4 est un serveur avec état suite à des opérations d’ouverture et de
verrouillage du fichier définies dans le protocole NFS version 4.
Listes de contrôle d’accès (ACL) sous NFS
L’implémentation d’AIX NFS version 4 prend en charge deux types d’ACL : NFS4 et AIXC.
Ces deux types d’ACL sont décrits ci–dessous.
Système de fichiers NFS
6-3
NFS4 ACL
NFS4 ACL est la liste de contrôle d’accès définie par le protocole NFS version 4. Comme il
est indépendant de la plate–forme, il peut être pris en charge par d’autres clients ou
serveurs de fournisseurs. Les clients et serveurs de NFS version 4 ne doivent pas prendre
en charge NFS4 ACL.
Dans un serveur AIX, si une instance de système de fichiers physique sous–jacente prend
en charge NFS4 ACL, le serveur AIX NFS4 gère NFS4 ACL pour cette instance de système
de fichiers. La plupart des types de systèmes de fichiers physiques sur AIX ne prennent pas
en charge NFS4 ACL. Ces types de systèmes de fichiers incluent CFS, UDF, JFS mais ne
s’y limitent pas ; idem pour JFS2 incluant les attributs étendus version 1. Toutes les
instances de JFS2 intégrant les attributs étendus version 2 prennent en charge NFS4 ACL.
Les systèmes de fichiers client NFS version 4 peuvent lire et écrire NFS4 ACL si l’instance
de système de fichiers NFS version 4 exportée sur le serveur gère NFS4 ACL.
AIX ACL
AIXC ACL est un ACL propriétaire d’AIX. Il n’est pas défini par le protocole NFS version 4,
et il est compris uniquement par les serveurs et clients AIX.
Sur un serveur NFS version 4, AIXC ACL est pris en charge lorsque l’instance de système
de fichiers sous–jacente prend en charge AIXC ACL. Toutes les instances de JFS et de
JFS2 prennent en charge AIXC ACL.
Un client NFS version 4 possède une option de montage prévue pour activer ou désactiver
la prise en charge AIX ACL. Par défaut, la liste de contrôle d’accès AIXC n’est pas prise en
charge. L’utilisateur d’un système de fichiers client NFS version 4 peut lire et écrire AIXC
ACL à condition que le client et le serveur exécutent tous deux AIX, que l’instance de
système de fichiers physique sous–jacente du serveur gère AIXC ACL et que le client AIX
monte l’instance du système de fichiers lorsque AIXC ACL est activé. La prise en charge
d’AIXC ACL dans NFS version 4 est similaire à la prise en charge d’ AIXC ACL dans les
implémentations d’AIX NFS version 2 et NFS version 3.
Toutes les instances d’un système de fichiers JFS2 incluant l’attribut étendu version 2
prennent en charge à la fois AIXC ACL et NFS4 ACL. Un fichier figurant dans ce type de
système de fichiers peut posséder le mode bits uniquement (aucun ACL), un NFS4 ACL ou
un AIXC ACL. Cependant, il ne peut présenter NFS4 ACL et AIXC ACL en même temps.
La commande aclgettypes peut être utilisée pour déterminer les types ACL sur lesquels on
peut lire et écrire dans une instance de système de fichiers. Cette commande peut produire
différentes sorties selon qu’elle est exécutée localement par rapport à un système de
fichiers physique sur un serveur NFS version 4 ou qu’elle est exécutée par rapport au
même système de fichiers sur un client NFS version 4. Par exemple, une instance de
système de fichiers NFS version 4 et le serveur NFS version 4 peuvent prendre en charge
NFS4 ACL et AIXC ACL, mais le client est configuré uniquement pour envoyer et recevoir
NFS4 ACL. Dans ce cas, lorsque la commande aclgettypes est exécutée depuis un
système de fichiers client NFS version 4, seul NFS4 est obtenu. Ainsi, si un utilisateur du
client requiert un AIXC ACL, une erreur est renvoyée.
La source autorisée pour accéder au contrôle se trouve dans le système de fichiers
sous–jacent exporté par le serveur NFS. Le système de fichiers tient compte des contrôles
d’accès au fichier (ACL ou bits de permission), des références de l’appelant et d’autres
restrictions du système local qui peuvent s’appliquer. Les applications et utilisateurs ne
doivent pas supposer que le seul examen des modes bits UNIX ou des ACL permet de
prédire un accès de manière concluante.
Les commandes aclget, aclput et alcedit peuvent être utilisées sur le client pour manipuler
NFS ou les AIX ACL. Pour plus d’informations, reportez–vous à la section traitant des listes
de contrôle d’accès dans le manuel AIX 5L Version 5.3 – Guide de sécurité.
6-4
Guide de gestion du système – Communications et réseaux
Système de fichiers cache (CacheFS)
Le système de fichiers cache (CacheFS) est un mécanisme de cache qui améliore les
performances et l’évolutivité du serveur NFS en réduisant la charge du réseau et du
serveur. Conçu comme un système de fichiers en couches, CacheFS permet de cacher un
système sur un autre. Dans un environnement NFS, CacheFS augmente le taux
client-par-serveur, réduit la charge du serveur et du réseau et améliore les performances
des liaisons client lentes, telles que le protocole PPP (Point-to-Point Protocol).
Un cache est créé sur la machine client de sorte que l’accès aux systèmes de fichiers
définis pour être montés dans le cache s’effectue localement et non par le réseau. Les
fichiers sont placés dans le cache la première fois qu’un utilisateur effectue une demande
d’accès. Le cache reste vide tant qu’un utilisateur ne demande pas l’accès à un (ou
plusieurs) fichier(s). Les premières requêtes d’accès peuvent sembler lentes, mais les
accès suivants aux mêmes fichiers sont plus rapides.
Remarques :
1. Vous ne pouvez pas cacher les systèmes de fichier / (racine) et /usr.
2. Vous ne pouvez monter que des systèmes de fichiers partagés. (Reportez-vous à la
commande exportfs.)
3. Cacher un système de fichiers disque JFS local (Journaled File System) n’apporte aucun
gain de performances.
4. Les tâches du tableau suivant sont réservées aux utilisateurs détenant les droits racine
ou système.
Système de fichiers NFS
6-5
Tâches CacheFS
Tâche
Raccourci SMIT
Commande ou fichier
Environnement
d’administration
Web–based System
Manager
Définition d’un
cache
cachefs_admin_create
cfsadmin –c
MountDirectoryName 1.
Logiciel ––> Systèmes de
fichiers ––> Systèmes de
fichiers cache ––>
Nouveau système de
fichiers cache.
Spécification
des fichiers à
monter
cachefs_mount
mount –F cachefs –o
backfstype= FileSysType,
cachedir= CacheDirectory [,
options ]
BackFileSystem
MountDirectoryName 2
ou
edit /etc/ filesystems .
Logiciel ––> Systèmes de
fichiers ––> Aperçu et
tâches ––> Monter un
système de fichiers.
Modification du cachefs_admin_
cache
change
Supprime le cache, puis le
recrée avec les options
adéquates de la commande
mount.
Logiciel ––> Systèmes de
fichiers ––> Systèmes de
fichiers cache ––>
Sélectionné ––>
Supprimer. Configure un
cache comme à la première
rangée de ce tableau.
Affichage des
informations
du cache
cachefs_admin_
change
cfsadmin –l
MountDirectoryName.
Logiciel ––> Systèmes de
fichiers ––> Systèmes de
fichiers cache ––>
Sélectionné ––>
Propriétés.
Suppression
d’un cache
cachefs_admin_
remove
1. Démontage du système de
fichiers
umount
MountDirectoryName
Logiciel ––> Systèmes de
fichiers ––> Systèmes de
fichiers cache ––>
Sélectionné ––>
Supprimer.
2. Détermination de l’ID du
cache :
cfsadmin –l
MountDirectoryName
3. Suppression du système de
fichiers
cfsadmin –d CacheID
CacheDirectory
Vérification de
l’intégrité du
système de
fichiers
cachefs_admin_check
fsck_cachefs CacheDirectory
3.
Logiciel ––> Systèmes de
fichiers ––> Systèmes de
fichiers cache ––>
Sélectionné ––> Vérifier
l’intégrité du cache.
Remarques :
1. Une fois le cache créé, n’exécutez aucune opération à l’intérieur du répertoire cache
lui-même (cachedir). Vous provoqueriez un conflit à l’intérieur du logiciel CacheFS.
6-6
Guide de gestion du système – Communications et réseaux
2. Si vous utilisez la commande mount pour spécifier les fichiers à monter,
vous devez relancer la commande chaque fois que le système est redémarré.
3. Associez l’option –m ou –o à la commande fsck_cachefs pour vérifier les systèmes
de fichiers sans effectuer aucune réparation.
Mappage de fichiers sous NFS
Le mappage de fichiers NFS donne aux programmes d’un client accès à un fichier comme
s’il se trouvait en mémoire. Via la sous–routine shmat, les utilisateurs peuvent mapper des
zones d’un fichier dans leur espace d’adressage : lorsqu’un programme lit ou écrit dans cet
espace mémoire, le fichier est copié en mémoire à partir du serveur ou mis à jour sur le
serveur.
Le mappage de fichiers sous NFS est limité :
• Le partage des informations entre clients est mal assuré.
• Les modifications apportées à un fichier sur un client via un fichier mappé ne sont pas
visibles sur un autre client.
• Verrouiller et déverrouiller des régions d’un fichier est inefficace quant à la coordination
des données entre clients.
Si un fichier NFS doit servir au partage de programmes de différents clients, il convient de
verrouiller les enregistrements et d’exécuter les sous-routines standard read et write.
Plusieurs programmes sur un client peuvent partager des données via un fichier mappé.
Un verrouillage astucieux d’enregistrement peut coordonner les mises à jour sur le fichier
sur le client, sous réserve que l’intégralité du fichier soit verrouillé. Plusieurs clients ne
peuvent partager des données via des fichiers mappés que s’il s’agit de données
immuables (base de données statique, par exemple).
Types de montage NFS
Il existe trois types de montage :
• Prédéfini
• Explicite
• Automatique
Les montages prédéfinis sont spécifiés dans le fichier /etc/filesystems. Chaque strophe
(entrée) de ce fichier définit les caractéristiques d’un montage : elle comprend des données
telles que le nom de l’hôte, le chemin d’accès à distance, le chemin d’accès local, etc.
Adoptez des montages prédéfinis si l’exploitation d’un client requiert toujours le même type
de montage.
Les montages explicites sont l’apanage de l’utilisateur racine. Généralement limités à de
courtes périodes, ils permettent de répondre à un besoin occasionnel, non planifié. Ils
permettent également d’effectuer un montage pour une tâche spéciale, lequel est
généralement inaccessible au client NFS. Ces montages sont généralement entièrement
qualifiés sur la ligne de commande via l’instruction mount assortie de toutes les
informations requises. Les montages explicites ne requièrent pas la mise à jour du fichier
/etc/filesystems. Les systèmes de fichiers explicitement montés le restent tant qu’ils ne
sont pas explicitement démontés via la commande umount ou que le système n’est pas
réinitialisé.
Les montages automatiques sont contrôlés par le démon automount ; l’extension de noyau
AutoFS surveille alors l’activité des répertoires spécifiés. Si un programme ou un utilisateur
tente d’accéder à un répertoire non monté, le démon AutoFS intercepte la demande, monte
le système de fichiers, puis répond à la demande.
Système de fichiers NFS
6-7
Exportation et montage NFS
L’administration du serveur NFS suppose une bonne compréhension du processus
d’exportation et de montage des répertoires. Un serveur NFS doit exporter un fichier
ou un répertoire pour que le client NFS puisse monter ensuite ce fichier ou ce répertoire.
Ces concepts sont décrit de façon plus détaillée dans cette section.
Exportation de répertoires
L’exportation d’un répertoire se fait sur le serveur NFS. Cette opération indique qu’un
répertoire dans l’espace nom du serveur est disponible pour les machines client.
Le répertoire exporté est désigné comme export et inclut tous les fichiers compris
dans le répertoire résidant sur le système de fichiers du répertoire exporté.
Chaque export définit aussi des restrictions d’accès. Parmi les restrictions applicables,
vous pouvez notamment déterminer :
• quels clients ont accès au répertoire exporté
• quelles versions NFS sont susceptibles d’être utilisées par le client pour accéder
au répertoire
• si le client est autorisé ou non à écrire des fichiers dans l’exportation
• quelles méthodes de sécurité doivent être utilisées par le client pour accéder aux
répertoires et fichiers dans l’exportation
Pour une description exhaustive des restrictions et des sémantiques d’exportation
autorisées, reportez–vous à la description de la commande exportfs dans le manuel AIX
5L Version 5.3 Commands Reference, Volume 2 et à la description du fichier /etc/exports
dans le manuel AIX 5L Version 5.3 Files Reference.
Remarque :
Lorsque des attributs d’exportation sont modifiés, vous devez réexporter le
répertoire pour que ces modifications prennent effet. Cela peut également
être nécessaire en cas de modifications apportées aux autres fichiers ou de
modifications externes au serveur. Par exemple, si un nom de client indiqué
dans une liste d’accès est un groupe réseau défini dans le fichier
/etc/netgroup et que la définition du groupe client est modifiée, toutes les
exportations qui utilisent ce groupe réseau dans une liste d’accès doivent
être réexportées afin que la modification entre en vigueur.
De même, si l’adresse IP d’un client est modifiée, toutes les exportations indiquant ce
client dans une liste d’accès doivent être réexportées. Cela vient du fait que le
serveur NFS gère un cache des droits d’accès du client pour chaque exportation. Le
cache est vidé à chaque annulation de l’exportation ou à chaque réexportation. Si les
droits d’accès d’une exportation sont modifiés, en particulier si l’adresse IP d’un client
change ou si un client est supprimé de la liste d’accès, l’annulation d’une exportation
ou la réexportation doit être effectuée afin que l’accès au client soit correctement
représenté dans le cache. Le serveur NFS fait appel au démon rpc.mountd pour
obtenir les droits d’accès de chaque client. Il faut donc que le démon rpc.mountd
soit en cours d’exécution sur le serveur même si celui–ci exporte uniquement des
systèmes de fichiers pour l’accès à NFS version 4.
6-8
Guide de gestion du système – Communications et réseaux
Montage de répertoires
Un client NFS peut monter un répertoire qui a été exporté par un serveur NFS. Monter un
répertoire met les fichiers qui résident sur le serveur NFS à la disposition d’un client NFS.
Un client a accès aux fichiers d’un serveur si les fichiers ont été exportés par le serveur et si
les restrictions d’exportation permettent au client d’accéder aux fichiers d’exportation. Une
fois que le client a monté correctement une exportation de serveur sur un point de montage
dans son espace nom, les fichiers du serveur pour cette exportation existent dans l’espace
nom du client et apparaissent comme fichiers dans le système de fichiers local.
Supposons, par exemple, que vous vouliez exporter le répertoire /tmp sur le serveur
diamond et monter ce répertoire sur le client clip comme répertoire /mnt. Entrez la
commande suivante sur le serveur :
exportfs –i –o access=clip /tmp
Le répertoire /tmp est maintenant disponible pour le client.
Entrez la commande suivante sur le client :
mount diamond:/tmp /mnt
Les répertoires et fichiers du répertoire /tmp du serveur apparaissent désormais dans le
répertoire /mnt du client.
Remarques :
1. Il existe plusieurs différences concernant les techniques de montage entre NFS
versions 2 et 3 d’une part et NFS version 4 d’autre part. Dans NFS versions 2 et 3, le
serveur a exporté les répertoires qu’il voulait rendre disponibles pour le montage. Le
client NFS version 2 ou 3 devait ensuite monter de manière explicite chaque exportation
pour laquelle il voulait un accès.
Avec NFS version 4, le serveur continue d’indiquer les contrôles d’exportation pour
chaque répertoire de serveur ou système de fichiers à exporter pour un accès NFS. A
partir de ces contrôles d’exportation, le serveur produit une seule arborescence de
répertoires contenant toutes les données exportées, et remplit les espaces vides entre
les répertoires exportés. Cette arborescence est un pseudo système de fichiers et
démarre à la pseudo racine du serveur NFS version 4. Le modèle de pseudo système
de fichiers de NFS version 4 permet à un client NFS version 4, en fonction de son
implémentation, d’exécuter un seul montage de la pseudo racine du serveur afin
d’accéder à toutes les données exportées du serveur. Le client AIX NFS prend en
charge cette fonction. Le contenu réel visible par le client dépend des contrôles
d’exportation du serveur.
2. NFS version 4 n’autorise pas le montage fichier à fichier.
Dans AIX 5.3 et les versions supérieures, la version du protocole NFS par défaut utilisée
dans les exportations serveur et les montages client est la version 3. L’option vers peut être
utilisée avec les montages et les exportations pour désigner le protocole NFS version 4.
Lorsqu’un répertoire est exporté par le serveur, ce répertoire n’est disponible que pour les
clients utilisant le protocole NFS version 2 ou version 3 par défaut. Pour autoriser l’accès à
NFS version 4, les options d’exportation doivent inclure l’option vers. Pour plus
d’informations, reportez–vous à la description de la commande exportfs dans le manuel
AIX 5L Version 5.3 Commands Reference, Volume 2.
Système de fichiers NFS
6-9
Processus de montage NFS
Pour accéder aux fichiers sur le serveur, les clients commencent par monter les répertoires
exportés du serveur. Lorsqu’un client monte un répertoire, il ne fait aucun copie de ce
répertoire. Le processus de montage utilise en revanche une série d’appels de procédure
à distance pour donner à un client accès aux répertoires du serveur de façon transparente.
Le processus de montage est le suivant :
1. Lorsque le serveur démarre, le script /etc/rc.nfs exécute la commande exportfs,
laquelle lit le fichier /etc/exports du serveur et informe le noyau des répertoires à
exporter et des restrictions d’accès qu’ils requièrent.
2. Le démon rpc.mountd et plusieurs démons nfsd sont ensuite lancés par le script
/etc/rc.nfs.
3. Le script /etc/rc.nfs exécute ensuite la commande mount, qui lit les systèmes de
fichiers répertoriés dans le fichier /etc/filesystems.
4. mount repère le(s) serveur(s) exportant les informations demandées par le client et
établit la communication avec ce(s) serveur(s). Ce processus est appelé liaison.
5. La commande mount demande ensuite qu’un ou plusieurs serveurs autorisent le client
à accéder aux répertoires inscrits dans le fichier /etc/filesystems.
6. Le démon du serveur reçoit les demandes de montage client, et les accorde ou les
refuse. Si le répertoire demandé est accessible, le démon du serveur envoie au noyau
du client un identificateur appelé descripteur de fichier.
7. Le noyau client attache ce descripteur au point de montage (répertoire) en enregistrant
des informations dans un enregistrement de montage.
La communication client avec le démon rpc.mountd n’a pas lieu lors du traitement du
montage avec NFS version 4. Les opérations réalisées au niveau du protocole central NFS
version 4 servent à assurer les opérations de montage du côté client. L’implémentation du
serveur NFS version 4 fait appel au support du démon rpc.mountd dans le cadre du
traitement de l’accès NFS version 4.
Fichiers NFS
Cette section contient des informations au sujet des fichiers de configuration associés à
NFS et utilisés par NFS.
Fichier /etc/exports
Le fichier /etc/exports recense tous les répertoires exportés par un serveur à ses clients.
Chaque ligne spécifie un seul répertoire. Le serveur exporte automatiquement les
répertoires de la liste à chaque lancement du serveur NFS. Ces répertoires exportés
peuvent ensuite être montés par les clients. La syntaxe d’une ligne du fichier /etc/exports
est la suivante :
directory
–option[,option]
directory est le chemin d’accès complet au répertoire. Options désigne soit un indicateur
simple, tel que ro, soit une liste de noms d’hôtes. Reportez-vous à la documentation du
fichier /etc/exports et de la commande exportfs pour la liste complète des options et leur
description. Le script /etc/rc.nfs ne lance pas les démons nfsd ou le démon rpc.mountd si
le fichier /etc/exports n’existe pas.
Exemple d’entrées d’un fichier /etc/exports :
/usr/games
–ro,access=ballet:jazz:tap
/home
–root=ballet,access=ballet
/var/tmp
/usr/lib
–access=clients
/accounts/database –vers=4,sec=krb5,access=accmachines,root=accmachine1
6-10
Guide de gestion du système – Communications et réseaux
La première entrée indique que le répertoire /usr/games peut être monté par les
systèmes ballet, jazz et tap. Ces systèmes sont habilités à lire des données et à
exécuter des programmes du répertoire, mais ne peuvent y écrire.
La deuxième entrée spécifie que le répertoire /home peut être monté par le système
ballet et que l’accès racine y est autorisé.
La troisième entrée spécifie que n’importe quel client peut monter le répertoire /var/tmp.
(Notez l’absence de liste d’accès.)
La quatrième entrée spécifie une liste d’accès désignée par le groupe réseau clients. En
d’autres termes, ces machines désignées comme appartenant au groupe réseau clients
peuvent monter le répertoire /usr/lib à partir de ce serveur. (Un groupe réseau est
groupe à l’échelle du réseau, ayant accès à certains ressources du réseau à des fins de
sécurité ou d’organisation. Les Netgroups sont contrôlés à l’aide de NIS ou de NIS+. Pour
plus d’informations, consultez le manuel AIX 5L Version 5.3 Network Information Services
(NIS and NIS+) Guide.
La cinquième entrée donne accès au répertoire /accounts/database uniquement pour les
clients appartenant au groupe réseau accmachines utilisant le protocole NFS Version 4 et
accédant au répertoire à l’aide de l’authentification Kerberos 5. L’accès racine est autorisé
uniquement à partir de accmachine1.
Fichier /etc/xtab
Le format du fichier /etc/xtab est similaire à celui du fichier /etc/exports. Ce fichier donne la
liste des répertoires exportés. A chaque exécution de la commande exportfs, le fichier
/etc/xtab est modifié : vous pouvez ainsi exportez temporairement un répertoire sans avoir
à modifier le fichier /etc/exports. Si vous annulez l’exportation du répertoire, il est retiré du
fichier /etc/xtab.
Remarque :
Le fichier /etc/xtab dont la mise à jour est automatique, ne doit pas être
édité.
Fichier /etc/nfs/hostkey
Ce fichier est utilisé par le serveur NFS pour définir le principal Kerberos hôte et
l’emplacement du fichier keytab. Pour savoir comment configurer et gérer ce fichier,
reportez–vous à la description de la commande nfshostkey dans le manuel AIX 5L
Version 5.3 Commands Reference, Volume 4.
Fichier /etc/nfs/local_domain
Ce fichier contient le domaine NFS local du système. Les systèmes partageant le même
domaine local NFS partagent, en principe, les mêmes registres groupe et les mêmes
registres utilisateur. Pour savoir comment configurer et gérer ce fichier, reportez–vous à la
description de la commande chnfsdom dans le manuel AIX 5L Version 5.3 Commands
Reference, Volume 1.
Fichier /etc/nfs/realm.map
Ce fichier est utilisé par le démon NFS registry pour mapper des principaux Kerberos
entrants name@kerberos–realm en principaux name@nfs–domain. Cela permet ensuite de
résoudre le principal name@nfs–domain sous la forme de données d’identification UNIX
locales. Ce fichier est un moyen pratique pour mapper des principaux Kerberos dans le
registre utilisateur du serveur. Envisagez cette solution lorsque des clients de différentes
partitions Kerberos auront accès au serveur, mais que l’espace nom utilisateur est global.
Ce fichier doit contenir des lignes au format suivant :
realm1
realm2
nfs–domain
nfs–domain
Système de fichiers NFS
6-11
pour l’ensemble des partitions Kerberos gérées par le serveur. Si le nom de la partition
Kerberos est systématiquement le même que celui du domaine NFS du serveur, ce fichier
est inutile. Si vous souhaitez tirer parti des fonctions plus générales de mappage entre
userA@kerberos–realm et userB@nfs–domain, utilisez le service EIM (Enterprise Identity
Mapping). Pour plus d’informations, reportez–vous à la section Mappage d’identité
page 6-18.
Pour ajouter, modifier ou supprimer des entrées dans ce fichier, servez–vous de la
commande chnfsrtd. Pour plus d’informations, reportez–vous à la description de la
commande chnfsrtd dans le manuel AIX 5L Version 5.3 Commands Reference, Volume 1.
Fichier /etc/nfs/princmap
Ce fichier permet de mapper les noms d’hôte aux principaux Kerberos lorsque le principal
n’est pas le nom de domaine complet du serveur. Il est constitué de plusieurs lignes sous le
format suivant :
<partie hôte du principal> alias1 alias2 ...
Pour ajouter, modifier ou supprimer des entrées dans ce fichier, servez–vous de la
commande nfshostmap. Pour plus d’informations, reportez–vous à la description de la
commande nfshostmap dans le manuel AIX 5L Version 5.3 Commands Reference,
Volume 4.
Fichier /etc/nfs/security_default
Le fichier /etc/nfs/security_default contient la liste des types de sécurité susceptibles
d’être utilisés par le client NFS, dans l’ordre approprié. Pour gérer ce fichier, servez–vous
de la commande chnfssec. Pour plus d’informations, reportez–vous à la description de la
commande chnfssec dans le manuel AIX 5L Version 5.3 Commands Reference, Volume 1.
Implémentation de NFS
NFS est implémenté sur nombre de types de machines, de systèmes d’exploitation et
d’architectures réseau. Cette autonomie lui est conférée par le protocole RPC
(Remote Procedure Call).
Protocole RPC (Remote Procedure Call)
RPC est une bibliothèque de procédures. Ces procédures permettent à un processus
(client) de commander à un autre (processus serveur) l’exécution d’appels de procédures,
comme s’il les exécutait dans son propre espace d’adressage. Les processus client et
serveur étant distincts, ils n’ont pas besoin de résider sur le même système (bien qu’ils le
puissent).
NFS est implémenté comme un ensemble d’appels RPC, le serveur prenant en charge
certains types d’appels client. Le client lance ces appels sur la base des opérations sur
systèmes de fichiers effectuées par le processus client. En ce sens, NFS est une
application RPC.
Les processus serveur et client pouvant résider sur des systèmes d’architectures
complètement différentes, RPC doit prendre en compte le fait que les données ne sont
peut–être pas représentées de la même manière des deux côtés. D’où son adoption du
protocole de représentation XDR (eXternal Data Representation).
Protocole XDR (eXternal Data Representation)
XDR est une spécification assurant une représentation standard de différents types de
données. Un programme utilisant cette norme ne risque pas de mal interpréter des
données, même provenant d’un système doté d’une architecture totalement différente.
Dans la pratique, la plupart des programmes n’utilisent pas XDR en interne. Ils adoptent
plutôt la représentation propre à l’architecture du système concerné. Lorsque le programme
doit communiquer avec un autre, il convertit ses données au format XDR avant de les
envoyer. De même, lorsqu’il reçoit des données, il les convertit du format XDR dans sa
propre représentation de données.
6-12
Guide de gestion du système – Communications et réseaux
Démon portmap
Chaque application RPC est associée avec un numéro de programme et un numéro de
version. Ces numéros servent à communiquer avec une application serveur sur un
système. Lorsqu’il effectue une demande à partir d’un serveur, le client doit connaître le
numéro du port sur lequel le serveur reçoit les demandes. Ce numéro de port est associé
au protocole UDP (User Datagram Protocol) ou TCP (Transmission Control Protocol) utilisé
par le service. Le client connaît le numéro du programme, le numéro de version et le nom
du système (ou celui de l’hôte sur lequel réside le service). Le client doit pouvoir faire
correspondre la paire numéro de programme/numéro de version au numéro de port de
l’application serveur. Cette opération est effectuée à l’aide du démon portmap.
Le démon portmap est exécuté sur le même système que l’application NFS. Lorsque le
serveur la lance, il l’enregistre avec portmap. Par le biais de cet enregistrement, il fournit
son numéro de programme, son numéro de version et son numéro de port UDP ou TCP.
Le démon portmap maintient une table des applications serveur. Lorsque le client émet une
demande vis-à-vis du serveur, il contacte d’abord le démon portmap pour connaître le port
utilisé par le serveur. Le démon portmap répond au client en lui indiquant le port en
question. Le client est alors à même d’émettre ses demandes directement à l’application
serveur.
Contrôle de NFS
Les démons NFS, NIS et NIS+ sont surveillés par le contrôleur SRC (System Resource
Controller). Cela signifie que vous devez utiliser les commandes telles que startsrc,
stopsrc et lssrc pour lancer, arrêter et vérifier l’état des démons NFS, NIS et NIS+.
Certains démons NFS ne sont pas contrôlés par SRC, à savoir : rpc.rexd, rpc.rusersd,
rpc.rwalld et rpc.rsprayd. Ils sont lancés et arrêtés par le démon inetd.
Le tableau suivant répertorie les démons et sous-systèmes contrôlés par SRC.
Démons et sous–systèmes associés
Chemin d’accès au fichier
Nom du
sous–système
Nom du
groupe
/usr/sbin/nfsd
nfsd
nfs
/usr/sbin/biod
biod
nfs
/usr/sbin/rpc.lockd
rpc.lockd
nfs
/usr/sbin/rpc.statd
rpc.statd
nfs
/usr/sbin/rpc.mountd
rpc.mountd
nfs
/usr/sbin/nfsrgyd
nfsrgyd
nfs
/usr/sbin/gssd
gssd
nfs
/usr/lib/netsvc/yp/ypserv
ypserv
yp
/usr/lib/netsvc/yp/ypbind
ypbind
yp
/usr/lib/netsvc/rpc.yppasswdd
yppasswdd
yp
/usr/lib/netsvc/rpc.ypupdated
ypupdated
yp
/usr/sbin/keyserv
keyserv
keyserv
/usr/sbin/portmap
portmap
portmap
Les démons NIS+ sont décrits dans le manuel AIX 5L Version 5.3 Network Information
Services (NIS and NIS+) Guide. Chacun de ces démons peut être défini dans les
commandes SRC à l’aide de leur nom de sous–système ou de leur nom de groupe
approprié. Aucun de ces démons ne prend en charge la liste des fonctions, ni les
commandes de suivi SRC.
Système de fichiers NFS
6-13
Pour plus d’informations sur l’utilisation du SRC, reportez–vous à la section de présentation
du contrôleur SRC (System Resource Controller) dans le manuel AIX 5L Version 5.3
System Management Concepts: Operating System and Devices.
Modification du nombre de démons biod et nfsd
La commande chnfs permet de changer le nombre maximum de démons biod ou nfsd
exécutables sur un système. Ainsi, pour limiter à 1000 le nombre de démons nfsd, et à 4 le
nombre de démons biod, entrez :
chnfs –n 1000 –b 4
Remarque :
Cette commande permet d’arrêter les démons en cours d’exécution, de
mettre à jour les informations de configuration SRC, puis de redémarrer les
démons. Le service NFS ne sera temporairement plus disponible.
Il est possible également de spécifier le nombre maximum de démons biod par montage en
utilisant l’option de montage biods= n.
Modification des arguments des démons contrôlés par SRC
Nombre de démons NFS, NIS et NIS+ peuvent être assortis d’arguments, sur la ligne de
commande, spécifiés une fois le démon activé. Ces démons n’étant pas eux-mêmes activés
directement via la ligne de commande, vous devez mettre à jour la base de données SRC
pour que les démons puissent être correctement activés. Pour ce faire, lancez la
commande chssys. La commande chssys a le format :
chssys –s Daemon –a ’NewParameter’
Par exemple :
chssys –s nfsd –a ’10’
modifie le sous-système nfsd de sorte que, à l’activation du démon, la ligne de commande
soit semblable à nfsd 10. La modification induite par la commande chssys ne prend effet
qu’une fois le sous-système arrêté puis relancé.
Lancement des démons NFS
La taille maximale des fichiers situés sur un serveur NFS est définie par l’environnement
du processus au démarrage de nfsd. Pour utiliser une valeur spécifique, éditez le fichier
/etc/rc.nfs. Exécutez la commande ulimit en précisant la limite désirée avant d’exécuter
la commande startsrc pour nfsd.
Les démons NFS peuvent être lancés individuellement ou tous à la fois. Pour les lancer
individuellement, exécutez :
startsrc –s
Démon
Démon étant l’un des démons contrôlés par SRC. Ainsi, pour lancer les démons nfsd,
exécutez :
startsrc –s nfsd
Pour les lancer tous simultanément, exécutez :
startsrc –g nfs
Remarque :
Si le fichier /etc/exports n’existe pas, les démons nfsd et rpc.mountd ne
sont pas lancés. Vous pouvez créer un fichier /etc/exports vide via la
commande touch /etc/exports : les démons nfsd et rpc.mountd seront
lancés, mais aucun système de fichiers ne sera exporté.
Arrêt des démons NFS
Les démons NFS peuvent être arrêtés individuellement ou tous à la fois.
Pour les arrêter individuellement, exécutez :
stopsrc –s
6-14
Démon
Guide de gestion du système – Communications et réseaux
Démon étant l’un des démons contrôlés par SRC. Ainsi, pour arrêter rpc.lockd, exécutez :
stopsrc –s rpc.lockd
Pour les arrêter tous simultanément, exécutez :
stopsrc –g nfs
Etat des démons NFS
Vous pouvez afficher l’état de démons NFS spécifiques ou de tous les démons à la fois.
Pour afficher l’état d’un démon, exécutez :
lssrc –s
Démon
Démon étant l’un des démons contrôlés par SRC. Ainsi, pour obtenir l’état de rpc.lockd,
exécutez :
lssrc –s rpc.lockd
Pour obtenir simultanément l’état de tous les démons NFS, exécutez :
lssrc –a
Prise en charge de NFS version 4
La prise en charge des fonctions du protocole NFS version 4 est assurée à partir de
AIX 5.3. Les fonctions essentielles du protocole sont gérées conformément aux
spécifications RFC 3530 à l’exception des fonctions suivantes :
• Les mécanismes de sécurité LIPKEY et SPKM–3 ne sont pas compatibles avec
l’authentification RPC RPCSEC–GSS. Seul le mécanisme Kerberos V5 est géré.
• Les spécifications UTF–8 ne sont pas entièrement prises en charge. De façon plus
précise, il n’est pas garanti que la transmission des noms de fichier et des chaînes du
système de fichiers (comme, par exemple, le contenu d’un lien symbolique et les noms
des entrées de répertoire) se fasse au format UTF–8. La transmission des chaînes
d’attribut NFS, telles que le propriétaire et le groupe de propriétaires, est
systématiquement au format UTF–8. Le serveur et le client NFS procèdent à la
validation UTF–8 des données de chaînes entrantes conformément à la définition
RFC 3530. Il est possible de désactiver cette fonction de contrôle au moyen de la
commande nfso. Il peut être utile de désactiver la validation UTF–8 afin d’utiliser le
protocole NFS version 4 dans des environnements contenant des configurations et
des données non UTF–8.
• Le client sans disque, NIM et UDP ne sont pas compatibles avec le protocole NFS
version 4.
Les fonctions facultatives suivantes du protocole NFS version 4 sont prises en charge :
• Les listes de contrôle d’accès (ACL) NFS version 4 sont gérées aussi bien par le client
NFS que par le serveur NFS. Le client NFS assure l’administration des listes de contrôle
d’accès NFS version 4 à l’aide des utilitaires acledit, aclget et aclput. Le serveur NFS
est capable de stocker et d’extraire les listes de contrôle d’accès NFS version 4 dans
les systèmes de fichiers sous–jacents compatibles avec le modèle ACL NFS version 4.
Pour plus d’informations, reportez–vous à la section Liste de contrôle d’accès (ACL)
sous NFS page 6-3.
• La prise en charge permet de mapper des principaux et des attributs de propriété de
fichier d’un domaine NFS version 4 à un autre. Elle est destinée principalement aux
serveurs AIX NFS. Il est nécessaire, pour cela, de procéder au déploiement de LDAP.
Les mappages NFS sont gérés au moyen de l’utilitaire chnfsim.
Plusieurs considérations sont à prendre en compte pour autoriser un accès simultané avec
NFS versions 2 et 3 et avec NFS version 4. L’accès NFS version 3 peut recevoir des erreurs
en raison de l’état accordé NFS version 4. De même, l’exportation des données pour
l’accès NFS version 4 peut avoir une incidence sur les performances de NFS version 3.
Système de fichiers NFS
6-15
Installation et configuration de NFS
Pour plus d’informations sur ce type d’installation, reportez–vous au manuel AIX 5L
Version 5.3 – Références et guide d’installation.
Etapes de configuration de NFS
Une fois le logiciel NFS installé sur vos systèmes, il faut le configurer. Voici l’ensemble des
étapes qu’il convient de réaliser pour configurer NFS. Chacune de ces étapes est décrite de
façon détaillée à la suite.
1. Déterminez les systèmes du réseau qui seront serveurs, et ceux qui seront clients (un
système peut être à la fois serveur et client).
2. Déterminez la version de NFS que vous allez utiliser.
3. Décidez s’il est nécessaire ou non de recourir à la fonction de sécurité RPCSEC–GSS.
Le cas échéant, tenez compte des considérations exposées dans la section
Configuration d’un réseau pour RPCSEC–GSS, page 6-19.
4. Pour chaque système (client ou serveur), suivez les instructions indiquées à la section
Lancement des démons NFS au démarrage du système, page 6-16.
5. Pour chaque serveur NFS, suivez les instructions indiquées à la section Configuration
d’un serveur NFS, page 6-16.
6. Pour chaque client NFS, suivez les instructions indiquées à la section Configuration d’un
client NFS, page 6-17.
7. Si vous souhaitez donner aux PC du réseau accès aux serveurs NFS (outre leur
capacité à monter des systèmes de fichiers), configurez PC-NFS comme indiqué à la
section PC-NFS, page 6-32.
8. Si vous avez prévu d’utiliser NFS version 4, tenez compte des considérations exposées
à la section Prise en charge de NFS version 4, page 6-15.
Lancement des démons NFS au démarrage du système
Par défaut, les démons NFS ne sont pas activés au cours de l’installation. Celle-ci achevée,
tous les fichiers sont placés sur le système, mais les étapes d’activation de NFS ne sont
pas effectuées. Vous pouvez lancer les démons NFS au démarrage du système via :
• Web–based System Manager, wsm
• le raccourci SMIT, smit mknfs
• la commande mknfs
Quelle que soit la méthode choisie, une entrée est intégrée au fichier inittab de façon que
le script /etc/rc.nfs soit exécuté à chaque redémarrage du système. A son tour, ce script
lance tous les démons requis par un système donné.
Configuration d’un serveur NFS
Procédez comme suit :
1. Créez le fichier /etc/exports. Reportez–vous au fichier /etc/exports, page 6-10
2. Si vous utilisez Kerberos, configurez le serveur NFS comme un client Kerberos.
Reportez–vous à Configuration d’un réseau pour RPCSEC–GSS, page 6-19.
3. Si vous utilisez NFS version 4, établissez le domaine NFS version 4 au moyen de la
commande chnfsdom. Pour plus d’informations, reportez–vous à la description de la
commande chnfsdom dans le manuel AIX 5L Version 5.3 Commands Reference.
Vous avez la possibilité, au départ, de spécifier le domaine Internet du serveur dans le
fichier. Vous pouvez, cependant, définir un domaine NFS version 4 différent du domaine
6-16
Guide de gestion du système – Communications et réseaux
Internet du serveur. Pour en savoir plus à ce sujet, reportez–vous à la section relative au
démon NFS registry, nfsrgyd dans le manuel AIX 5L Version 5.3 Commands
Reference, Volume 4.
4. Si vous utilisez NFS version 4 avec Kerberos, vous devrez éventuellement créer le
fichier /etc/nfs/realm.map. Reportez–vous au fichier /etc/nfs/realm.map, page 6-11.
5. Si vous souhaitez appliquer l’authentification Kerberos au serveur, vous devez activer la
fonction de sécurité évoluée sur le serveur. Vous pouvez le faire via SMIT ou en utilisant
la commande chnfs –S –B. Pour plus d’informations au sujet de la commande chnfs,
reportez–vous à la description de la commande chnfs dans le manuel AIX 5L
Version 5.3 Commands Reference, Volume 1.
Configuration d’un client NFS
1. Lancez NFS comme indiqué à la section Lancement des démons NFS, page6-14.
2. Définissez le point de montage local par la commande mkdir. La réussite d’un montage
NFS suppose la présence d’un répertoire servant de point de montage. Ce répertoire
doit être vide. La création de ce point de montage ne diffère en rien de celle de n’importe
quel répertoire, et aucun attribut particulier ne doit être spécifié.
Remarque :
Les points de montage doivent exister préalablement à tout montage à
une exception près : si vous utilisez le démon automount, il n’est pas
nécessaire de créer des points de montage. Pour plus d’informations,
reportez–vous à la description du démon automount dans le manuel
AIX 5L Version 5.3 Commands Reference, Volume 1.
3. Si vous utilisez Kerberos, procédez comme suit :
a. Configurez le client NFS au sein d’une partition Kerberos. Faites appel pour cela
à la commande config.krb5.
b. Créez des principaux Kerberos pour tous les utilisateurs du client prévoyant
d’accéder aux fichiers via des montages Kerberos. Faites appel pour cela à la
commande kadmin.
c. L’établissement d’un principal Kerberos pour la machine client elle–même est
facultatif. On appelle client léger un client pour lequel aucun principal n’a été défini et
client lourd un client doté d’un principal. Les clients légers ont recours à une sécurité
NFS RPC moins puissante lorsqu’ils effectuent certaines opérations de gestion de
contexte client–serveur sous NFS version 4 dans le cadre de l’administration d’état.
Un client lourd, dépendant de la configuration, peut bénéficier d’une sécurité RPC de
type Kerberos plus performante. Les configurations des clients légers monopolisent
moins de ressources administratives et peuvent être suffisantes dans de nombreux
environnements. Pour les déploiements exigeant des niveaux de sécurité extrêmes,
il est généralement préférable d’opter pour des configurations de client lourd.
4. Si vous utilisez NFS version 4, vous devez également établir le domaine NFS version 4
au moyen de la commande chnfsdom. Vous avez la possibilité, au départ, de spécifier
le domaine Internet du client dans le fichier. Vous pouvez, cependant, définir un domaine
NFS version 4 différent du domaine Internet du client. Pour en savoir plus à ce sujet,
reportez–vous à la documentation relative au démon NFS registry nfsrgyd.
5. Si vous souhaitez appliquer l’authentification Kerberos au client, vous devez activer la
fonction de sécurité évoluée sur le client. Vous pouvez le faire via SMIT ou en utilisant la
commande chnfs –S –B. Pour plus d’informations sur chnfs, reportez–vous à la page
de référence de la commande chnfs.
6. Etablissez les montages prédéfinis comme indiqué à la section Etablissement de
montages NFS prédéfinis, page 6-27.
Système de fichiers NFS
6-17
Mappage d’identité
Le mappage d’identité est une méthode utilisée par le serveur et le client local NFS pour
traduire des utilisateurs et des groupes étrangers en utilisateurs et groupes locaux. AIX
utilise la technologie EIM, laquelle est basée sur LDAP, pour procéder au mappage
d’identité. Toutes les données de mappage d’identité NFS sont stockées sur un serveur
LDAP.
Pour configurer un client EIM, les ensembles de fichiers bos.eim.rte et ldap.client doivent
être installés. Le serveur EIM a besoin également de l’ensemble de fichiers ldap.server.
Après avoir installé les ensembles de fichiers appropriés, servez–vous de
/usr/sbin/chnfsim pour configurer EIM. Les options de configuration minimum sont les
suivantes :
/usr/sbin/chnfsim –c –h [serveur EIM] –e [domaine LDAP/EIM] –f [suffixe
LDAP] –w [mot de passe administrateur]
Cela permet de configurer à la fois les clients et les serveurs EIM afin d’utiliser un serveur
EIM spécifique pour le mappage d’identité. Si le nom d’hôte spécifié dans la commande
correspond au nom d’hôte local, un serveur LDAP est également configuré.
Une fois la phase de configuration terminée, l’administrateur EIM peut renseigner le serveur
LDAP en fonction des données de mappage d’identité NFS. Un utilisateur ou un groupe
individuel, tel que Jean Dupont, est connu sous le nom d’identité de mappage. La chaîne du
propriétaire NFS de cet utilisateur, [email protected], est appelée un mappage
d’identité. Pour entrer ces données sur le serveur LDAP, voici l’instruction à exécuter :
/usr/sbin/chnfsim –a –u –i ”Jean Dupont” –n jeandupont –d austin.ibm.com
L’identité de mappage est le nom descriptif de l’utilisateur ou du groupe alors que le
mappage d’identité correspond à la chaîne du propriétaire NFS nom@domaine. Les
mappages entre les partitions et les domaines sont aussi stockés sur le serveur LDAP. Pour
établir une correspondance entre la partition Kerberos kerb.austin.ibm.com et le
domaine NFS austin.ibm.com, voici l’instruction qu’il convient d’exécuter :
/usr/sbin/chnfsim –a –r kerb.austin.ibm.com –d austin.ibm.com
Pour configurer NFS de façon à utiliser les données de mappage dans EIM, il faut
redémarrer le démon NFS registry. Celui–ci vérifie si un serveur EIM est disponible au
démarrage, et le cas échéant, toutes les fonctions de mappage passent par EIM et tous les
mappages locaux sont ignorés.
Pour plus d’informations sur EIM, reportez–vous à la section EIM (Entreprise Identity
Mapping) dans le manuel AIX 5L Version 5.3 – Guide de sécurité.
Exportation d’un système de fichiers NFS
Vous pouvez exporter un système de fichiers NFS via l’application réseau Web–based
System Manager, ou en utilisant l’une des procédures suivantes.
• Via SMIT :
1. Vérifiez que NFS est actif en entrant la commande lssrc –g nfs. La sortie doit
indiquer que les démons nfsd et rpc.mountd sont actifs. Dans la négative, lancez
NFS comme indiqué à la section Lancement des démons NFS page 6-14.
2. Sur la ligne de commande, tapez l’instruction suivante et appuyez sur Entrée :
smit mknfsexp
3. Renseignez les zones Chemin d’accès du répertoire à exporter, Mode d’accès
au répertoire exporté et Export répert maintenant, init-syst. ou les deux.
4. Modifiez les autres caractéristiques ou acceptez les valeurs par défaut.
5. Vos changements terminés, SMIT met à jour le fichier /etc/exports. Si le fichier
/etc/exports n’existe pas, il est créé.
6. Répétez les étapes 3 à 5 pour chaque répertoire à exporter.
6-18
Guide de gestion du système – Communications et réseaux
• Pour exporter un système de fichiers NFS via un éditeur :
1. Ouvrez le fichier /etc/exports avec votre éditeur favori.
2. Créez une entrée pour chaque répertoire à exporter, en indiquant son chemin d’accès
complet. Répertoriez tous les répertoires à exporter en commençant à la marge
gauche. Ne spécifiez pas de répertoire qui en contient un autre déjà exporté. Pour en
savoir plus sur la syntaxe des entrées dans le fichier /etc/exports, reportez-vous à la
documentation du fichier /etc/exports.
3. Sauvegardez et fermez le fichier /etc/exports.
4. Si NFS est en cours d’exécution, tapez la commande suivante et appuyez sur
Entrée:
/usr/sbin/exportfs –a
–a indique à la commande exportfs d’envoyer au noyau toutes les informations
du fichier /etc/exports. Si NFS n’est pas actif, lancez-le comme indiqué à la section
Lancement des démons NFS page 6-14.
• Pour exporter temporairement un système de fichiers NFS (sans changer le fichier
/etc/exports), tapez la commande suivante et appuyez sur Entrée :
exportfs –i /dirname
où dirname est le nom du système de fichiers que vous souhaitez exporter. La
commande exportfs –i spécifie de ne pas rechercher le répertoire dans le fichier
/etc/exports, et que toutes les options sont directement issues de la ligne de
commande.
La prise en charge AIX NFS version 4 permet à l’administrateur de créer et de gérer un
autre espace nom présenté par le serveur NFS sur les clients. il est nécessaire pour cela
d’utiliser l’option d’exportation exname. Cette prise en charge peut également servir à
masquer les détails de l’espace nom du système de fichiers local sur le serveur à partir
des clients NFS. Pour plus d’informations, reportez–vous à la description de la
commande exportfs dans le manuel AIX 5L Version 5.3 Commands Reference,
Volume 2 et à la description du fichier /etc/exports dans le manuel AIX 5L Version 5.3
Files Reference.
Configuration d’un réseau pour RPCSEC–GSS
Cette section décrit un scénario relatif à la configuration d’un réseau pour RPCSEC–GSS.
Le réseau compte cinq serveurs :
• kdc.austin.ibm.com
• alpha.austin.ibm.com
• beta.austin.ibm.com
• gamma.austin.ibm.com
• zeta.austin.ibm.com
Le système kdc.austin.ibm.com sera configuré comme serveur KDC (Key Distribution
Center) et la partition Kerberos AUSTIN.IBM.COM sera réservée à tous les systèmes (à
l’exception de kdc.austin.ibm.com et zeta.austin.ibm.com ) qui feront office de
serveurs NFS pour les systèmes de fichiers exportés avec RPCSEC–GSS.
Les systèmes alpha.austin.ibm.com et beta.austin.ibm.com possèdent un lien
supplémentaire entre eux. Grâce à ce lien, ils se présentent l’un à l’autre comme
fast_alpha.test.austin.com et fast_beta.test.austin.ibm.com. C’est la
raison pour laquelle une étape de configuration supplémentaire sera nécessaire.
Système de fichiers NFS
6-19
Ce réseau compte en outre les utilisateurs suivants :
• adam
• brian
• charlie
• dave
• eric
lesquels ont été configurés sur certains des systèmes.
Remarque :
La configuration ci–dessous est proposée uniquement à titre d’exemple et
risque de ne pas convenir à tous les environnements. Avant d’essayer de
configurer une nouvelle partition Kerberos, veuillez consulter le manuel
Administrator’s and User’s Guide pour le service d’authentification réseau.
Remarque :
Kerberos ne tolère que des écarts d’heure système peu importants à
l’échelle du réseau. Avant de lancer cette procédure, il est donc
indispensable de prévoir un mécanisme de synchronisation automatique
des heures sur tout le réseau, en ayant recours, par exemple, au démon
AIX timed ou à une configuration NTP.
Etape 1.
Configurez le serveur KDC.
Remarque :
Dans l’idéal, il vaut mieux éviter d’utiliser le serveur KDC dans tout
autre but ; en effet, si les données du serveur KDC venaient à être
compromises, tous les principaux Kerberos le seraient également.
Dans ce scénario, kdc.austin.ibm.com sera configuré en tant que serveur KDC.
La configuration suivante s’applique à des3. If si vous préférez utilisez des pour des
raisons de performance, ajoutez l’argument –e des–cbc–crc:normal aux appels
addprinc et ktadd pour kadmin ci–dessous.
a. Installez l’ensemble de fichiers krb5.server.rte sur kdc.austin.ibm.com.
b. Configurez le serveur KDC. Dans ce scénario, la commande suivante a été
employée :
config.krb5 –S –d austin.ibm.com –r AUSTIN.IBM.COM
Après l’exécution de cette commande, le système vous demande un mot de passe
d’accès à la base de données principale et un mot de passe d’accès au principal
d’administration.
c. Créez des principaux pour chaque utilisateur et chaque hôte en exécutant la
commande /usr/krb5/sbin/kadmin.local sur le serveur KDC. Cet exemple permet
de générer des principaux Kerberos correspondant au nom d’utilisateur UNIX de
l’utilisateur associé. Le nom du principal sera mappé au nom d’utilisateur par NFS
pour déterminer les données d’identification UNIX associées au principal. Pour
savoir comment établir un plus grand nombre de correspondances générales entre
des principaux et des noms d’utilisateur, reportez–vous à la section Mappage
d’identité page 6-18. Dans le cadre de ce réseau, nous avons défini les principaux
suivants :
– adam
– brian
– charlie
– dave
– eric
– nfs/alpha.austin.ibm.com
– nfs/beta.austin.ibm.com
– nfs/gamma.austin.ibm.com
6-20
Guide de gestion du système – Communications et réseaux
Remarque :
Etape 2.
Les noms des principaux utilisateur choisis doivent être identiques
aux noms d’utilisateur correspondants dans le registre utilisateur
configuré du système (/etc/passwd, LDAP, NIS, et ainsi de suite).
NFS utilise le nom de principal en tant que nom d’utilisateur afin
d’obtenir les ID d’utilisateur et de groupe sur le système local. Si
les noms ne correspondent pas, l’accès sera traité comme un
accès anonyme. Le serveur KDC est maintenant configuré.
Nous allons, à présent, configurer chaque client et serveur NFS en tant que
clients Kerberos au moyen de la commande config.krb5. La méthode
utilisée dépend de la façon dont KDC a été configuré. Dans ce scénario,
l’instruction suivante a été exécutée sur chaque système NFS :
config.krb5 –C –d austin.ibm.com –r AUSTIN.IBM.COM –c
kdc.austin.ibm.com –s kdc.austin.ibm.com
Il est maintenant possible d’appliquer la commande kinit pour tout principal utilisateur
sur tous les systèmes configurés. Pour utiliser, par exemple, la commande kinit
comme utilisateur adam, exécutez l’instruction suivante :
/usr/krb5/bin/kinit adam
Il faudra spécifier le mot de passe Kerberos d’adam et non le mot de passe AIX.
Cet exemple a recours à kinit pour authentifier l’utilisateur. Vous avez la possibilité
de configurer AIX pour utiliser l’authentification Kerberos lors de la connexion au
système. Pour plus d’informations, reportez–vous à la section Authentification à AIX
à l’aide de Kerberos dans le manuel AIX 5L Version 5.3 – Guide de sécurité.
Etape 3.
Nous avons prévu de configurer chaque serveur NFS en fonction de
l’entrée keytab appropriée. Dans ce scénario, nous avons choisi de
configurer l’entrée keytab pour alpha.austin.ibm.com à titre
d’exemple. Nous procéderons exactement de la même manière pour
beta.austin.ibm.com et gamma.austin.ibm.com.
a. A partir de alpha.austin.ibm.com, exécutez la commande kadmin.
Exécutez ensuite l’instruction suivante :
ktadd nfs/alpha.austin.ibm.com
Cela a pour effet de créer le fichier keytab.
b. Configurez ensuite le démon gssd de façon à utiliser le fichier keytab que vous
venez de créer avec la commande nfshostkey. Dans ce scénario, nous avons
exécuté l’instruction suivante :
nfshostkey –p nfs/alpha.austin.ibm.com –f /etc/krb5/krb5.keytab
c. Configurez le démon gssd pour qu’il démarre automatiquement en exécutant la
commande suivante :
chnfs –S –B
Répétez cette procédure pour chaque système.
Etape 4.
A ce stade, le serveur NFS est en état de fonctionner, même si tous les
utilisateurs seront considérés comme inconnus (nobody). Il faut faire en
sorte que l’ensemble des utilisateurs soient reconnus sur tous les serveurs
avec le même ID utilisateur (UID) et le même ID groupe (GID). Ceux qui
n’existent pas auront accès au répertoire exporté uniquement en tant
qu’utilisateurs nobody. Pour vous assurer que les noms d’utilisateur sont
mappés correctement, vous devez configurer le démon NFS registry.
a. Configurez le domaine au moyen de la commande chnfsdom . Dans ce scénario,
la commande suivante a été exécutée sur tous les serveurs NFS afin de configurer
austin.ibm.com comme domaine :
chnfsdom austin.ibm.com
Système de fichiers NFS
6-21
b. Configurez le fichier /etc/nfs/realm.map. Celui–ci doit contenir une ligne en
veillant à ce que le nom de la partition soit suivie du domaine local. Dans le cadre
de notre exemple de réseau, ces deux fichiers doivent être similaires à ceci sur
tous les serveurs NFS :
realm.map AUSTIN.IBM.CO