Cette partie aborde les tâches et les informations conceptuelles relatives à la configuration, à l'administration et au dépannage de réseaux TCP/IP.
Ce chapitre décrit les problèmes à résoudre pour créer un réseau de façon méthodique et économique. Une fois ces problèmes résolus, vous pouvez concevoir un plan de réseau lors de la configuration et de l'administration du réseau.
Le présent chapitre contient les informations suivantes :
Les tâches de configuration d'un réseau sont décrites au Chapitre 5Configuration des services réseau TCP/IP et de l'adressage IPv4 (tâches).
Le tableau suivant répertorie les différentes tâches permettant de configurer le réseau. Le tableau comprend la description des actions de chaque tâche et la section de la documentation actuelle dans laquelle les étapes permettant d'effectuer ces tâches sont décrites en détails.
Tâche |
Description |
Référence |
---|---|---|
1. Planification du matériel requis et de la topologie réseau |
Déterminez les types d'équipements nécessaires ainsi que la disposition de ces équipements sur le site. |
|
2. Obtention d'une adresse IP enregistrée pour le réseau |
Le réseau doit posséder une adresse IP unique si les communications doivent s'effectuer hors du réseau local, via Internet par exemple. |
Reportez-vous à la section Obtention du numéro IP du réseau. |
3. Élaboration d'un schéma d'adressage IP pour les systèmes, en fonction du préfixe de réseau IPv4 ou du préfixe de site IPv6 |
Déterminez la méthode de déploiement des adresses sur le site. |
Reportez-vous à la section Conception d'un schéma d'adressage IPv4 ou à la section Préparation d'un plan d'adressage IPv6. |
4. Création d'une liste contenant les adresses IP et noms d'hôtes de toutes les machines du réseau |
Utilisez cette liste pour créer les bases de données réseau. |
Reportez-vous à la section Bases de données réseau |
5. Détermination du service de noms à utiliser sur le réseau |
Choisissez le service de noms NIS, LDAP, DNS ou les bases de données réseau dans le répertoire /etc local. |
Reportez-vous à la section Sélection d'un service de noms et d'un service d'annuaire |
6. Établissement des sous-divisions administratives, le cas échéant (selon le réseau) |
Décidez si le site requiert une division du réseau en sous-divisions administratives. |
Reportez-vous à la section Sous-divisions administratives |
7. Détermination de l'emplacement auquel positionner les routeurs dans le réseau |
Si le réseau est étendu et, par conséquent, requiert des routeurs, créez une topologie réseau prenant en charge ces derniers. |
Reportez-vous à la section Planification des routeurs du réseau |
8. Élaboration d'une stratégie pour les sous-réseaux, le cas échéant |
Vous aurez peut-être besoin de créer des sous-réseaux pour administrer l'espace d'adressage IP ou pour mettre des adresses IP supplémentaires à la disposition des utilisateurs. |
Pour la planification de sous-réseau IPv4, reportez-vous à la section Qu'est-ce que la création de sous-réseaux ? Pour la planification de sous-réseau IPv6, reportez-vous à la section Création d'un schéma de numérotation pour les sous-réseaux |
Lors de la conception du réseau, vous devez choisir le type de réseau le plus adapté aux besoins de votre organisation. Les décisions à prendre dans le cadre de la planification impliquent le matériel réseau. Vous devez déterminer :
la topologie réseau, la disposition et les connexions du matériel réseau ;
le nombre de systèmes hôte que le réseau peut prendre en charge ;
les types d'hôtes pris en charge par le réseau ;
les types de serveurs requis ;
le type de média réseau à utiliser : Ethernet, Token Ring, FDDI, etc. ;
si des ponts ou routeurs doivent étendre ce média ou connecter le réseau local à des réseaux externes ;
si des systèmes requièrent des interfaces acquises séparément, outre leurs interfaces intégrées.
En fonction de ces facteurs, vous pouvez définir la taille du réseau local.
Ce manuel n'a pas pour objectif de décrire la planification du matériel réseau. Pour obtenir de l'assistance, reportez-vous aux manuels accompagnant le matériel.
La configuration du réseau dépend du nombre de systèmes à prendre en charge. Votre organisation peut avoir besoin d'un petit réseau de plusieurs douzaines de systèmes autonomes résidant dans un même bâtiment et au même étage. Vous pouvez aussi configurer un réseau comprenant plus de 1 000 systèmes situés dans différents bâtiments. Cette configuration requiert une division supplémentaire du réseau en sous-divisions appelées sous-réseaux.
Lors de la planification du schéma d'adressage du réseau, tenez compte des facteurs suivants :
le type d'adresse IP à employer : IPv4 ou IPv6
le nombre de systèmes potentiels sur le réseau ;
le nombre de systèmes multiréseau ou routeurs, qui requièrent une adresse IP pour chaque interface ;
si des adresses privées doivent être utilisées sur le réseau ;
si les pools d'adresses IPv4 doivent être gérés par un serveur DHCP.
En raison de la croissance mondiale d'Internet depuis 1990, les adresses IP disponibles s'épuisent. Pour y remédier, l'IETF (Internet Engineering Task Force, groupe d'étude d'ingénierie Internet) a développé un certain nombre de méthodes alternatives d'adressage IP. Les types d'adresses IP suivants sont actuellement utilisés :
Si plusieurs adresses IP ont été attribuées à votre organisation pour le réseau ou si des sous-réseaux sont utilisés, désignez une autorité centrale au sein de votre organisation comme responsable de l'attribution des adresses réseau IP. Cette autorité doit assurer le contrôle d'un pool d'adresses IP réseau attribuées et allouer des adresses aux hôtes, réseaux et sous-réseaux, le cas échéant. Pour éviter tout problème, assurez-vous qu'il n'existe aucun numéro de réseau aléatoire ou dupliqué dans l'organisation.
Ces adresses 32 bits correspondent au format d'adressage IP initialement conçu pour TCP/IP. À l'origine, les réseaux IP se décomposent en trois classes, A, B et C. Le numéro de réseau attribué à un réseau reflète cette identification de classe, tandis que les 8 bits ou plus supplémentaires représentent un hôte. Les adresses IPv4 basées sur les classes requièrent la configuration d'un masque de réseau pour le numéro de réseau. En outre, ces adresses étaient souvent divisées en sous-réseaux afin d'augmenter le nombre d'adresses disponibles pour les systèmes du réseau local.
Aujourd'hui, les adresses IP sont appelées adresses IPv4. Il est désormais impossible d'obtenir des numéros de réseau IPv4 basés sur les classes auprès d'un fournisseur de services Internet, mais de nombreux réseaux les utilisent encore. Pour de plus amples informations sur l'administration d'adresses IPv4, reportez-vous à la section Conception du schéma d'adressage IPv4.
L'IETF a développé des adresses CIDR (Classless Inter-Domain Routing, routage inter-domaine sans classe) dans le but de résoudre à court ou moyen terme le problème d'épuisement des adresses IPv4. Par ailleurs, le format CIDR a été conçu pour remédier au manque de capacité des tables de routage Internet. Une adresse IPv4 avec notation CIDR présente une longueur de 32 bits et le même format décimal avec points. Cependant, CIDR ajoute une désignation de préfixe juste après l'octet le plus à droite afin de définir la portion de réseau de l'adresse IPv4. Pour de plus amples informations, reportez-vous à la section Conception du schéma d'adressage IPv4 CIDR.
Le protocole DHCP (Dynamic Host Configuration Protocol, protocole de configuration dynamique d'hôte) permet à un système de recevoir à l'initialisation les informations de configuration d'un serveur DHCP, notamment une adresse IP. Les serveurs DHCP tiennent à jour des pools d'adresses IP à partir desquels attribuer des adresses aux clients DHCP. Cela permet à un site DHCP d'utiliser un pool d'adresses IP plus petit que celui qui serait nécessaire si tous les clients possédaient une adresse IP permanente. Vous pouvez configurer le service DHCP Oracle Solaris afin de gérer les adresses IP de votre site ou une partie des adresses. Pour plus d'informations, reportez-vous au Chapitre 12Service DHCP Oracle Solaris (présentation).
L'IETF a déployé des adresses IPv6 128–bits afin de résoudre à long terme le problème d'épuisement des adresses IPv4 disponibles. Les adresses IPv6 assurent un espace d'adressage plus étendu que IPv4. Grâce au protocole TCP/IP double pile, Oracle Solaris prend en charge les adressages IPv4 et IPv6 sur un même hôte. De même que les adresses IPv4 au format CIDR, les adresses IPv6 ne possèdent aucune notion de classe de réseau ni de masque de réseau. Comme dans CIDR, les adresses IPv6 utilisent des préfixes pour désigner la partie de l'adresse définissant le réseau du site. Pour une introduction à IPv6, reportez-vous à la section Présentation de l'adressage IPv6.
L'IANA a réservé un bloc d'adresses IPv4 et un préfixe de site IPv6 à utiliser sur les réseaux privés. Vous pouvez déployer ces adresses sur des systèmes au sein d'un réseau d'entreprise, mais les paquets possédant des adresses privées ne peuvent pas être transmis via Internet. Pour de plus amples informations sur les adresses privées, reportez-vous à la section Utilisation d'adresses IPv4 privées.
Des adresses IPv4 privées sont également réservées à la documentation. Les exemples de ce manuel utilisent des adresses IPv4 privées et le préfixe de documentation IPv6 réservé.
Un réseau IPv4 se définit à l'aide d'un numéro de réseau IPv4 et d'un masque de réseau. Un réseau IPv6 est défini par son préfixe de site et s'il dispose d'un sous-réseau, par son préfixe de sous-réseau.
Les utilisateurs locaux auront probablement besoin de communiquer hors du réseau local, sauf si vous souhaitez conserver un réseau privé. Par conséquent, vous devez obtenir un numéro IP enregistré pour le réseau auprès de l'organisation adéquate, afin de permettre au réseau de communiquer avec l'extérieur. Cette adresse devient le numéro de réseau de votre schéma d'adressage IPv4 ou le préfixe de site de votre schéma d'adressage IPv6.
Les fournisseurs d'accès Internet (FAI) procurent des adresses IP pour les réseaux à un coût dépendant du niveau de service assuré. Comparez les offres de divers FAI afin de déterminer celui qui fournit le service le plus adéquat pour votre réseau. Les FAI offrent généralement des adresses allouées dynamiquement ou des adresses IP statiques aux entreprises. Certains FAI proposent à la fois des adresses IPv4 et IPv6.
Si le site est un FAI, vous pouvez obtenir les blocs d'adresses IP pour vos clients auprès de l'IR (Internet Registry, registre Internet) correspondant à votre environnement linguistique. L'IANA (Internet Assigned Numbers Authority, autorité de numéros assignés sur Internet) est actuellement responsable de la délégation des adresses IP enregistrées aux IR dans le monde entier. Chaque IR possède des modèles et des informations d'enregistrement dédiés à l'environnement linguistique assuré par l'IR. Pour plus d'informations sur l'IANA et les IR, reportez-vous à la page des services d'adresse IP de l'IANA.
N'attribuez pas d'adresses IP au réseau de façon arbitraire, même s'il n'est connecté à aucun réseau TCP/IP externe. Au contraire, utilisez les adresses privées comme décrit à la section Utilisation d'adresses IPv4 privées.
Pour plus d'informations sur la planification d'adresses IPv6, reportez-vous à la section Préparation d'un plan d'adressage IPv6.
Cette section présente l'adressage IPv4 pour vous aider à concevoir un plan d'adressage IPv4. Pour de plus amples informations sur les adresses IPv6, reportez-vous à la section Présentation de l'adressage IPv6. Pour plus d'informations sur les adresses DHCP, reportez-vous au Chapitre 12Service DHCP Oracle Solaris (présentation).
Chaque réseau IPv4 doit posséder les éléments suivants :
un numéro de réseau unique conçu par un FAI, un IR ou, pour les réseaux plus anciens, enregistré par l'IANA. si vous souhaitez employer des adresses privées, les numéros de réseau créés doivent être uniques au sein de l'organisation ;
des adresses IPv4 uniques pour les interfaces de chaque système du réseau ;
un masque de réseau.
Une adresse IPv4 est un nombre de 32 bits identifiant de manière unique une interface réseau sur un système, comme expliqué à la section Application d'adresses IP aux interfaces réseau. Une adresse IPv4 s'écrit sous forme de nombres décimaux, divisés en quatre champs de 8 bits séparés par des points. Chaque champ de 8 bits représente un octet de l'adresse IPv4. Cette forme de représentation des octets d'une adresse IPv4 est appelée format décimal avec points.
La figure ci-dessous présente les composants d'une adresse IPv4, 172.16.50.56.
Numéro de réseau IPv4 enregistré. En notation IPv4 basée sur les classes, ce numéro définit également la classe de réseau IP (la classe B dans cet exemple) qui aurait été enregistrée par l'IANA.
Partie hôte de l'adresse IPv4. La partie hôte identifie de manière unique l'interface d'un système résidant sur le réseau. La partie réseau de l'adresse est la même pour toutes les interfaces du réseau local, mais la partie hôte doit être différente.
Si vous souhaitez diviser un réseau IPv4 basé sur les classes en sous-réseaux, vous devez définir un masque de sous-réseau (masque de réseau), comme indiqué à la section Base de données netmasks.
L'exemple suivant présente l'adresse de format CIDR 192.168.3.56/22.
Partie réseau, qui correspond au numéro de réseau IPv4 fourni par le FAI ou l'IR.
Partie hôte attribuée à une interface d'un système.
Préfixe de réseau, qui définit le nombre de bits de l'adresse constituant le numéro de réseau. Le préfixe de réseau indique également le masque de sous-réseau de l'adresse IP. Les préfixes de réseau sont également attribués par le FAI ou l'IR.
Un réseau Oracle Solaris peut combiner des adresses IPv4 standard, des adresses IPv4 au format CIDR, des adresses DHCP, des adresses IPv6 et des adresses IPv4 privées.
Cette section décrit les classes selon lesquelles l'adresse IPv4 standard est organisée. L'IANA ne distribue plus de numéros de réseau, mais de nombreux réseaux utilisent encore ces numéros. Sur certains sites, l'espace d'adressage doit être administré à l'aide de numéros de réseau définis par rapport aux classes. Vous trouverez une description détaillée des classes de réseau IPv4 à la section Classes de réseau.
Le tableau suivant indique la décomposition d'une adresse IPv4 standard en espaces d'adressage hôte et réseau. Pour chaque classe, la plage de valeurs décimales du premier octet du numéro de réseau est indiquée dans la colonne Plage d'octets. La colonne Numéro de réseau indique le nombre d'octets de l'adresse IPv4 dédiés à la partie réseau de l'adresse. Chaque octet est représenté par xxx. La colonne Adresse hôte indique le nombre d'octets dédiés à la partie hôte de l'adresse. Par exemple, pour une adresse réseau de classe A, le premier octet est dédié au réseau, tandis que les trois derniers octets définissent l'hôte. Dans un réseau de classe C, c'est le contraire.
Tableau 2–1 Décomposition des adresses IPv4 selon la classe
Classe |
Plage d'octets |
Numéro de réseau |
Adresse hôte |
---|---|---|---|
0–127 |
xxx |
xxx.xxx. xxx |
|
128–191 |
xxx.xxx |
xxx.xxx |
|
192–223 |
xxx.xxx. xxx |
xxx |
Les numéros du premier octet de l'adresse IPv4 définissent la classe du réseau (soit A, B ou C). La plage des trois autres octets est 0–255. Les numéros 0 et 255 sont réservés. Vous pouvez attribuer les numéros 1 à 254 à chaque octet, selon la classe de réseau attribuée à votre réseau par l'IANA.
Le tableau ci-dessous indique les octets de l'adresse IPv4 qui vous est attribuée. Ce tableau indique également, pour chaque octet, la plage de numéros attribuables aux hôtes.
Tableau 2–2 Plage de classes IPv4 disponibles
Classe de réseau |
Plage du premier octet |
Plage du deuxième octet |
Plage du troisième octet |
Plage du quatrième octet |
---|---|---|---|---|
0–127 |
1–254 |
1–254 |
1–254 |
|
128–191 |
Préattribué par l'IANA |
1–254 |
1–254 |
|
192–223 |
Préattribué par l'IANA |
Préattribué par l'IANA |
1–254 |
Les réseaux locaux comprenant un grand nombre d'hôtes sont parfois répartis en sous-réseaux. Si vous décomposez le numéro de réseau IPv4 en sous-réseaux, vous devez attribuer un identificateur réseau à chaque sous-réseau. Le cas échéant, utilisez une partie des bits de la partie hôte de l'adresse IPv4 en tant qu'identificateur réseau afin d'optimiser l'espace d'adressage IPv4. Lorsqu'une partie spécifiée de l'adresse est utilisée en tant qu'identificateur réseau, elle devient le numéro de sous-réseau. Pour créer un numéro de sous-réseau, vous devez utiliser un masque de réseau, ou masque de bits, qui sélectionne les parties réseau et sous-réseau d'une adresse IPv4. Pour plus d'informations, reportez-vous à la section Création du masque de réseau des adresses IPv4.
Les classes de réseau qui constituaient IPv4 à l'origine ne sont plus utilisées sur Internet. Aujourd'hui, l'IANA distribue des adresses de format CIDR sans classe à ses registres du monde entier. Toute adresse IPv4 obtenue auprès d'un FAI se présente au format CIDR, comme illustré sur la Figure 2–2.
Le préfixe de réseau de l'adresse CIDR indique le nombre d'adresses IPv4 disponibles pour les hôtes du réseau. Ces adresses hôte sont attribuées aux interfaces d'un hôte. Si un hôte possède plusieurs interfaces physiques, vous devez attribuer une adresse hôte à chaque interface physique employée.
Le préfixe de réseau d'une adresse CIDR définit également la longueur du masque de sous-réseau. La plupart des commandes reconnaissent le préfixe CIDR d'un masque de sous-réseau dans un réseau. Toutefois, vous devez définir le masque de sous-réseau à l'aide de la représentation décimale avec points pour le programme d'installation Oracle Solaris et le fichier /etc/netmask. Dans ces deux cas, appliquez la représentation décimale avec points du préfixe de réseau CIDR, comme indiqué dans le tableau ci-dessous.
Tableau 2–3 Préfixes CIDR et leur équivalent décimal
Préfixe de réseau CIDR |
Adresses IP disponibles |
Équivalent en numérotation décimale avec points |
---|---|---|
/19 |
8 192 |
255.255.224.0 |
/20 |
4 096 |
255.255.240.0 |
/21 |
2 048 |
255.255.248.0 |
/22 |
1 024 |
255.255.252.0 |
/23 |
512 |
255.255.254.0 |
/24 |
256 |
255.255.255.0 |
/25 |
128 |
255.255.255.128 |
/26 |
64 |
255.255.255.192 |
/27 |
32 |
255.255.255.224 |
Pour de plus amples informations sur les adresses CIDR, reportez-vous aux sources suivantes :
Vous trouverez des informations techniques sur CIDR dans le document RFC 1519, Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy (en anglais).
Des informations plus générales sur CIDR sont disponibles auprès de Pacific Bell Internet dans le document Classless Inter-Domain Routing (CIDR) Overview (en anglais).
Vous trouverez également une présentation sur CIDR dans l'article de Wikipedia intitulé Classless inter-domain routing".
L'IANA a réservé trois blocs d'adresses IPv4 pour permettre aux sociétés de les utiliser sur leurs réseaux privés. Ces adresses sont définies dans le document RFC 1918, Address Allocation for Private Internets (en anglais). Vous pouvez utiliser ces adresses privées, également appelées adresses 1918, pour les systèmes résidant sur des réseaux locaux au sein d'un intranet d'entreprise. Toutefois, les adresses privées ne son pas valides sur Internet. Ne les utilisez pas sur des systèmes devant communiquer hors du réseau local.
Le tableau suivant répertorie les plages d'adresses IPv4 privées et des masques de réseau respectifs.
Plage d'adresses IPv4 |
Masque de réseau |
---|---|
10.0.0.0 - 10.255.255.255 |
10.0.0.0 |
172.16.0.0 - 172.31.255.255 |
172.16.0.0 |
192.168.0.0 - 192.168.255.255 |
192.168.0.0 |
Pour se connecter au réseau, un système doit posséder au moins une interface réseau physique. Chaque interface réseau doit posséder une adresse IP unique. Lors de l'installation Oracle Solaris, vous devez spécifier l'adresse IP de la première interface détectée par le programme d'installation. En général, le nom de cette interface est nom-périphérique0, par exemple eri0 ou hme0. Cette interface est considérée comme l'interface réseau principale.
Si vous ajoutez une autre interface réseau à l'hôte, celle-ci doit également posséder une adresse IP unique. Une fois la deuxième interface réseau ajoutée, l'hôte devient multiréseau. Par contre, lorsque vous ajoutez une deuxième interface réseau à un hôte et activez la transmission IP, cet hôte devient un routeur. Pour plus d'explications, reportez-vous à la section Configuration d'un routeur IPv4.
Chaque interface réseau possède un nom de périphérique, un pilote de périphérique et un fichier de périphérique associé dans le répertoire /devices. L'interface réseau peut posséder un nom de périphérique, par exemple eri ou smc0, qui correspondent aux noms de périphérique de deux interfaces Ethernet usuelles.
Pour obtenir des informations et la description des tâches liées aux interfaces, reportez-vous à la section Gestion des interfaces dans Solaris 10 3/05 ou au Chapitre 6Administration d'interfaces réseau (tâches).
Dans ce manuel, il va de soi que les systèmes possèdent des interfaces réseau Ethernet. Si vous souhaitez utiliser un autre média réseau, reportez-vous aux manuels fournis avec l'interface réseau pour obtenir les informations de configuration.
Lorsque vous avez reçu l'adresse IP réseau qui vous est attribuée, et lorsque vous avez indiqué les adresses IP à vos systèmes, la tâche suivante consiste à attribuer les noms aux hôtes. Ensuite, vous devez déterminer comment gérer les services de noms sur le réseau. Ces noms sont initialement utilisés pour configurer le réseau et, par la suite, pour étendre le réseau à l'aide de routeurs, de ponts ou de PPP.
Les protocoles TCP/IP détectent un système sur le réseau à l'aide de son adresse IP. Toutefois, choisissez un nom reconnaissable afin d'identifier facilement le système. Par conséquent, les protocoles TCP/IP (et Oracle Solaris) nécessitent à la fois l'adresse IP et le nom d'hôte pour identifier de manière unique le système.
Dans le cadre de TCP/IP, un réseau correspond à un ensemble d'entités nommées. Un hôte correspond à une entité possédant un nom. Un routeur correspond à une entité possédant un nom. Le réseau correspond à une entité possédant un nom. Vous pouvez également attribuer un nom à un groupe ou service dans lequel le réseau est installé, ainsi qu'à une division, une région ou une société. Théoriquement, la hiérarchie de noms utilisée pour identifier un réseau est illimitée. Le nom de domaine identifie un domaine.
Sur de nombreux sites, les utilisateurs sont autorisés à choisir les noms d'hôtes de leur machine. Tout serveur requiert également au moins un nom d'hôte associé à l'adresse IP de son interface réseau principale.
L'administrateur système doit s'assurer que chaque nom d'hôte du domaine est unique. En d'autres termes, vous ne pouvez pas attribuer le même nom, Fred par exemple, à deux machines du réseau. Par contre, la machine appelée Fred peut posséder plusieurs adresses IP.
Lors de la planification du réseau, dressez la liste des adresses IP et des noms d'hôtes associés afin d'en faciliter l'accès lors des processus de configuration. Cette liste permet de vérifier que chaque nom d'hôte est unique.
Oracle Solaris permet d'utiliser trois types de services de noms : fichiers locaux, NIS et DNS. Les services de noms mettent à jour d'importantes informations sur les machines du réseau, par exemple les noms d'hôtes, les adresses IP, les adresses Ethernet, etc. Oracle Solaris permet également d'utiliser le service d'annuaire LDAP avec ou à la place d'un service de noms. Pour une présentation des services de noms de Oracle Solaris, reportez-vous à la Partie I, About Naming and Directory Services du System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Lors de l'installation du système d'exploitation, vous indiquez le nom d'hôte et l'adresse IP du serveur, des clients ou du système autonome. Le programme d'installation de Oracle Solaris ajoute ces informations aux hôtes. Dans Solaris 10 11/06 et les versions Solaris 10 antérieures, ces informations sont ajoutées à la base de données réseau ipnodes. Cette base de données fait partie d'un ensemble de bases de données réseau contenant les informations nécessaires aux opérations TCP/IP sur le réseau. Le service de noms sélectionné pour le réseau lit ces bases de données.
La configuration des bases de données réseau est d'une importance capitale. Par conséquent, vous devez choisir le service de noms à utiliser au cours du processus de planification réseau. En outre, l'utilisation des services de noms affecte également l'organisation du réseau en un domaine administratif. La section Bases de données réseau et fichier nsswitch.conf contient des informations détaillées sur les bases de données réseau.
Les services de noms NIS et DNS mettent à jour des bases de données réseau sur plusieurs serveurs du réseau. Ces services de noms et la configuration des bases de données sont décrits dans le System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). En outre, ce manuel explique en détail les concepts d'espace de noms et de domaine administratif.
Si vous n'implémentez ni NIS, ni LDAP, ni DNS, le réseau assure le service de noms à l'aide de fichiers locaux. Le terme "fichiers locaux" fait référence à la série de fichiers du répertoire /etc utilisé par les bases de données réseau. Sauf indication contraire, les procédures de ce manuel partent du principe que vous utilisez des fichiers locaux comme service de noms.
Si vous décidez d'utiliser des fichiers locaux en tant que service de noms pour le réseau, vous pouvez configurer plus tard un autre service de noms.
De nombreux réseaux organisent leurs hôtes et routeurs selon une hiérarchie de domaines administratifs. Si vous utilisez le service de noms NIS ou DNS, vous devez sélectionner pour l'organisation un nom de domaine unique au monde. Pour vérifier que le nom de domaine est unique, enregistrez-le auprès de l'InterNIC. Si vous souhaitez utiliser DNS, vous devez également enregistrer votre nom de domaine auprès de l'InterNIC.
La structure des noms de domaine est hiérarchique. En général, tout nouveau domaine se place sous un domaine existant associé. Par exemple, le nom de domaine d'une filiale peut se placer sous le nom de domaine de la maison mère. Si le nom de domaine n'a pas d'autre relation, une organisation peut placer son nom de domaine directement sous l'un des domaines supérieurs existants.
Vous trouverez ci-dessous quelques exemples de domaines supérieurs :
.com : entreprises commerciales (d'envergure internationale) ;
.edu : institutions d'enseignement (d'envergure internationale) ;
.gov : organismes publics américains ;
.fr : France.
Vous devez sélectionner un nom unique pour identifier votre organisation.
La création de sous-divisions administratives dépend de la taille du réseau et du contrôle requis. À mesure que les nombres d'hôtes et de serveurs augmentent, la gestion du réseau devient de plus en plus complexe. Dans une telle situation, il peut s'avérer indispensable de configurer des divisions administratives supplémentaires. Par exemple, ajoutez des réseaux d'une classe particulière ou séparez les réseaux existants en sous-réseaux. La configuration de sous-divisions administratives pour le réseau dépend des facteurs ci-dessous :
Étendue du réseau
Une division administrative peut gérer à elle seule un réseau de plusieurs centaines d'hôtes se trouvant physiquement au même endroit et requérant des services administratifs identiques. Toutefois, il peut s'avérer judicieux d'établir plusieurs sous-divisions administratives. Les sous-divisions sont particulièrement utiles dans le cas d'un petit réseau réparti en sous-réseaux, si le réseau s'étend sur une large zone géographique.
Besoins des utilisateurs
Par exemple, un réseau peut résider entièrement dans un bâtiment et prendre en charge des machines relativement peut nombreuses. Ces machines sont réparties en plusieurs sous-réseaux. Chaque sous-réseau prend en charge des groupes d'utilisateurs ayant des besoins différents. Dans cet exemple, il serait judicieux de créer une sous-division administrative par sous-réseau.
Il existe deux types d'entités TCP/IP sur un réseau : les hôtes et les routeurs. Tout réseau doit contenir des hôtes, mais les routeurs ne sont pas toujours requis. La topologie physique du réseau détermine si des routeurs sont requis. Cette section présente les concepts de routage et de topologie réseau. Ces concepts sont importants pour l'ajout d'un réseau à l'environnement réseau existant.
Pour obtenir les détails de la configuration des routeurs sur les réseaux IPv4, ainsi que la description des tâches associées, reportez-vous à la section Transfert et routage de paquets sur des réseaux IPv4. Pour obtenir les détails de la configuration des routeurs sur les réseaux IPv6, ainsi que la description des tâches associées, reportez-vous à la section Configuration d'un routeur IPv6.
La topologie réseau décrit l'organisation des réseaux. Les routeurs constituent des entités connectant les réseaux les uns aux autres. Toute machine possédant plusieurs interfaces réseau et implémentant la transmission IP constitue un routeur. Toutefois, pour fonctionner en tant que routeur, le système doit être configuré, comme décrit à la section Configuration d'un routeur IPv4.
Les routeurs connectent plusieurs réseaux pour former des interréseaux plus étendus. Les routeurs doivent être configurés de manière à transmettre des paquets entre deux réseaux adjacents. Les routeurs doivent également être à même de transmettre les paquets vers les réseaux résidant au-delà des réseaux adjacents.
La figure ci-dessous indique les composants de base d'une topologie réseau. La première illustration présente une configuration simple de deux réseaux connectés par un routeur. La deuxième illustration présente la configuration de trois réseaux interconnectés par deux routeurs. Dans le premier exemple, le routeur R joint le réseau 1 et le réseau 2 pour former un interréseau plus étendu. Dans le deuxième exemple, le routeur R1 connecte les réseaux 1 et 2. Le routeur R2 connecte les réseaux 2 et 3. Les connexions forment un réseau comprenant les réseaux 1, 2 et 3.
Outre la formation d'interréseaux par la jonction de réseaux, les routeurs assurent la transmission de paquets entre les réseaux en fonction des adresses du réseau de destination. À mesure que les interréseaux se complexifient, chaque routeur doit prendre de plus en plus de décisions relativement à la destination des paquets.
La figure ci-dessous présente un cas plus complexe. Le routeur R3 connecte directement les réseaux 1 et 3. La redondance améliore la fiabilité. Si le réseau 2 tombe en panne, le routeur R3 fournit encore une route entre les réseaux 1 et 3. Vous pouvez interconnecter plusieurs réseaux. Toutefois, les réseaux doivent employer les mêmes protocoles réseau.
L'adresse IP du destinataire, indiquée dans l'en-tête du paquet, détermine la méthode de routage du paquet. Si le numéro de réseau de l'adresse correspond au réseau local, le paquet se dirige directement vers l'hôte possédant cette adresse IP. Si le numéro de réseau ne correspond pas au réseau local, le paquet se dirige directement vers le routeur du réseau local.
Les routeurs conservent les informations de routage dans des tables de routage. Ces tables contiennent les adresses IP des hôtes et routeurs résidant sur les réseaux auxquels le routeur est connecté. Elles incluent également des pointeurs vers ces réseaux. À la réception d'un paquet, le routeur recherche dans sa table de routage l'adresse de destination indiquée dans l'en-tête du paquet. Si l'adresse de destination ne se trouve pas dans la table, le routeur transfère le paquet à un autre routeur répertorié dans sa table de routage. Pour plus d'informations sur les routeurs, reportez-vous à la section Configuration d'un routeur IPv4.
La figure ci-dessous présente une topologie réseau constituée de trois réseaux connectés par deux routeurs.
Le routeur R1 connecte les réseaux 192.9.200 et 192.9.201. Le routeur R2 connecte les réseaux 192.9.201 et 192.9.202. SI l'hôte A du réseau 192.9.200 envoie un message à l'hôte B du réseau 192.9.202, les événements suivants se produisent :
L'hôte A envoie un paquet au réseau 192.9.200. L'en-tête du paquet contient l'adresse IPv4 de l'hôte destinataire, soit l'hôte B, 192.9.202.10.
Aucune machine du réseau 192.9.200 ne possède l'adresse IPv4 192.9.202.10. Par conséquent, le routeur R1 accepte le paquet.
Le routeur R1 examine ses tables de routage. Aucune machine du réseau 192.9.201 ne possède l'adresse 192.9.202.10. Toutefois, le routeur R2 est répertorié dans les tables de routage.
R1 sélectionne ensuite R2 comme routeur du "saut suivant". R1 envoie le paquet à R2.
Comme il connecte le réseau 192.9.201 au réseau 192.9.202, R2 possède des informations de routage pour l'hôte B. Il transfère ensuite le paquet vers le réseau 192.9.202, où l'hôte B l'accepte.
Ce chapitre présente un aperçu de l'implémentation du protocole Internet version 6 (IPv6) de Oracle Solaris. Cette implémentation inclut le démon et les utilitaires associés prenant en charge l'espace d'adressage IPv6.
L'environnement réseau de Oracle Solaris peut contenir des adresses IPv6 et IPv4. Les systèmes configurés avec des adresses IPv6 conservent leurs adresses IPv4, si celles-ci existent déjà. Les opérations utilisant les adresses IPv6 n'ont pas d'incidence sur les opérations IPv4 et inversement.
Les rubriques traitées sont les suivantes :
Pour obtenir des informations détaillées sur IPv6, consultez les chapitres suivants.
Planification de réseau IPv6 – Chapitre 4Planification d'un réseau IPv6 (tâches)
Tâches relatives à IPv6 – Chapitre 7Configuration d'un réseau IPv6 (tâches) andChapitre 8Gestion d'un réseau TCP/IP (tâches).
Informations détaillées sur IPv6 – Chapitre 11Présentation détaillée de IPv6 (référence)
L'espace d'adressage offert par IPv6 est plus grand que celui qui est fournit par IPv4. IPv6 permet également d'améliorer les capacités Internet, et ce dans de nombreux domaines, tel que décrit dans cette section.
La taille de l'adresse IP passe de 32 bits pour IPv4 à 128 bits pour IPv6, ce qui permet une prise en charge d'un plus grand nombre de niveaux de hiérarchie d'adressage. En outre, IPv6 fournit beaucoup plus de systèmes IPv6 adressables. Pour de plus amples informations, reportez-vous à la section Présentation de l'adressage IPv6.
Le protocole IPv6 de détection de voisins (ND, Neighbor Discovery) facilite la configuration automatique des adresses IPv6. La configuration automatique correspond à la capacité d'un hôte IPv6 à générer automatiquement sa propre adresse IPv6, ce qui simplifie l'administration d'adresses. Pour de plus amples informations, reportez-vous à la section Configuration automatique d'adresse IPv6.
Le protocole de détection de voisins correspond à une combinaison de ces protocoles IPv4 : ARP (Address Resolution Protocol, protocole de résolution d'adresse), ICMP (Internet Control Message Protocol, protocole de message de contrôle Internet), RDISC (Router Discovery, détection de routeur) et ICMP Redirect. Les routeurs IPv6 utilisent la détection de voisins afin de publier le préfixe de site IPv6. Les hôtes IPv6 utilisent la détection de voisins à des fins diverses, incluant la demande de préfixe à un routeur IPv6. Pour de plus amples informations, reportez-vous à la section Présentation du protocole de détection de voisins IPv6.
Avec le format d'en-tête IPv6, certains champs d'en-tête IPv4 ne sont plus utilisés tandis que d'autres deviennent facultatifs. Cette modification permet de maintenir les coûts de bande passante de l'en-tête IPv6 aussi bas que possible, malgré l'augmentation de la taille d'adresse. Bien que les adresses IPv6 soient quatre fois plus longues que les adresses IPv4, l'en-tête IPv6 n'est que deux fois plus grande l'en-tête IPv4.
Des modifications de la méthode d'encodage des options d'en-tête d'IP permettent un transfert plus efficace. En outre, les limites relatives à la longueur des options IPv6 sont moins strictes. Ces modifications permettent une plus grande flexibilité pour l'introduction future de nouvelles options.
De nombreux services réseau Oracle Solaris critiques reconnaissent et prennent en charge les adresses IPv6, par exemple :
les services de noms comme DNS, LDAP et NIS. Pour obtenir des informations sur la prise en charge de ces services dans IPv6, reportez-vous à la section System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .
les applications d'authentification et de confidentialité, telles que IPsec (IP Security Architecture, architecture de sécurité IP) et IKE (Internet Key Exchange, échange de clé Internet). Pour plus d'informations, reportez-vous à Partie IV, IPsec.
les services différenciés, par exemple ceux qui sont fournis par IPQoS (IP Quality of Service, qualité de service IP). Pour plus d'informations, reportez-vous à Partie VII, Qualité de service IP (IPQoS).
la détection de basculement, fournie par IPMP (IP Network Multipathing, multiacheminement sur réseau IP). Pour plus d'informations, reportez-vous à Partie VI, IPMP.
Outre cette partie, vous pouvez obtenir des informations sur IPv6 auprès des sources répertoriées dans les sections suivantes.
De nombreux RFC (Request for Comments, demande de commentaires) relatifs à IPv6 sont disponibles. Le tableau suivant répertorie les principaux articles sur IPv6 et leur emplacement sur le site Web de l'IETF (Internet Engineering Task Force, groupe d'étude d'ingénierie Internet) à ce jour.
Tableau 3–1 RFC et brouillons Internet relatifs à IPv6
RFC ou brouillon Internet |
Objet |
Emplacement |
---|---|---|
RFC 2461, Neighbor Discovery for IP Version 6 (IPv6) |
Description des caractéristiques et fonctions du protocole de détection de voisins IPv6. | |
RFC 3306, Unicast—Prefix—Based IPv6 Multicast Addresses |
Description du format et des types d'adresses IPv6 multidiffusion. | |
RFC 3484: Default Address Selection for Internet Protocol version 6 (IPv6) |
Description des algorithmes utilisés pour la sélection d'adresses IPv6 par défaut. | |
RFC 3513, Internet Protocol version 6 (IPv6) Addressing Architecture |
Informations détaillées sur les types d'adresses IPv6 et de nombreux exemples. | |
RFC 3587, IPv6 Global Unicast Address Format |
Définition du format standard des adresses IPv6 unicast. |
Vous trouverez des informations sur IPv6 sur les sites Web suivants.
Tableau 3–2 Sites Web relatifs à IPv6
Site Web |
Description |
Emplacement |
---|---|---|
Forum IPv6 |
Des liens vers des présentations, événements, formations et implémentations relatifs à IPv6 et à dimension mondiale sont disponibles sur le site Web de cette société. | |
Internet Educational Task Force IPv6 Working Group |
Des liens vers la totalité des RFC et brouillons Internet IPv6 pertinents sont disponibles sur la page d'accueil de ce groupe de travail IETF. |
Cette section présente les termes fondamentaux de la topologie réseau IPv6. La figure ci-dessous indique les composants de base d'un réseau IPv6.
L'illustration représente un réseau IPv6 et sa connexion à un FAI. Le réseau interne se compose des liens 1, 2, 3 et 4. Chaque lien est renseigné par des hôtes et terminé par un routeur. Le routeur de bordure se trouve à l'une des extrémités du lien 4, qui correspond à la DMZ du réseau. Le routeur de bordure exécute un tunnel IPv6 vers un FAI, lequel fournit la connectivité Internet au réseau. Le lien 2 et le lien 3 sont gérés en tant que sous-réseau 8a. Le sous-réseau 8b ne contient des systèmes que sur le lien 1. Le sous-réseau 8c et DMZ sont contigus sur le lien 4.
Comme indiqué sur la Figure 3–1, un réseau IPv6 se compose des mêmes éléments qu'un réseau IPv4. Cependant, la terminologie IPv6 diffère légèrement de celle d'IPv4. Voici une liste des termes courants de composants de réseau tels qu'ils sont utilisés dans un contexte IPv6.
Tout système disposant d'une adresse IPv6 et d'une interface configurée pour une prise en charge d'IPv6. Ce terme générique s'applique aux hôtes et aux routeurs.
Nœud transférant les paquets IPv6. Au moins une des deux interfaces du routeur doit être configurée afin d'assurer la prise en charge d'IPv6. Un routeur IPv6 peut également publier sur le réseau interne le préfixe de site IPv6 enregistré pour l'entreprise.
Nœud avec adresse IPv6. Un hôte IPv6 peut disposer de plusieurs interfaces configurées pour une prise en charge d'IPv6. Tout comme dans IPv4, les hôtes IPv6 n'assurent pas le transfert de paquets.
Média réseau unique et contigu limité à l'une de ses extrémités par un routeur.
Nœud IPv6 situé sur le même lien que le nœud local.
Segment administratif d'un réseau IPv6. Les composants d'un sous-réseau IPv6 peuvent correspondre directement avec tous les nœuds d'un lien, comme dans IPv4. Les nœuds d'un lien peuvent être administrés dans des sous-réseaux séparés si nécessaire. En outre, IPv6 prend en charge les sous-réseaux à liens multiples, dans lesquels les nœuds situés sur plusieurs liens peuvent être les composants d'un sous-réseau unique. Les liens 2 et 3 de la Figure 3–1 sont des composants du sous-réseau à liens multiples 8a.
Tunnel fournissant un chemin virtuel point à point entre un nœud IPv6 et l'extrémité d'un autre nœud IPv6. IPv6 prend en charge les tunnels configurables manuellement et les tunnels 6to4 automatiques.
Routeur situé à la limite d'un réseau qui fournit l'une des extrémités du tunnel IPv6 à une extrémité située à l'extérieur du réseau local. Ce routeur doit disposer au moins d'une interface IPv6 avec le réseau interne. Pour le réseau externe, le routeur peut disposer d'une interface IPv6 ou IPv4.
Les adresses IPv6 sont assignées à des interfaces, plutôt qu'à des nœuds, dans la mesure où un nœud peut disposer de plusieurs interfaces. De plus, vous pouvez assigner plusieurs adresses IPv6 à une interface.
Pour obtenir des informations techniques complètes sur le format d'adresse IPv6, consultez le document RFC 2374, IPv6 Global Unicast Address Format
IPv6 définit trois types d'adresse :
Identifie l'interface d'un nœud individuel.
Identifie un groupe d'interfaces, en règle générale sur des nœuds différents. Les paquets envoyés à l'adresse multidiffusion vont à tous les membres du groupe multidiffusion.
Identifie un groupe d'interfaces, en règle générale sur des nœuds différents. Les paquets envoyés à l'adresse anycast vont au nœud membre du groupe anycast le plus proche de l'expéditeur.
Une adresse IPv6 est longue de 128 bits et se compose de huit champs de 16 bits, chacun étant délimité par deux-points (:). Chaque champ doit contenir un nombre hexadécimal, à la différence de la notation en format décimal avec points des adresses IPv4. Dans l'illustration suivante, les x représentent des nombres hexadécimaux.
Les trois champs situés complètement à gauche (48 bits) contiennent le préfixe de site. Le préfixe décrit la topologie publique allouée en général à votre site par un FAI ou un registre Internet régional (RIR, Regional Internet Registry).
Le champ suivant correspond à l'ID de sous-réseau de 16 bits alloué au site (par vous ou par un autre administrateur). L'ID de sous-réseau décrit la topologie privée, appelée également topologie de site, car elle est interne au site.
Les quatre champs les plus à droite (64 bits) contiennent l'ID d'interface, également appelée jeton. L'ID d'interface est soit configurée automatiquement à partir de l'adresse MAC de l'interface, soit configurée manuellement au format EUI-64.
Observez à nouveau l'adresse de l'illustration Figure 3–2 :
2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b
Cet exemple illustre les 128 bits d'une adresse IPv6. Les premiers 48 bits, 2001:0db8:3c4d, contiennent le préfixe de site, représentant la topologie publique. Les 16 bits suivants, 0015, contiennent l'ID de sous-réseau. Ils représentent la topologie privée du site. Les 64 bits situés complètement à droite, 0000:0000:1a2f:1a2b, contiennent l'ID d'interface.
En général, les adresses IPv6 n'occupent pas la totalité des 128 bits dont elles disposent. Par conséquent, certains champs sont renseignés partiellement ou en totalité par des zéros.
L'architecture d'adressage IPv6 vous permet d'utiliser la notation à deux points (: : ) pour représenter les champs de zéros contigus de 16 bits. Vous pouvez par exemple raccourcir l'adresse IPv6 de la Figure 3–2 en remplaçant les deux champs de zéros contigus de l'ID d'interface par deux deux-points. L'adresse devient alors : 2001:0db8:3c4d:0015::1a2f:1a2b. Les autres champs de zéros peuvent être représentés par un seul 0. Vous pouvez également omettre tout zéro de début d'un champ, en remplaçant par exemple 0db8 par db8.
Par conséquent, l'adresse 2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b peut être raccourcie en 2001:db8:3c4d:15::1a2f:1a2b.
Vous pouvez utiliser la notation à deux deux-points afin de remplacer les champs contigus composés de zéros de l'adresse IPv6. Par exemple, l'adresse IPv6 2001:0db8:3c4d:0015:0000:d234::3eee:0000 peut être raccourcie en 2001:db8:3c4d:15:0:d234:3eee::.
Les champs de l'adresse IPv6 situés complètement à gauche contiennent le préfixe utilisé pour le routage de paquets IPv6. Le format des préfixes IPv6 est le suivant :
préfixe/longueur en bits
La longueur du préfixe est indiquée en notation CIDR. La notation CIDR correspond à un slash (/) à la fin de l'adresse, suivi de la longueur du préfixe en bits. Pour de plus amples informations sur les adresses IP au format CIDR, reportez-vous à la section Conception du schéma d'adressage IPv4 CIDR.
Le préfixe de site d'une adresse IPv6 occupe jusqu'à 48 des bits situés complètement à gauche de celle-ci. Par exemple, le préfixe de site de l'adresse IPv6 2001:db8:3c4d:0015:0000:0000:1a2f:1a2b/48 réside dans les 48 bits situés complètement à gauche, soit 2001:db8:3c4d. Vous pouvez représenter ce préfixe de la façon suivante, avec zéros compressés :
2001:db8:3c4d::/48
Le préfixe 2001:db8::/32 est un préfixe IPv6 spécial utilisé spécifiquement dans les exemples de documentation.
Vous pouvez spécifier un préfixe de sous-réseau définissant la topologie interne du réseau vers un routeur. Le préfixe de sous-réseau de l'exemple d'adresse IPv6 est le suivant.
2001:db8:3c4d:15::/64
Le préfixe de sous-réseau contient toujours 64 bits. Ceux-ci se décomposent en 48 bits pour le préfixe de site et 16 bits pour l'ID de sous-réseau.
Les préfixes suivants sont réservés à un usage spécial :
Indique qu'un préfixe de routage 6to4 suit.
Indique qu'une adresse lien-local suit.
Indique qu'une adresse multidiffusion suit.
IPv6 inclut deux assignations différentes d'adresses unicast :
adresse unicast globale ;
adresse lien-local.
Le type d'adresse unicast est déterminé par les bits contigus situés complètement à gauche de l'adresse, qui contiennent le préfixe.
Le format d'adresse unicast est organisé selon la hiérarchie suivante :
topologie publique ;
topologie de site (privée) ;
ID d'interface.
L'adresse unicast globale est unique au monde sur Internet. L'adresse IPv6 d'exemple figurant à la section Préfixes d'IPv6 constitue une adresse unicast globale. L'illustration suivante représente l'étendue de l'adresse unicast globale, en comparaison avec les parties de l'adresse IPv6.
Le préfixe de site définit la topologie publique de votre réseau auprès d'un routeur. Vous pouvez obtenir le préfixe de site pour votre entreprise auprès d'un FAI ou d'un RIR (Regional Internet Registry, registre Internet régional).
Dans IPv6, l'ID de sous-réseau définit un sous-réseau administratif du réseau ; sa longueur est de 16 bits maximum. L'assignation d'un ID de sous-réseau fait partie de la configuration de réseau IPv6. Le préfixe de sous-réseau définit la topologie du site vers un routeur en spécifiant le lien spécifique auquel a été assigné le sous-réseau.
Conceptuellement, les sous-réseaux IPv6 sont similaires aux sous-réseaux IPv4, dans la mesure où chaque sous-réseau est en général associé à un lien matériel unique. Cependant, les ID de sous-réseau IPv6 s'expriment en notation hexadécimale plutôt qu'en notation décimale avec points.
L'ID d'interface identifie l'interface d'un nœud donné. Un ID d'interface doit être unique au sein du sous-réseau. Les hôtes IPv6 peuvent utiliser le protocole de détection de voisins afin de générer automatiquement leurs propres ID d'interface. La détection de voisins génère automatiquement l'ID d'interface, en fonction de l'adresse MAC ou EUI-64 de l'interface de l'hôte. Vous pouvez également attribuer manuellement les ID d'interface ; cela est recommandé pour les routeurs IPv6 et les serveurs compatibles IPv6. Pour obtenir des instructions de création manuelle d'adresses EUI-3513, reportez-vous au document RFC 3513 Internet Protocol Version 6 (IPv6) Addressing Architecture.
Le protocole IPv6 inclut, à des fins de transition, la capacité d'intégrer une adresse IPv4 dans une adresse IPv6. Ce type d'adresse IPv4 facilite la mise en tunnel de paquets IPv6 au travers de réseaux IPv4 existants. L'adresse 6to4 constitue un exemple d'adresse unicast transitionnelle globale. Pour de plus amples informations sur l'adressage 6to4, reportez-vous à la section Tunnels automatiques 6to4.
L'adresse unicast lien-local s'utilise exclusivement sur le lien de réseau local. Les adresses lien-local ne sont ni valides ni reconnues en dehors de l'entreprise. L'exemple suivant représente le format de l'adresse lien-local.
Le format d'un préfixe lien-local est le suivant :
fe80::ID-interface/10
L'exemple suivant constitue une adresse lien-local :
fe80::23a1:b152
Représentation hexadécimale du préfixe binaire 10 bits 1111111010. Ce préfixe identifie le type d'adresse IPv6 comme étant un lien local.
Adresse hexadécimale de l'interface, dérivée en général de l'adresse MAC 48 bits.
Lorsque vous activez le protocole IPv6 lors de l'installation de Oracle Solaris, l'interface avec le numéro le plus faible de l'ordinateur local est configurée avec une adresse de lien local. Chaque interface doit disposer d'au moins une adresse lien-local afin d'identifier le nœud auprès d'autres nœuds sur le lien local. Par conséquent, vous devez configurer manuellement les adresses lien-local pour les interfaces supplémentaires d'un nœud. Une fois la configuration terminée, le nœud utilise ses adresses lien-local pour la configuration automatique d'adresses et la détection de voisins.
IPv6 prend en charge l'utilisation d'adresses multicast. L'adresse multicast identifie un groupe multicast, qui correspond à un groupe d'interfaces, en règle générale sur des nœuds différents. Une interface peut faire partie d'un nombre indéfini de groupes multicast. Si les premiers 16 bits d'une adresse IPv6 sont ff00 n, il s'agit d'une adresse multicast.
Les adresses multicast sont utilisées pour l'envoi d'informations ou de services à toutes les interfaces définies en tant que membres du groupe multicast. Par exemple, les adresses multicast s'utilisent entre autres afin de communiquer avec tous les nœuds IPv6 du lien local.
Lors de la création de l'adresse unicast IPv6 d'une interface, le noyau ajoute automatiquement l'interface à un certain nombre de groupes multicast. Par exemple, chaque nœud est ajouté par le noyau au groupe multicast Solicited Node, qui est utilisé par le protocole de détection de voisins afin de détecter l'accessibilité. En outre, le noyau ajoute automatiquement un nœud aux groupes multicast All-Nodes ou All Routers.
Pour obtenir des informations détaillées sur les adresses multicast, reportez-vous à la section Présentation détaillée des adresses IPv6 multicast. Pour obtenir des informations techniques, reportez-vous au document RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses. Le format d'adresse multicast y est décrit. Pour plus d'informations sur l'utilisation appropriée des adresses et des groupes multicast, reportez-vous au document RFC 3307, Allocation Guidelines for IPv6 Multicast Addresses.
Les adresses anycast IPv6 identifient un groupe d'interfaces situées sur différents nœuds IPv6. Chaque groupe d'interfaces correspond à un groupe anycast. Lorsqu'un paquet est envoyé à l'adresse anycast, le membre du groupe anycast le plus proche de l'expéditeur reçoit le paquet.
L'implémentation du protocole IPv6 dans Oracle Solaris n'est pas compatible avec la création de groupes et d'adresses anycast. Cependant, les nœuds IPv6 Oracle Solaris peuvent envoyer des paquets à des adresses anycast. Pour de plus amples informations, reportez-vous à la section Informations importantes pour la création de tunnels vers un routeur relais 6to4.
IPv6 introduit le protocole de détection de voisins, qui utilise la messagerie pour gérer les interactions entre nœuds voisins. Les nœuds voisins sont des nœuds IPv6 situés sur le même lien. Par exemple, un nœud peut connaître l'adresse lien-local d'un voisin grâce à l'émission de messages relatifs à la détection de voisins. La détection de voisins contrôle les activités principales suivantes de lien local IPv6 :
Détection de routeur : aide les hôtes à localiser les routeurs sur le lien local.
Configuration automatique d'adresse : permet à un nœud de configurer automatiquement les adresses IPv6 pour ses interfaces.
Détection de préfixe : permet aux nœuds de détecter les préfixes de sous-réseau connus alloués à un lien. Les nœuds utilisent les préfixes afin de faire la distinction entre les destinations situées sur le lien local et celles qu'il n'est possible d'atteindre que par le biais d'un routeur.
Résolution d'adresse : permet aux nœuds de déterminer l'adresse lien-local d'un voisin, uniquement à l'aide de l'adresse IP de la destination.
Détermination du prochain saut : utilise un algorithme afin de déterminer l'adresse IP d'un destinataire de paquet un saut au-delà du lien local. Le prochain saut peut être un routeur ou le nœud de destination.
Détection d'inaccessibilité de voisin : aide les nœuds à déterminer si un voisin est désormais inaccessible. Il est possible de répéter la résolution d'adresse pour les routeurs et les hôtes.
Détection d'adresses dupliquées : permet à un nœud de déterminer si une adresse qu'il souhaite utiliser n'est pas déjà en cours d'utilisation.
Redirection : permet à un routeur d'informer un hôte de l'existence d'un nœud premier saut plus adéquat pour atteindre une destination particulière.
La détection de voisins utilise les types de messages IMCP suivants afin de communiquer parmi les nœuds sur un lien :
sollicitation de routeur ;
publication de routeur ;
sollicitation de voisin ;
publication de voisin ;
réacheminement.
Pour obtenir des informations sur les messages de détection de voisins et sur d'autres sujets relatifs au protocole de détection de voisins, reportez-vous à la section Protocole ND IPv6. Pour obtenir des informations techniques sur le protocole Neighbor Discovery, reportez-vous au document, RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).
Une des fonctions principales d'IPv6 correspond à la capacité de l'hôte à configurer automatiquement une interface. La détection de voisins permet à l'hôte de localiser un routeur IPv6 sur le lien local et d'émettre une requête de préfixe de site. L'hôte effectue les tâches suivantes dans le cadre du processus de configuration automatique :
création d'une adresse lien-local pour chaque interface ne nécessitant pas de routeur sur le lien ;
vérification de l'unicité de l'adresse d'un lien ne nécessitant pas de routeur sur le lien ;
définition du mode d'obtention des adresses globales, soit à l'aide du mécanisme sans état, soit du mécanisme avec état, soit à l'aide des deux mécanismes (requiert un routeur sur le lien).
La configuration automatique sans état ne nécessite aucune configuration manuelle des hôtes, une configuration minimale (voire aucune) des routeurs et aucun serveur supplémentaire. Le mécanisme sans état permet à un hôte de générer ses propres adresses. Le mécanisme sans état utilise des informations locales et non locales publiées par les routeurs pour la génération d'adresses.
Vous pouvez implémenter des adresses temporaires pour une interface, lesquelles sont également configurées automatiquement. Vous activez un jeton d'adresse temporaire pour une ou plusieurs interfaces sur un hôte. Cependant, à la différence des adresses IPv6 standard configurées automatiquement, une adresse temporaire se compose du préfixe de site et d'un numéro de 64 bits généré aléatoirement. Ce numéro aléatoire devient la partie d'ID d'interface de l'adresse IPv6. Une adresse lien-local n'est pas générée avec l'adresse temporaire en tant qu'ID d'interface.
Les routeurs publient tous les préfixes assignés sur le lien. Les hôtes IPv6 utilisent la détection de voisins afin d'obtenir un préfixe de sous-réseau d'un routeur local. Les hôtes créent des adresses IPv6 automatiquement en combinant le préfixe de sous-réseau avec l'ID d'interface généré à partir de l'adresse MAC d'une interface. En l'absence de routeur, un hôte génère uniquement des adresses lien-local. Les adresses lien-local s'utilisent exclusivement pour la communication avec les nœuds sur un même lien.
N'utilisez pas la configuration automatique sans état pour la création d'adresses IPv6 de serveurs. Les hôtes génèrent automatiquement des ID d'interface basés sur des informations spécifiques au matériel lors de la configuration automatique. L'ID d'interface actuel pourrait devenir incorrecte en cas de remplacement de l'interface par une nouvelle interface.
Dans la plupart des entreprises, l'introduction du protocole IPv6 sur un réseau IPv4 doit s'effectuer progressivement. L'environnement de réseau à double pile Oracle Solaris prend en charge à la fois les fonctionnalités IPv4 et IPv6. Comme la plupart des réseaux utilisent le protocole IPv4, il est impossible aux réseaux IPv6 de communiquer sans tunnels.
En général, la création de tunnels IPv6 inclut l'encapsulation du paquet IPv6 sortant dans un paquet IPv4. Le routeur de bordure du réseau IPv6 configure un tunnel point à point sur plusieurs réseaux IPv4 jusqu'au routeur de bordure du réseau IPv6 de destination. Le paquet passe ensuite à travers le tunnel jusqu'au routeur de bordure du réseau cible qui le décapsule. Enfin, le routeur transmet le paquet IPv6 distinct au noeud de destination.
L'implémentation du protocole IPv6 sous Oracle Solaris prend en charge les scénarios de mise en tunnel suivants :
Configuration manuelle d'un tunnel entre les deux réseaux IPv6 sur le réseau IPv4. Le réseau IPv4 peut correspondre à un réseau Internet ou au réseau local d'une entreprise.
Configuration manuelle d'un tunnel entre les deux réseaux IPv4 sur un réseau IPv6 (généralement de l'entreprise).
Configuration automatique et dynamique d'un tunnel 6to4 entre les deux réseaux IPv6 sur le réseau IPv4 d'une entreprise ou sur un réseau Internet.
Pour de plus amples informations sur les tunnels IPv6, reportez-vous à la section Tunnels IPv6. Pour de plus amples informations sur les tunnels IPv4-to-IPv4 et VPN, reportez-vous à la section Réseaux privés virtuels et IPsec.
Le déploiement d'IPv6 sur un réseau, nouveau ou existant, requiert un grand effort de planification. Ce chapitre décrit les tâches de planification requise avant de configurer IPv6 sur votre site. Dans le cas de réseaux existants, le déploiement d'IPv6 doit s'effectuer progressivement. Les rubriques de ce chapitre vous permettent d'effectuer une introduction progressive d'IPv6 dans un réseau exclusivement IPv4 à l'origine.
Ce chapitre examine les rubriques suivantes :
Pour une présentation des concepts IPv6, reportez-vous au Chapitre 3Présentation d'IPv6. Pour obtenir des informations détaillées, reportez-vous au Chapitre 11Présentation détaillée de IPv6 (référence).
Effectuez les tâches de la liste suivante dans l'ordre afin de planifier les tâches nécessaires au déploiement d'IPv6.
Le tableau suivant répertorie les différentes tâches de configuration du réseau IPv6. Le tableau comprend la description des actions de chaque tâche et la section de la documentation actuelle dans laquelle les étapes permettant d'effectuer ces tâches sont décrites en détails.
Tâche |
Description |
Voir |
---|---|---|
1. Préparation du matériel pour qu'il prenne en charge IPv6. |
Vérifiez qu'il est possible de mettre le matériel à niveau vers IPv6. |
Préparation de la topologie réseau pour une prise en charge d'IPv6 |
2. Obtention d'un FAI prenant en charge IPv6. |
Assurez-vous que votre FAI actuel prend en charge le protocole IPv6. Dans le cas contraire, trouvez un FAI prenant en charge IPv6. Vous pouvez faire appel à deux FAI : l'un pour IPv6, l'autre pour les communications IPv4. |
|
3. Vérification de la compatibilité des applications avec IPv6. |
Assurez-vous que les applications peuvent s'exécuter dans un environnement IPv6. |
Procédure de préparation de services réseau pour la prise en charge d'IPv6 |
4. Obtention d'un préfixe de site. |
Obtenez un préfixe de site de 48 octets pour votre site auprès de votre FAI ou du registre Internet régional le plus proche. | |
5. Créer un plan d'adressage de sous-réseau. |
Vous devez planifier la topologie globale du réseau IPv6 ainsi que le schéma d'adressage avant de configurer IPv6 sur les différents nœuds de votre réseau. | |
6. Conception d'un plan pour l'utilisation de tunnels. |
Déterminez les routeurs qui vont exécuter les tunnels vers d'autres sous-réseaux ou des réseaux externes. | |
7. Création d'un plan d'adressage pour les entités du réseau. |
Vous devez disposer au préalable d'un plan pour l'adressage des serveurs, des routeurs et des hôtes avant d'effectuer la configuration d'IPv6. | |
8. Développement d'une stratégie de sécurité IPv6. |
Vérifiez les filtres IP, l'architecture de sécurité IP (IPsec), la fonction d'échange de clés Internet (IKE, Internet Key Exchange) et les autres fonctionnalités de sécurité de Oracle Solaris lors de la création de la stratégie de sécurité IPv6. | |
9. (Facultatif) Paramétrage d'une DMZ. |
Pour des raisons de sécurité, vous devez disposer d'un plan d'adressage pour la DMZ et ses entités avant de configurer IPv6. |
Considérations de sécurité relatives à l'implémentation d'IPv6 |
10. Activation de la prise en charge d'IPv6 par les nœuds. |
Configurez IPv6 sur tous les routeurs et les hôtes. | |
11. Activation des services réseau. |
Assurez-vous que les serveurs existants prennent en charge IPv6. |
Principales tâches d'administration TCP/IP (liste des tâches) |
12. Mise à jour des noms de serveurs pour la prise en charge d'IPv6. |
Assurez-vous que les serveurs DNS, NIS et LDAP sont mis à jour avec les nouvelles adresses IPv6. |
Configuration de prise en charge de services d'attribution de noms pour IPv6 |
Les tâches de ce chapitre permettent de planifier des services IPv6 dans un réseau d'entreprise typique. L'illustration suivante correspond au réseau auquel il est fait référence tout au long du chapitre. Le réseau IPv6 proposé peut inclure une partie ou la totalité des liaisons réseau figurant dans l'illustration.
Le scénario de réseau d'entreprise se compose de cinq sous-réseaux disposant d'adresses IPv4. Les liaisons du réseau correspondent directement aux sous-réseaux administratifs. Les quatre réseaux internes sont affichés avec des adresses IPv4 privées de type RFC 1918, ce qui correspond à une solution courante pour le manque d'adresses IPv4. Le schéma d'adressage de ces réseaux internes est comme suit :
Le sous-réseau 1 correspond à l'épine dorsale du réseau interne 192.168.1 .
Le sous-réseau 2 correspond au réseau interne 192.168.2, avec LDAP, sendmail et serveurs DNS.
Le sous-réseau 3 correspond au réseau interne 192.168.3, avec les serveurs NFS de l'entreprise.
Le sous-réseau 4 correspond au réseau interne 192.168.4 qui contient les hôtes des employés de l'entreprise.
Le réseau public externe 172.16.85 fait office de DMZ pour l'entreprise. Ce réseau contient des serveurs Web, des serveurs FTP anonymes et d'autres ressources que l'entreprise propose au monde extérieur. Le routeur 2 exécute un pare-feu et sépare le réseau public 172.16.85 de l'épine dorsale interne. Sur l'autre extrémité de la DMZ, le routeur 1 exécute un pare-feu et fait office de serveur de limites de l'entreprise.
Sur la Figure 4–1, la DMZ publique possède l'adresse privée RFC 1918 172.16.85. Dans le monde réel, la DMZ publique doit disposer d'une adresse IPv4 enregistrée. La plupart des sites IPv4 utilisent une combinaison d'adresses publiques et d'adresses privées RFC 1918. Cependant, lors de l'introduction d'IPv6, le concept d'adresses publiques et privées est modifié. Dans la mesure où IPv6 dispose d'un espace d'adresse beaucoup plus important, les adresses publiques IPv6 s'utilisent à la fois sur les réseaux privés et publics.
Le protocole double pile Oracle Solaris prend en charge à la fois les opérations IPv4 et IPv6. Vous pouvez effectuer des opérations liées à IPv4 pendant et après le déploiement d'IPv6 sur votre réseau.
IPv6 introduit des fonctionnalités supplémentaires dans un réseau existant. Par conséquent, lors du premier déploiement d'IPv6, vous devez vous assurer de ne pas perturber les opérations fonctionnant avec IPv4. Les sujets abordés dans cette section décrivent une méthode pas à pas d'introduction d'IPv6 dans un réseau existant.
La première étape du déploiement IPv6 consiste à déterminer les entités existantes sur votre réseau prenant en charge IPv6. Dans la plupart des cas, la topologie du réseau (les câbles, les routeurs et les hôtes) n'est pas modifiée par l'implémentation d'IPv6. Cependant, dans certains cas, il est nécessaire de préparer le matériel et les applications existantes pour IPv6 avant d'effectuer la configuration des adresses IPv6 sur les interfaces réseau.
Assurez-vous que le matériel de votre réseau peut être mis à niveau vers IPv6. Par exemple, consultez la documentation du fabricant en matière de compatibilité IPv6 en ce qui concerne les classes de matériel suivantes :
routeurs ;
pare-feux ;
serveurs ;
commutateurs.
Toutes les procédures décrites dans cette partie partent du principe qu'il est possible de mettre le matériel à niveau (en particulier les routeurs) vers IPv6.
Certains modèles de routeurs ne permettent pas une mise à niveau vers IPv6. Pour obtenir des informations supplémentaire et une solution au problème, reportez-vous à la section Impossible de mettre à niveau un routeur IPv4 vers IPv6.
Les services réseau IPv4 suivants de la version active de Oracle Solaris sont compatibles avec le protocole IPv6 :
sendmail
NFS
HTTP (Apache 2.x ou Orion)
DNS
LDAP
Le service de messagerie IMAP est compatible uniquement avec IPv4.
Les nœuds configurés pour IPv6 peuvent exécuter des services IPv4. Lors de l'activation d'IPv6, tous les services n'acceptent pas les connexions IPv6. Les services préparés pour IPv6 acceptent les connexions. Les services qui ne le sont pas continuent de fonctionner avec la partie IPv4 de la pile de protocole.
Certains problèmes peuvent survenir après une mise à niveau des services vers IPv6. Pour de plus amples informations, reportez-vous à la section Problèmes survenant après la mise à niveau de services vers IPv6.
Les serveurs étant considérés comme des hôtes IPv6, par défaut, leurs adresses IPv6 sont automatiquement configurées par le protocole de détection des voisins. Cependant, de nombreux serveurs possèdent plusieurs cartes d'interface réseau et il peut s'avérer nécessaire de les retirer en vue de leur maintenance ou de leur remplacement. Lorsqu'une carte d'interface réseau est remplacée, la détection de voisins génère automatiquement un nouvel ID d'interface pour cette carte. Ce comportement pourrait s'avérer problématique pour un serveur.
Par conséquent, il est conseillé de configurer manuellement la partie ID d'interface des adresses IPv6 pour chaque interface du serveur. Pour obtenir des instructions, reportez-vous à la section Procédure de configuration d'un jeton IPv6 spécifié par l'utilisateur. Si le remplacement d'une carte d'interface réseau est nécessaire ultérieurement, l'adresse IPv6 configurée est appliquée à la carte de substitution.
Mettez les services réseau suivants à jour afin qu'ils prennent en charge IPv6 :
serveurs de courrier.
serveurs NIS ;
NFS
LDAP prend en charge IPv6 sans aucune configuration supplémentaire nécessaire.
Assurez-vous que le matériel de votre pare-feu est compatible avec le protocole IPv6.
Reportez-vous à la documentation adéquate pour obtenir des instructions.
Assurez-vous que les autres services de votre réseau ont été préparés pour prendre en charge le protocole IPv6.
Pour de plus amples informations, reportez-vous à la documentation technique et marketing du logiciel.
Si votre site déploie les services suivante, assurez-vous d'avoir pris les mesures adéquates pour ces services :
pare-feux ;
Pensez à renforcer les stratégies en place pour le protocole IPv4 afin qu'elles prennent en charge le protocole IPv6. Pour prendre connaissance de problèmes de sécurité supplémentaires, reportez-vous à la section Considérations de sécurité relatives à l'implémentation d'IPv6.
Messagerie
Vous pouvez envisager d'ajouter les adresses IPv6 de votre serveur de messagerie aux enregistrements MX pour DNS.
DNS
Pour prendre connaissance des considérations spécifiques à DNS, reportez-vous à la section Procédure de préparation de DNS pour la prise en charge d'IPv6.
IPQoS
Utilisez les mêmes stratégies Diffserv que celles utilisées pour le protocole IPv4 sur l'hôte. Pour de plus amples informations, reportez-vous à la section Module de classification.
Contrôlez tout service réseau offert par un nœud avant de convertir ce dernier vers IPv6.
La version de Oracle Solaris actuelle prend en charge la résolution de DNS côté client et côté serveur. Procédez comme suit pour préparer les services DNS à IPv6.
Pour obtenir des informations supplémentaires relatives à la prise en charge de DNS pour IPv6, reportez-vous à la section System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .
Assurez-vous que le serveur DNS effectuant la résolution récursive de nom est double pile (IPv4 et IPv6) ou uniquement compatible avec IPv4.
Dans le serveur DNS, renseignez la base de données DNS avec les enregistrements AAAA de base de données IPv6 dans la zone de transfert.
Les serveurs exécutant plusieurs services critiques requièrent une attention particulière. Assurez-vous du bon fonctionnement du réseau. En outre, tous les services critiques doivent avoir été préparés pour IPv6. Ensuite, ajoutez l'adresse IPv6 du serveur à la base de données DNS.
Ajoutez les enregistrements PTR associés aux enregistrements AAAA dans la zone d'inversion.
Ajoutez des données exclusivement IPv4 ou des données IPv6 et IPv4 à l'enregistrement NS décrivant les zones.
L'implémentation d'IPv6 prend en charge un certain nombre de configurations de tunnel faisant office de mécanismes de transition lors de la migration de votre réseau vers un mélange d'IPv4 et d'IPv6. Les tunnels permettent aux réseaux IPv6 isolés de communiquer. Dans la mesure où Internet exécute essentiellement IPv4, les paquets IPv6 de votre site doivent circuler dans Internet via des tunnels ayant pour destination des réseaux IPv6.
Vous trouverez ici les scénarios les plus courants d'utilisation de tunnels dans la topologie de réseau IPv6 :
Le FAI qui vous fournit des services IPv6 vous permet de créer un tunnel à partir du routeur de bordure du site vers le réseau du FAI. La Figure 4–1 représente un de ces tunnels. Dans ce cas, vous devez exécuter un tunnel manuel IPv6 sur IPv4.
Vous gérez un réseau distribué de grande taille avec connectivité IPv4. Pour connecter les sites distribués utilisant IPv6, vous pouvez exécuter un tunnel automatique 6to4 à partir du routeur de périphérie de chaque sous-réseau.
Il est parfois impossible de mettre un routeur à niveau vers IPv6 dans l'infrastructure de l'entreprise. Dans ce cas, vous pouvez créer un tunnel manuel à travers le routeur IPv4, avec deux routeurs IPv6 en guise d'extrémités.
La section Tâches de configuration de tunnels pour la prise en charge d'IPv6 (liste des tâches) contient les procédures de configuration des tunnels. Pour des informations conceptuelles à propos des tunnels, reportez-vous à la section Tunnels IPv6.
En cas d'introduction d'IPv6 dans un réseau existant, veillez à ne pas compromettre la sécurité du site. Tenez compte des problèmes de sécurité suivants lors de l'implémentation progressive d'IPv6 :
La même quantité de filtrage est requise pour les paquets IPv6 et IPv4.
Les paquets IPv6 sont souvent mis en tunnel via un pare-feu. Par conséquent, implémentez l'un des deux scénarios suivants :
Paramétrez le pare-feu de sorte qu'il inspecte le contenu du tunnel.
Placez un pare-feu IPv6 avec des règles similaires à l'extrémité opposée du tunnel.
Certains mécanismes de transition utilisent des tunnels IPv6 sur UDP sur IPv4. Ces mécanismes peuvent s'avérer dangereux et court-circuiter le pare-feu.
Globalement, il est possible d'atteindre les nœuds IPv6 à partir de l'extérieur du réseau de l'entreprise. Si votre stratégie de sécurité interdit tout accès public, vous devez établir des règles de pare-feu plus strictes. Vous pourriez par exemple configurer un pare-feu avec état.
Ce manuel inclut des fonctionnalités de sécurité qu'il est possible d'utiliser dans une implémentation IPv6.
La fonction d'architecture IPsec (sécurité IP) permet d'obtenir une protection cryptographique des paquets IPv6. Pour plus d'informations, reportez-vous au Chapitre 19Architecture IPsec (présentation).
La fonctionnalité IKE (Internet Key Exchange, échange de clé Internet) permet d'utiliser l'authentification de clé publique pour les paquets IPv6. Pour plus d'informations, reportez-vous au Chapitre 22Protocole IKE (présentation).
Le développement d'un plan d'adressage constitue une des parties les plus importantes de la transition d'IPv4 à IPv6. Cette tâche nécessite les préparatifs suivants :
Vous devez disposer d'un préfixe de site préalablement à la configuration d'IPv6. Le préfixe de site permet de dériver les adresses IPv6 pour tous les nœuds de votre implémentation IPv6. Pour une présentation des préfixes de site, reportez-vous à la section Préfixes d'IPv6.
Tout FAI prenant en charge IPv6 devrait être en mesure de fournir un préfixe de site IPv6 de 48 octets. Si votre FAI ne prend en charge que IPv4, vous pouvez faire appel à un autre FAI pour la prise en charge d'IPv6 tout en conservant votre FAI actuel pour la prise en charge d'IPv4. Dans ce cas, il existe plusieurs solutions au problème. Pour de plus amples informations, reportez-vous à la section Le FAI actuel ne prend pas en charge IPv6.
Si votre entreprise est un FAI, les préfixes de site pour vos clients s'obtiennent auprès du registre Internet adéquat. Pour plus d'informations, reportez-vous au site Internet Assigned Numbers Authority (IANA).
Si votre réseau IPv6 n'est pas entièrement nouveau, basez le schéma de numérotation IPv6 sur la topologie IPv4 existante.
Commencez par mapper les sous-réseaux IPv4 existants vers les sous-réseaux IPv6 équivalents. Par exemple, utilisez les sous-réseaux figurant sur la Figure 4–1. Les sous-réseaux 1 à 4 utilisent l'identification d'adresse privée IPv4 RFC 1918 pour les 16 premiers octets de leurs adresses, en plus des chiffres 1 à 4 qui identifient le sous-réseau. Par exemple, supposons que le préfixe IPv6 2001:db8:3c4d/48 a été assigné au site.
Le tableau suivant illustre le mappage des préfixes IPv4 privés vers les préfixes IPv6.
Préfixe de sous-réseau IPv4 |
Préfixe de sous-réseau IPv6 équivalent |
---|---|
192.168.1.0/24 |
2001:db8:3c4d:1::/64 |
192.168.2.0/24 |
2001:db8:3c4d:2::/64 |
192.168.3.0/24 |
2001:db8:3c4d:3::/64 |
192.168.4.0/24 |
2001:db8:3c4d:4::/64 |
Pour la plupart des hôtes, la configuration automatique d'adresses IPv6 sans état pour leurs interfaces constitue une stratégie adéquate et rapide. Lorsque l'hôte reçoit le préfixe de site en provenance du routeur le plus proche, la détection de voisin génère automatiquement des adresses IPv6 pour chaque interface de l'hôte.
Les serveurs doivent disposer d'adresses IPv6 stables. Si vous ne configurez pas manuellement les adresses IPv6 d'un serveur, une nouvelle adresse IPv6 est configurée automatiquement à chaque fois qu'une carte d'interface réseau est remplacée sur le serveur. Tenez compte des conseils suivants lors de la création d'adresses de serveurs :
Attribuez aux serveurs des ID d'interface significatifs et stables. Vous pouvez par exemple utiliser un schéma de numérotation séquentiel pour les ID d'interface. Par exemple, l'interface interne du serveur LDAP dans la Figure 4–1 pourrait devenir 2001:db8:3c4d:2::2.
Si vous ne renommez pas régulièrement votre réseau IPv4, vous pouvez également utiliser les adresses IPv4 des routeurs et serveurs en tant qu'ID d'interface. Dans la Figure 4–1, on suppose que l'interface du routeur 1 vers la DMZ a pour adresse IPv4 123.456.789.111 . Vous pouvez convertir l'adresse IPv4 vers le format hexadécimale et utiliser le résultat de la conversion en tant qu'ID d'interface. Le nouvel ID d'interface serait ::7bc8:156F.
Cette approche est applicable uniquement si vous êtes propriétaire de l'adresse IPv4 enregistrée, non pas si vous l'avez obtenue auprès d'un FAI. Si vous utilisez une adresse IPv4 qui vous a été fournie par un FAI, vous créez une dépendance qui risque d'entraîner des problèmes en cas de changement de FAI.
En raison du nombre limité d'adresses IPv4, un concepteur de réseau devait auparavant se demander s'il devait utiliser des adresses globales enregistrées ou des adresses privées RFC 1918. Cependant, la notion d'adresses IPv4 privées et publiques ne s'applique pas aux adresses IPv6. Vous pouvez utiliser des adresses globales unicast incluant le préfixe de site, sur toutes les liaisons du réseau, DMZ publique incluse.
L'administration réseau TCP/IP comporte deux étapes. La première correspond à l'assemblage matériel. La seconde consiste à configurer les démons, fichiers et services de mise en œuvre du protocole TCP/IP.
Le présent chapitre décrit la configuration TCP/IP sur un réseau implémentant les services et l'adressage IPv4.
De nombreuses tâches abordées dans ce chapitre s'appliquent aussi bien aux réseaux IPv4 uniquement qu'aux réseaux IPv6. En cas de différence des étapes de configuration des deux formats d'adressage, les instructions se rapportent au format IPv4. Des renvois aux tâches IPv6 correspondantes décrites au Chapitre 7Configuration d'un réseau IPv6 (tâches) sont inclus.
Le présent chapitre contient les informations suivantes :
Les changements apportés dans Solaris 10 8/07 sont les suivants :
La configuration et la gestion du routage peuvent s'effectuer à l'aide de l'utilitaire SMF (Service Management Facility, utilitaire de gestion de service) et non plus uniquement à l'aide de la commande routeadm. Pour plus d'informations, reportez-vous aux procédures et exemples décrits à la section Transfert et routage de paquets sur des réseaux IPv4 et à la page de manuel routeadm(1M).
Le fichier /etc/inet/ipnodes est devenu obsolète. Comme expliqué dans chaque procédure, utilisez le chemin /etc/inet/ipnodes uniquement pour les versions précédentes de Oracle Solaris 10.
Avant de configurer TCP/IP, effectuez les tâches répertoriées dans le tableau suivant. Le tableau comprend la description des actions de chaque tâche et la section de la documentation actuelle dans laquelle les étapes permettant d'effectuer ces tâches sont décrites en détails.
Tâche |
Description |
Voir |
---|---|---|
1. Conception de la topologie réseau |
Choisissez la configuration physique du réseau. |
Présentation de la topologie réseau et Topologie du système autonome IPv4 |
2. Obtention d'un numéro réseau via l'ISP (Internet Service Provider, fournisseur de services Internet) ou RIR (Regional Internet Registry, organisme d'enregistrement Internet local) |
Obtenez un numéro réseau enregistré permettant les communications externes des systèmes de votre site. | |
3. Programmation du plan d'adressage IPv4 du réseau Incluez l'adressage de sous-réseau, le cas échéant. |
Élaborez le plan d'adressage à partir du numéro réseau. | |
4. Assemblage du matériel réseau conformément à la topologie réseau Assurez-vous du bon fonctionnement du matériel. |
Configurez les systèmes, médias réseau, routeurs, commutateurs, hubs et passerelles exposés dans la conception de la topologie réseau. |
Manuels du matériel et Présentation de la topologie réseau. |
5. Assignation des adresses IPv4 et des noms d'hôtes à tous les systèmes du réseau |
Assignez les adresses IPv4 pendant ou après l'installation de Oracle Solaris dans les fichiers correspondants. |
Conception du schéma d'adressage IPv4 et Modification de l'adresse IPv4 et des autres paramètres de configuration réseau |
6. Exécution du logiciel de configuration requis par les routeurs et les interfaces réseau, le cas échéant |
Configurez les routeurs et les hôtes multiréseaux. |
Planification des routeurs du réseau et Configuration d'un routeur IPv4 pour toute information sur les routeurs. |
7. Identification du service de noms ou du service d'annuaire utilisé sur le réseau NIS, LDAP, DNS ou fichiers locaux. |
Configurez le service de noms et/ou le service d'annuaire sélectionné. |
System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) . |
8. Sélection de noms de domaine pour le réseau, le cas échéant |
Sélectionnez un nom de domaine pour votre réseau et enregistrez-le auprès de l'InterNIC. |
System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) |
En tant qu'administrateur réseau, vous configurez TCP/IP pour une exécution sur les hôtes et sur les routeurs (le cas échéant). Les informations de configuration utilisées par ces systèmes peuvent se trouver dans des fichiers du système local ou dans des fichiers résidant sur d'autres systèmes du réseau. Les informations de configuration requises sont répertoriées ci-dessous :
nom d'hôte de chaque système ;
adresse IP de chaque système ;
nom de domaine auquel chaque système appartient ;
Routeur par défaut
masque de réseau IPv4 utilisé sur le réseau de chaque système.
Un système qui obtient les informations de configuration TCP/IP à partir de fichiers locaux fonctionne en mode Fichiers locaux. Un système qui obtient les informations de configuration TCP/IP à partir d'un serveur réseau à distance fonctionne en mode Client réseau.
Pour s'exécuter en mode Fichiers locaux, un système doit posséder des copies locales des fichiers de configuration TCP/IP. Ces fichiers sont décrits à la section Fichiers de configuration TCP/IP. L'attribution d'un disque dédié, sans faire figure de configuration requise, est toutefois recommandée pour le système.
La plupart des serveurs doivent s'exécuter en mode Fichiers locaux. Cette exigence s'applique aux serveurs suivants :
serveurs de configuration réseau ;
serveurs NFS ;
serveurs de noms fournissant les services NIS, LDAP ou DNS ;
serveurs de courrier.
Les routeurs doivent également s'exécuter en mode Fichiers locaux.
Les systèmes fonctionnant exclusivement en tant que serveurs d'impression ne sont pas tenus de s'exécuter en mode Fichiers locaux. L'exécution des hôtes en mode Fichiers locaux est fonction de la taille du réseau.
Pour les réseaux de taille réduite, il est facile de gérer le volume de travail consacré à la maintenance de ces fichiers. Dans le cas d'un réseau desservant des centaines d'hôtes, la tâche est plus complexe, même si le réseau est divisé en plusieurs sous-domaines d'administration. Par conséquent, le mode Fichiers locaux se révèle moins efficace dans le cadre de réseaux de grande taille. Toutefois, le mode Fichiers locaux s'appliquent aux routeurs et serveurs, qui doivent pouvoir fonctionner de manière indépendante.
Les serveurs de configuration réseau fournissent les informations de configuration TCP/IP aux hôtes configurés en mode Client réseau. Ces serveurs prennent en charge trois protocoles d'initialisation :
RARP – le protocole RARP (Reverse Address Resolution Protocol) mappe les adresses Ethernet (48 bits) vers les adresses IPv4 (32 bits). En d'autres termes, il réalise l'opération inverse du protocole ARP. Lorsque vous utilisez RARP sur un serveur de configuration réseau, les hôtes exécutés en mode Client réseau obtiennent leur adresses IP et leurs fichiers de configuration TCP/IP à partir du serveur. Le démon in.rarpd active les services RARP. Pour plus d'informations, reportez-vous à la page de manuel in.rarpd(1M).
TFTP – Le protocole TFTP (Trivial File Transfer Protocol) transfère les fichiers d'un système distant à l'autre. Le démon in.tftpd exécute les services TFTP, qui autorisent le transfert de fichiers entre les serveurs de configuration réseau et leurs clients réseau. Pour plus d'informations, reportez-vous à la page de manuel in.tftpd(1M).
Bootparams – Le protocole Bootparams fournit les paramètres d'initialisation, requis par les clients chargés d'initialiser le réseau. Le démon rpc.bootparamd exécute ces services. Pour plus d'informations, reportez-vous à la page de manuel bootparamd(1M).
Les serveurs de configuration réseau peuvent également être configurés en tant que serveurs de fichiers NFS.
Si vous configurez des hôtes en tant que clients réseau, vous devez aussi configurer au moins un système sur le réseau en tant que serveur de configuration réseau. En cas de division du réseau en sous-réseaux, vous devez configurer au moins un serveur de configuration réseau pour chaque sous-réseau doté de clients réseau.
Les hôtes recevant leurs informations de configuration d'un serveur de configuration réseau fonctionnent en mode Client réseau. Les systèmes configurés en tant que clients réseau ne requièrent aucune copie locale des fichiers de configuration TCP/IP.
Le mode Client réseau simplifie la gestion des réseaux de grande taille. Il réduit le nombre de tâches de configuration à effectuer sur chaque hôte et garantit la conformité de tous les systèmes du réseau aux mêmes normes de configuration.
Le mode Client réseau peut être configuré sur tous les types d'ordinateur. Par exemple, vous pouvez configurer le mode client réseau sur des systèmes autonomes.
Les configurations ne se limitent pas aux modes Fichiers locaux uniquement ou Clients réseau uniquement. Les routeurs et les clients doivent toujours être configurés en mode local. En revanche, la configuration des hôtes peut combiner les modes Fichiers locaux et Clients réseau.
La Figure 5–1 illustre les hôtes d'un réseau fictif présentant le numéro réseau 192.9.200. Le serveur de configuration du réseau s'intitule sahara. Les hôtes tenere et nubian possèdent des disques qui leur sont propres et s'exécutent en mode Fichiers locaux. L'hôte faiyum dispose également d'un disque, mais s'exécute en mode Clients réseau
Enfin, le système timbuktu est configuré comme un routeur. Il inclut deux interfaces réseau. La première, intitulée timbuktu, appartient au réseau 192.9.200. La seconde, timbuktu-201, appartient au réseau 192.9.201 . Les deux réseaux résident dans le domaine d'organisation deserts.worldwide.com Le domaine utilise des fichiers locaux comme service de nom.
Si vous remplacez un réseau sans sous-réseau par un réseau avec sous-réseau, suivez la procédure ci-dessous.
Les informations contenues dans cette section ne s'appliquent qu'aux sous-réseaux IPv4. Pour plus d'informations sur la planification des sous-réseaux IPv6, reportez-vous aux sections Préparation de la topologie réseau pour une prise en charge d'IPv6 et Création d'un schéma de numérotation pour les sous-réseaux.
Le tableau suivant répertorie la liste des tâches permettant d'ajouter un sous-réseau au réseau en cours. Le tableau comprend la description des actions de chaque tâche et la section de la documentation actuelle dans laquelle les étapes permettant d'effectuer ces tâches sont décrites en détails.
Tâche |
Description |
Voir |
---|---|---|
1. Identification des besoins en sous-réseaux de la topologie réseau |
Décidez de la nouvelle topologie de sous-réseau, notamment de l'emplacement des routeurs et hôtes sur les sous-réseaux. |
Planification des routeurs du réseau, Qu'est-ce que la création de sous-réseaux ? et Classes de réseau |
2. Assignation des adresses IP avec le nouveau numéro de sous-réseau aux systèmes qui doivent devenir membres du sous-réseau. |
Configurez les adresses IP utilisant le nouveau numéro de sous-réseau lors de l'installation de Oracle Solaris ou ultérieurement dans le fichier /etc/hostname.interface. | |
3. Configuration du masque du sous-réseau sur tous les systèmes potentiels du sous-réseau |
Dans le cadre d'une configuration manuelle des clients réseau, modifiez le fichier /etc/inet/netmasks. Dans le cas contraire, indiquez le masque de réseau au programme d'installation Oracle Solaris. |
Base de données netmasks et Création du masque de réseau des adresses IPv4 |
4. Modification des bases de données réseau par rapport aux nouvelles adresses IP de tous les systèmes du sous-réseau |
Modifiez /etc/inet/hosts et, pour Solaris 10 11/06 ou versions antérieures,/etc/inet/ipnodes, sur tous les hôtes afin de prendre en compte les nouvelles adresses hôte. | |
5. Réinitialisation de tous les systèmes |
Le tableau suivant répertorie les tâches supplémentaires à effectuer une fois que vous êtes passé d'une configuration réseau sans sous-réseaux à un réseau utilisant des sous-réseaux. Le tableau comprend la description des actions de chaque tâche et la section de la documentation actuelle dans laquelle les étapes permettant d'effectuer ces tâches sont décrites en détails.
Tâche |
Description |
Voir |
---|---|---|
Configuration d'un hôte en mode Fichiers locaux |
Modification des fichiers nodename, hostname, hosts, defaultdomain, defaultrouter et netmasks | |
Configuration d'un serveur de configuration réseau |
Activation du démon in.tftp et modification des fichiers hosts, ethers et bootparams | |
Configuration d'un hôte en mode Client réseau |
Création du fichier hostname, modification du fichier hosts et suppression des fichiers nodename et defaultdomain, s'ils existent | |
Spécification de la stratégie de routage du client réseau |
Choix entre un routage statique ou dynamique sur l'hôte |
Activation du routage statique sur un hôte à interface unique et Activation du routage dynamique sur un hôte à interface unique |
Modification de la configuration réseau existante |
Modification du nom d'hôte, de l'adresse IP et des autres paramètres définis lors de l'installation ou ultérieurement. |
Modification de l'adresse IPv4 et des autres paramètres de configuration réseau |
L'installation logicielle réseau s'effectue en parallèle avec celle du logiciel du système d'exploitation. C'est lors de cette étape que vous devez stocker certains paramètres de configuration IP dans les fichiers adéquats de sorte à ce qu'ils soient lus lors de l'initialisation.
Le processus de configuration réseau implique la création ou la modification des fichiers de configuration réseau. L'accès aux informations de configuration par le noyau du système est soumis à certains facteurs. Le stockage manuel (mode Fichiers locaux) ou l'acquisition sur le serveur de configuration réseau (mode Client réseau) conditionne la disponibilité.
Les paramètres fournis lors de la configuration réseau sont répertoriés ci-dessous.
Adresse IP de chaque interface réseau sur tous les systèmes.
Noms d'hôtes de chaque système sur le réseau. Vous pouvez saisir le nom d'hôte dans un fichier local ou une base de données de service de noms.
Le nom de domaine NIS, LDAP ou DNS dans lequel le système réside, le cas échéant.
Les adresses de routeur par défaut. Vous devez fournir cette information lorsqu'un routeur unique est connecté à chaque réseau de la topologie. Vous devez également la fournir lorsque les routeurs n'utilisent pas de protocoles de routage tels que RDISC (Router Discovery Server Protocol) ou RIP (Router Information Protocol). Pour plus d'informations sur les routeurs par défaut, reportez-vous à la section Transfert et routage de paquets sur des réseaux IPv4. Le Tableau 5–1 présente la liste des protocoles de routage pris en charge par Oracle Solaris.
Le masque de sous-réseau (requis uniquement pour les réseaux avec sous-réseaux).
Lorsque le programme d'installation de Oracle Solaris détecte plusieurs interfaces sur le système, vous pouvez éventuellement configurer des interfaces supplémentaires lors de l'installation. Pour obtenir l'ensemble des instructions, reportez-vous au Guide d’installation d’Oracle Solaris 10 9/10 : installations de base.
Ce chapitre contient des informations sur la création et la modification des fichiers locaux de configuration. Pour plus d'informations sur l'utilisation de bases de données de service de noms, reportez-vous au document System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .
Procédez comme suit pour configurer TCP/IP sur un hôte exécuté en mode Fichiers locaux.
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Allez dans le répertoire /etc.
Vérifiez le nom d'hôte défini dans le fichier /etc/nodename.
Lorsque vous spécifiez le nom d'hôte d'un système lors de l'installation Oracle Solaris, ce dernier est enregistré dans le fichier /etc/nodename. Veillez à ce que l'entrée du nom d'hôte corresponde au nom d'hôte correct pour le système.
Vérifiez qu'un fichier /etc/hostname.interface existe pour chaque interface réseau sur le système.
Pour connaître la syntaxe et trouver des informations de base sur le fichier /etc/hostname. interface, reportez-vous à la section Principes de base de gestion des interfaces physiques.
Lorsque vous exécutez le programme d'installation de Oracle Solaris, vous devez au moins configurer une interface lors de l'installation. La première interface configurée automatiquement devient l'interface réseau principale. Le programme d'installation crée un fichier /etc/hostname. interface pour l'interface du réseau principal et toute autre interface éventuellement configurée lors de l'installation.
Si vous configurez des interfaces supplémentaires lors de l'installation, assurez-vous que chacune d'elles dispose d'un fichier /etc/hostname. interface. Vous ne devez pas configurer plusieurs interfaces lors de l'installation de Oracle Solaris. Toutefois, si vous souhaitez ajouter d'autres interfaces au système plus tard, vous devez les configurer manuellement.
Pour connaître la procédure de configuration manuelle des interfaces, reportez-vous à la section Gestion des interfaces dans Solaris 10 3/05 ou à la section Configuration d'une interface physique après l'installation du système pour les versions 10 1/06 et suivantes de Solaris.
Pour Solaris 10 11/06 et les versions précédentes, assurez-vous que les entrées du fichier /etc/inet/ipnodes sont à jour.
Le programme d'installation Oracle Solaris 10 crée le fichier /etc/inet/ipnodes. Celui-ci contient le nom de nœud ainsi que l'adresse IPv4 et IPv6 de chaque interface configurée lors de l'installation, le cas échéant.
Utilisez le format d'entrée suivant dans le fichier /etc/inet/ipnodes :
IP-address node-name nicknames... |
Les pseudos correspondent à des noms supplémentaires désignant une interface.
Assurez-vous que les entrées du fichier /etc/inet/hosts sont à jour.
Le programme d'installation Oracle Solaris crée des entrées pour l'interface réseau principale, l'adresse loopback et toute interface supplémentaire configurée lors de l'installation, le cas échéant.
Assurez-vous que les entrées existantes du fichier /etc/inet/hosts sont à jour.
(Facultatif) Ajoutez les adresses IP et les noms correspondants des interfaces réseau ajoutées à l'hôte local après l'installation.
(Facultatif) Ajoutez l'adresse ou les adresses IP du serveur de fichier (pour le montage NFS du système de fichiers /usr).
Tapez le nom de domaine complet de l'hôte dans le fichier /etc/defaultdomain.
Par exemple, si l'hôte tenere fait partie du domaine deserts.worldwide.com, vous devez taper deserts.worldwide.com dans le fichier /etc/defaultdomain . Pour plus d'informations, reportez-vous au Fichier /etc/defaultdomain.
Tapez le nom du routeur dans le fichier /etc/defaultrouter.
Pour plus d'informations sur ce fichier, reportez-vous à la section Fichier /etc/defaultrouter.
Tapez le nom du routeur par défaut et ses adresses IP dans le fichier /etc/inet/hosts.
La section Configuration des hôtes en mode Client réseau contient des options de routage supplémentaires. Vous pouvez appliquer ces options à une configuration en mode Fichiers locaux.
Ajoutez le masque de votre réseau, le cas échéant :
Si l'hôte obtient son adresse IP du serveur DHCP, il n'est pas nécessaire de spécifier le masque de réseau.
Si vous avez défini un serveur NIS sur le même réseau que ce client, vous pouvez ajouter les informations du fichier netmask dans la base de données appropriée sur le serveur.
Dans les autres conditions, effectuez la procédure suivante :
Tapez le numéro et le masque de réseau dans le fichier /etc/inet/netmasks .
Utilisez le format suivant :
network-number netmask |
Par exemple, pour le numéro de réseau de Classe C 192.168.83, vous devez taper :
192.168.83.0 255.255.255.0 |
Pour les adresses CIDR, remplacez le préfixe réseau par la représentation décimale avec points équivalente. Les préfixes de réseau et leurs équivalents décimaux à points sont répertoriés dans le Tableau 2–3. Par exemple, pour exprimer le préfixe réseau CIDR 192.168.3.0/22, tapez ce qui suit :
192.168.3.0 255.255.252.0 |
Modifiez l'ordre de recherche des masques de réseau dans /etc/nsswitch.conf pour que la recherche porte en premier sur les fichiers locaux.
netmasks: files nis |
Vous trouverez des informations sur la configuration des serveurs d'installation et des serveurs d'initialisation dans le guide Guide d’installation d’Oracle Solaris 10 9/10 : installations de base.
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Modifiez le répertoire root (/) du futur serveur de configuration réseau.
Activez le démon in.tftpd en créant le répertoire /tftpboot :
# mkdir /tftpboot |
Cette commande configure le système en tant que serveur RARP, bootparams et TFTP.
Créez un lien symbolique vers le répertoire.
# ln -s /tftpboot/. /tftpboot/tftpboot |
Activez la ligne tftp du fichier /etc/inetd.conf.
Assurez-vous que l'entrée est la suivante :
tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot |
Cette ligne empêche in.tftpd d'extraire un fichier autre que ceux figurant dans /tftpboot.
Modifiez la base de données hosts.
Ajoutez les noms d'hôtes et les adresses IP de chaque client sur le réseau.
Modifiez la base de données ethers.
Créez des entrées pour chaque hôte du réseau qui s'exécute en mode Client réseau.
Modifiez la base de données bootparams.
Voir Base de données bootparams. Utilisez une entrée générique ou créez une entrée pour chaque hôte exécuté en mode Client réseau.
Convertissez l'entrée /etc/inetd.conf en un fichier manifeste de service SMF (Service Management Facility) et activez le service obtenu :
# /usr/sbin/inetconv |
Assurez-vous que in.tftpd fonctionne correctement.
# svcs network/tftp/udp6 |
La sortie que vous devez recevoir ressemble à ce qui suit :
STATE STIME FMRI online 18:22:21 svc:/network/tftp/udp6:default |
Le démon in.tftpd est géré par SMF (Service Management Facility). La commande svcadm permet d'effectuer les opérations de gestion sur in.tftpd (par exemple, l'activation, la désactivation ou le redémarrage). L'initiation et la réinitialisation du service s'effectue par l'intermédiaire de la commande inetd . Utilisez la commande inetadm pour modifier la configuration et afficher les informations de configuration pour in.tftpd. La commande svcs permet d'interroger l'état du service. Pour une présentation de l'utilitaire SMF (Service Management Facility), reportez-vous au Chapitre 18, Managing Services (Overview) du System Administration Guide: Basic Administration.
Les clients réseau reçoivent leurs informations de configuration des serveurs de configuration réseau. Par conséquent, avant de configurer un hôte en tant que client réseau, assurez-vous de configurer au moins un serveur de configuration pour le réseau.
Pour configurer les hôtes en mode Client réseau, suivez la procédure ci-dessous.
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Recherchez le fichier nodename dans le répertoire /etc.
S'il existe, supprimez-le.
La suppression de /etc/nodename oblige le système à utiliser le programme hostconfig pour obtenir le nom d'hôte, le nom de domaine et les adresses du routeur auprès du serveur de configuration réseau. Voir Configuration des systèmes sur le réseau local.
Créez le fichier /etc/hostname. interface, si ce n'est pas déjà fait.
Veillez à ce qu'il soit vide. Un fichier /etc/hostname.interface vide oblige le système à acquérir l'adresse IPv4 auprès du serveur de configuration réseau.
Assurez-vous que le fichier /etc/inet/hosts contient uniquement le nom localhost et l'adresse IP de l'interface réseau loopback.
# cat /etc/inet/hosts # Internet host table # 127.0.0.1 localhost |
L'adresse IP de l'interface loopback IPv4 est 127.0.0.1.
Pour plus d'informations, reportez-vous à la section Adresse loopback. Le fichier ne doit pas contenir l'adresse IP ni le nom d'hôte de l'hôte local (interface réseau principale).
Vérifiez qu'il existe un fichier /etc/defaultdomain.
S'il existe, supprimez-le.
Le programme hostconfig définit automatiquement le nom de domaine. Pour remplacer le nom de domaine défini par hostconfig, saisissez le nom de domaine de substitution dans le fichier /etc/defaultdomain.
Assurez-vous que les chemins de recherche dans le fichier /etc/nsswitch.conf du client sont conformes aux exigences de service de noms de votre réseau.
Cette section décrit la procédure de modification de l'adresse IPv4, du nom d'hôte et des autres paramètres réseau d'un système déjà installé. Cette procédure permet de modifier l'adresse IP d'un serveur ou d'un système autonome en réseau. Elle ne s'applique pas aux appareils ou clients réseau. Cette procédure entraîne la création d'une configuration qui sera conservée après les réinitialisations du système.
Les instructions s'appliquent explicitement à la modification de l'adresse IPv4 de l'interface réseau principale. Pour ajouter une autre interface au système, reportez-vous à la section Configuration d'une interface physique après l'installation du système.
Dans la plupart des cas, les étapes suivantes font appel à la numérotation décimale avec points IPv4 classique afin de spécifier l'adresse IPv4 et le masque de sous-réseau. Vous pouvez aussi indiquer l'adresse IPv4 à l'aide de la numérotation CIDR dans tous les fichiers pertinents. La section Adresses IPv4 au format CIDR présente la numérotation CIDR.
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Pour Solaris 10 11/06 et versions précédentes uniquement, modifiez l'adresse IP dans le fichier /etc/inet/ipnodes ou la base de données ipnodes équivalente.
Pour chaque adresse IP que vous ajoutez au système, utilisez la syntaxe suivante :
IP-address host-name, nicknames IP-address interface-name, nicknames |
La première entrée doit contenir l'adresse IP de l'interface réseau principale ainsi que le nom d'hôte du système. Si vous le souhaitez, vous pouvez ajouter des pseudos au nom d'hôte. Lorsque vous ajoutez des interfaces physiques supplémentaires à un système, créez des entrées dans /etc/inet/ipnodes pour les adresses IP et les noms associés de ces interfaces.
Si le nom d'hôte du système doit changer, modifiez l'entrée de nom d'hôte dans le fichier /etc/nodename.
Modifiez l'adresse IP et, le cas échéant, le nom d'hôte dans le fichier /etc/inet/hosts ou la base de données équivalente hosts.
Modifiez l'adresse IP dans le fichier /etc/hostname. interface pour l'interface réseau principale.
Utilisez l'un des éléments suivants en tant qu'entrée de l'interface réseau principale dans le fichier /etc/hostnameinterface :
Adresse IPv4 exprimée dans le format décimal avec points classique
Utilisez la syntaxe suivante :
IPv4 address subnet mask |
L'entrée de masque de réseau est facultative. Si elle n'est pas spécifiée, le masque de réseau par défaut est utilisé.
Voici un exemple concret :
# vi hostname.eri0 10.0.2.5 netmask 255.0.0.0 |
Adresse IPv4, exprimée en numérotation CIDR, si elle est appropriée à la configuration réseau
IPv4 address/network prefix |
Voici un exemple concret :
# vi hostname.eri0 10.0.2.5/8 |
Le préfixe CIDR désigne le masque de réseau approprié à l'adresse IPv4. Par exemple, le /8 ci-dessus indique le masque de réseau 255.0.0.0.
Nom d'hôte
Pour utiliser le nom d'hôte du système dans le fichier /etc/hostname.interface, assurez-vous que le nom d'hôte et l'adresse IPv4 associée figurent également dans la base de données hosts.
En cas de changement du masque de sous-réseau, modifiez les entrées de sous-réseau dans les fichiers suivants :
/etc/netmasks
(Facultatif) /etc/hostname.interface
En cas de changement de l'adresse de sous-réseau, remplacez l'adresse IP du routeur par défaut dans /etc/defaultrouter par celle du routeur par défaut du nouveau sous-réseau.
Redémarrez le système.
# reboot -- -r |
Cet exemple illustre la modification des paramètres réseau suivants d'un système déplacé vers un sous-réseau différent :
L'adresse IP de l'interface réseau principale eri0 passe de 10.0.0.14 à 192.168.55.14 .
Le nom d'hôte passe de myhost à mynewhostname.
Le masque de réseau passe de 255.0.0.0 à 255.255.255.0.
L'adresse de routeur par défaut devient 192.168.55.200 .
Vérifiez l'état actuel du système :
# hostname myhost # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.14 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 |
Ensuite, modifiez l'adresse IP et le nom d'hôte du système eri0 dans les fichiers concernés :
# vi /etc/nodename mynewhostname In Solaris 10 11/06 and earlier Solaris 10 releases only, do the following: # vi /etc/inet/ipnodes 192.168.55.14 mynewhostname #moved system to 192.168.55 net # vi /etc/inet/hosts # # Internet host table # 127.0.0.1 localhost 192.168.55.14 mynewhostname loghost # vi /etc/hostname.eri0 192.168.55.14 netmask 255.255.255.0 |
Enfin, modifiez le masque de réseau et l'adresse IP du routeur par défaut.
# vi /etc/netmasks. . . 192.168.55.0 255.255.255.0 # vi /etc/defaultrouter 192.168.55.200 #moved system to 192.168.55 net # |
Après avoir apporté ces modifications, réinitialisez le système.
# reboot -- -r |
Assurez-vous que la configuration que vous venez de définir est conservée après la réinitialisation.
# hostname mynewhostname # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.55.14 netmask ffffff00 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 |
Cet exemple illustre la modification du nom d'hôte, de l'adresse IP de l'interface réseau principale et du masque de sous-réseau pour la session actuelle uniquement. Lorsque vous réinitialisez le système, l'adresse IP et le masque de sous-réseau précédents sont rétablis. L'adresse IP de l'interface réseau principale eri0 passe de 10.0.0.14 à 192.168.34.100 .
# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.14 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 # ifconfig eri0 192.168.34.100 netmask 255.255.255.0 broadcast + up # vi /etc/nodename mynewhostname # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.34.100 netmask ffffff00 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 # hostname mynewhostname |
Cet exemple illustre la modification du nom d'hôte et de l'adresse IP pour la session actuelle à l'aide de la numérotation CIDR. Lorsque vous réinitialisez le système, l'adresse IP et le masque de sous-réseau précédents sont rétablis. L'adresse IP de l'interface réseau principale eri0 passe de 10.0.0.14 à 192.168.6.25/27.
# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.14 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 # ifconfig eri0 192.168.6.25/27 broadcast + up # vi /etc/nodename mynewhostname # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.06.25 netmask ffffffe0 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 # hostname mynewhostname |
Lorsque vous utilisez la numérotation CIDR pour l'adresse IPv4, il n'est pas nécessaire d'indiquer le masque de réseau. ifconfig fait appel à la désignation de préfixe de réseau pour identifier le masque de réseau. Par exemple, pour le réseau 192.168.6.0/27, ifconfig définit le masque ffffffe0. Si vous avez utilisé la désignation de préfixe /24 plus courante, le masque de réseau obtenu est ffffff00. L'utilisation de la désignation de préfixe /24 revient à spécifier le masque de réseau 255.255.255.0 dans ifconfig lors de la configuration d'une nouvelle adresse IP.
Pour modifier l'adresse IP d'une interface autre que l'interface réseau principale, reportez-vous au guide System Administration Guide: Basic Administration (en anglais) et à la section Configuration d'une interface physique après l'installation du système.
Cette section contient les procédures et exemples illustrant la configuration du transfert et du routage des routeurs et des hôtes sur les réseaux IPv4.
Le transfert de paquet correspond à la méthode élémentaire de partage des informations d'un système à l'autre sur un réseau. Les paquets sont transférés entre l'interface source et l'interface cible, en principe sur deux systèmes différents. Lorsque vous exécutez une commande ou que vous envoyez un message vers une interface non locale, le système transfère ces paquets sur le réseau local. L'interface avec l'adresse IP cible spécifiée dans les en-têtes de paquet récupère alors les paquets à partir du réseau local. Lorsque l'adresse cible ne figure pas sur le réseau local, les paquets sont alors transférés vers le réseau adjacent suivant, également appelé saut. Par défaut, la transmission des paquets est automatiquement configurée lors de l'installation de Oracle Solaris.
Le routage désigne le processus selon lequel les systèmes identifient la destination d'un paquet. Les protocoles de routage d'un système "détectent" les autres systèmes sur le réseau local. Lorsque le système source et le système cible résident sur le même réseau local, le chemin emprunté par les paquets pour se rendre de l'un à l'autre s'appelle une route directe. Si les paquets doivent effectuer au moins un saut au-delà du système source, le chemin reliant le système source et le système cible s'appelle une route indirecte. Les protocoles de routage prennent connaissance du chemin vers une interface cible et conserve des données sur les routes connues dans la table de routage du système.
Les routeurs sont des systèmes spécialement configurés et reliés à plusieurs réseaux locaux par l'intermédiaire de plusieurs interfaces physiques. Par conséquent, un routeur peut transférer des paquets au-delà du réseau local domestique, qu'il utilise ou non un protocole de routage. Pour plus d'informations sur le transfert de paquets par les routeurs, reportez-vous à la section Planification des routeurs du réseau.
Les protocoles de routage gèrent les opérations de routage sur un système. L'échange d'informations avec les hôtes leur permet de conserver des routes connues vers les réseaux distants. Les routeurs et les hôtes peuvent exécuter des protocoles de routage. Les protocoles de routage sur l'hôte communiquent avec les démons de routage sur d'autres routeurs et hôtes. Ces protocoles aident l'hôte à identifier la destination des paquets. Lorsque les interfaces réseau sont activées, le système communique automatiquement avec les démons de routage. Ceux-ci contrôlent les routeurs sur le réseau et signalent les adresses des routeurs aux hôtes sur le réseau local. Certains protocoles de routage conservent également des statistiques permettant de mesurer les performances du routage. Contrairement au transfert de paquets, vous devez configurer de manière explicite le routage sur un système Oracle Solaris.
Cette section décrit les procédures de gestion du transfert de paquet et du routage sur les hôtes et routeurs IPv4. Pour plus d'informations sur le routage sur un réseau IPv6, reportez-vous à la section Configuration d'un routeur IPv6.
Les protocoles de routage sont classés en protocoles IGP (Interior Gateway Protocol, protocole de passerelle intérieure), EGP (Exterior Gateway Protocol, protocole de passerelle extérieure) ou une combinaison des deux. Les protocoles de passerelle intérieure échangent des informations de routage entre routeurs de réseaux sous contrôle administratif commun. Dans la topologie de réseau de la Figure 5–3, les routeurs exécutent un IGP dans le cadre de l'échange d'informations de routage. Les protocoles de passerelle extérieure activent le routeur reliant le réseau Internet local à un réseau extérieur en vue d'échanger des informations avec un routeur sur un réseau externe. Par exemple, le routeur reliant un réseau d'entreprise à un fournisseur de services Internet (ISP, Internet Service Provider) échange les informations de routage avec son homologue ISP via un EGP. L'EGP BGP (Border Gateway Protocol) permet de transporter des informations de routage entre différents IGP et organisations.
Le tableau suivant contient des informations sur les protocoles de routage Oracle Solaris et les emplacements de la documentation correspondant à chaque protocole.
Tableau 5–1 Protocoles de routage Oracle Solaris
Protocole |
Démon associé |
Description |
Voir |
---|---|---|---|
RIP (Routing Information Protocol) |
in.routed |
IGP acheminant les paquets IPv4 et gérant une table de routage | |
Détection de routeur ICMP (Internet Control Message Protocol) |
in.routed |
Permet aux hôtes de détecter la présence d'un routeur sur le réseau |
Activation du routage statique sur un hôte à interface unique et Activation du routage dynamique sur un hôte à interface unique |
Protocole RIPng (Routing Information Protocol, next generation, protocole d'informations de routage, nouvelle génération) |
in.ripngd |
IGP acheminant les paquets IPv6 et gérant une table de routage | |
Protocole ND (Neighbor Discovery) |
in.ndpd |
Signale la présence d'un routeur IPv6 et détecte les hôtes IPv6 sur un réseau |
Oracle Solaris 10 prend également en charge la suite de protocole de routage Quagga Open Source. Bien que ne faisant pas partie de la principale distribution Oracle Solaris, ces protocoles sont disponibles à partir du disque de consolidation SFW. Le tableau suivant répertorie les protocoles Quagga :
Tableau 5–2 Protocoles Quagga OpenSolaris
Protocole |
Démon |
Description |
---|---|---|
Protocole RIP |
ripd |
Protocole IGP à vecteur de distance IPv4 qui achemine les paquets IPv4 et signale sa table de routage aux routeurs adjacents. |
RIPng |
ripngd |
Protocole IGP à vecteur de distance IPv6 qui achemine les paquets IPv4 et gère une table de routage. |
Protocole OSPF (Open Shortest Path First) |
ospfd |
Protocole IGP d'état des liens IPv4 pour le routage des paquets et la mise en réseau à haute disponibilité. |
BGP (Border Gateway Protocol) |
bgpd |
Protocole EGP IPv4 et IPv6 pour le routage d'un domaine administratif à l'autre. |
La figure suivante illustre un système autonome ayant recours aux protocoles de routage Quagga.
La figure illustre un système autonome de réseau d'entreprise divisé en deux domaines de routage, A et B. Le domaine de routage A est un interréseau présentant une stratégie de routage cohésive dans un souci de gestion simplifiée ou en raison de l'utilisation d'un protocole de routage unique. Les deux domaines exécutent des protocoles de routage de la suite de protocoles Quagga.
Le domaine de routage A est un domaine OSPF géré sous un ID de domaine OSPF unique. Tous les systèmes à l'intérieur de ce domaine exécutent OSPF en tant qu'IGP. Outre les hôtes et routeurs internes, le domaine A comprend deux routeurs de bordure.
Le routeur de bordure R1 relie le réseau d'entreprise à Internet via un ISP. Pour faciliter les communications entre le réseau d'entreprise et le monde extérieur, R1 exécute BGP sur son interface réseau tournée vers l'extérieur. Le routeur de bordure R5 relie le domaine A au domaine B. Tous les systèmes du domaine B sont gérés avec le protocole de passerelle intérieure RIP. Par conséquent, le routeur de bordure R5 doit exécuter OSPF sur l'interface tournée vers le domaine A et RIP sur l'interface tournée vers le domaine B.
Pour plus d'informations sur les protocoles Quagga, reportez-vous au site Open Solaris Quagga. Pour connaître les procédures de configuration de ces protocoles, consultez la documentation de quagga.
Les sites comportant plusieurs routeurs et réseaux gèrent généralement leur topologie réseau comme un domaine de routage unique, également appelé système autonome AS (Autonomous System) . La figure suivante illustre une topologie réseau typique, considérée comme un AS de petite taille. Les exemples de cette section font référence à cette topologie.
La figure illustre un AS divisé en trois réseaux locaux : 10.0.5.0, 172.20.1.0 et 192.168.5 . Quatre routeurs se partagent les responsabilités de routage et de transfert des paquets. L'AS inclut les types de systèmes suivants :
Les routeurs de bordure relient un AS à un réseau externe, tel qu'Internet. Les routeurs périphériques réalisent l'interconnexion avec les réseaux externes à l'IGP exécuté sur le AS local. Un routeur de bordure peut exécuter un EGP, BGP (Border Gateway Protocol) par exemple, afin d'échanger des informations avec les routeurs externes, tels que les routeurs de l'ISP. Sur la Figure 5–3, les interfaces du routeur de bordure sont connectées au réseau interne 10.0.5.0 et à un routeur haut débit d'un fournisseur de services.
Pour plus d'informations sur la configuration d'un routeur de bordure et sur BGP (Border Gateway Protocol), consultez la documentation Open Source Quagga.
Si vous envisagez de connecter votre AS à Internet via BGP, vous devez obtenir un ASN (Autonomous System Number, numéro de système autonome) auprès du Registre Internet de votre environnement linguistique. Les registres régionaux, comme l'ARIN (American Registry for Internet Numbers), fournissent des directives pour l'obtention d'un ASN. Par exemple, le document ARIN Number Resource Policy Manual explique comment obtenir un ASN (Autonomous System Number, numéro de système autonome) pour un système autonome aux États-Unis et au Canada. Votre ISP est également en mesure d'obtenir un ASN pour vous.
Les routeurs par défaut gèrent les informations de routage concernant tous les systèmes du réseau local. Généralement, ces routeurs exécutent des IGP, tels que RIP. Sur la Figure 5–3, les interfaces du Routeur 1 sont reliées aux réseaux internes 10.0.5.0 et 192.168.5. Le routeur 1 sert également de routeur par défaut du réseau 192.168.5. Le routeur 1 gère les informations de routage pour tous les systèmes du réseau 192.168.5 ainsi que les routes vers d'autres routeurs, tels que le routeur de bordure. Les interfaces du routeur 2 sont reliées aux réseaux internes 10.0.5.0 et 172.20.1.
L'Exemple 5–4 illustre la configuration d'un routeur par défaut.
Les routeurs de transfert de paquet transmettent les paquets, mais n'exécutent aucun protocole de routage. Ce type de routeur reçoit les paquets de l'une de ses interfaces connectées à un réseau unique. Ces paquets sont alors transférés via une interface différente du routeur vers un autre réseau local. Sur la Figure 5–3, le routeur de transmission de paquets, Routeur 3, présente des connexions vers les réseaux 172.20.1 et 192.168.5.
Les hôtes multiréseaux possèdent plusieurs interfaces connectées au même segment de réseau. Par défaut, dans tous les systèmes exécutant Oracle Solaris, un hôte contenant plusieurs réseaux peut transférer des paquets. La Figure 5–3 illustre un hôte multiréseau dont les deux interfaces sont connectées au réseau 192.168.5 . L'Exemple 5–6 décrit la configuration d'un hôte multiréseau.
Les hôtes d'interface unique s'appuient sur les routeurs locaux pour le transfert de paquet et la réception d'informations de configuration critiques. Sur la Figure 5–3, l'hôte A sur le réseau 192.168.5 et l'hôte B sur le réseau 172.20.1 font appel au routage dynamique et au routage statique respectivement. La section Activation du routage dynamique sur un hôte à interface unique décrit la configuration d'un hôte exécutant le routage dynamique. La section Activation du routage statique sur un hôte à interface unique décrit la configuration d'un hôte exécutant le routage statique.
Cette section décrit la procédure de configuration d'un routeur IPv4 et en donne un exemple. Pour configurer un routeur IPv6, reportez-vous à la section Procédure de configuration d'un routeur compatible IPv6.
Un routeur représente l'interface entre deux ou plusieurs réseaux. Dès lors, un nom et une adresse IP uniques doivent être assignés à chacune de ses interfaces de réseau physiques. Par conséquent, chaque routeur possède un nom d'hôte et une adresse IP associés à son interface réseau principale ainsi qu'un nom et une adresse IP uniques pour chaque interface réseau supplémentaire.
Vous pouvez également effectuer la procédure suivante pour configurer un système doté d'une seule interface physique (un hôte, par défaut) en tant que routeur. Pour être configuré en tant que routeur, un système d'interface unique doit servir d'extrémité de lien PPP, comme décrit à la section Planning a Dial-up PPP Link du System Administration Guide: Network Services .
Vous pouvez configurer l'ensemble des interfaces d'un routeur lors de l'installation du système Oracle Solaris. Pour obtenir des instructions, reportez-vous au Guide d’installation d’Oracle Solaris 10 9/10 : installations de base.
La procédure suivante suppose que vous configurez les interfaces du routeur après l'installation.
Une fois le routeur physiquement installé sur le réseau, configurez le routeur en mode Fichiers locaux, suivant la procédure décrite à la section Configuration d'un hôte en mode Fichiers locaux. Cette configuration garantit l'initialisation du routeur en cas de panne du serveur de configuration.
Sur le système à configurer comme routeur, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
À partir de la version Solaris 10 1/06, utilisez la commande dladm show-link pour identifier les interfaces physiquement installées sur le routeur.
# dladm show-link |
La sortie suivante de la commande dladm show-link indique qu'une carte d'interface réseau qfe avec quatre interfaces et deux interfaces bge sont disponibles sur le système.
qfe0 type: legacy mtu: 1500 device: qfe0 qfe1 type: legacy mtu: 1500 device: qfe1 qfe2 type: legacy mtu: 1500 device: qfe0 qfe3 type: legacy mtu: 1500 device: qfe1 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 |
Vérifiez les interfaces configurées et montées sur le routeur lors de l'installation.
# ifconfig -a |
La sortie suivante de la commande ifconfig -a indique que l'interface qfe0 a été configurée lors de l'installation. Cette interface réside sur le réseau 172.16.0.0. Les autres interfaces sur de la carte d'interface réseau qfe, qfe1 - qfe3 et les interfaces bge n'ont pas été configurées.
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.16.26.232 netmask ffff0000 broadcast 172.16.26.255 ether 0:3:ba:11:b1:15 |
Configurez et montez une autre interface.
# ifconfig interface plumb up |
Par exemple, pour qfe1, vous devez taper :
# ifconfig qfe1 plumb up |
Les interfaces explicitement configurées à l'aide de la commande ifconfig ne sont pas conservées à la réinitialisation.
Assignez un masque de réseau et une adresse IPv4 à l'interface.
Vous pouvez configurer un routeur IPv4 de manière à recevoir son adresse IP via DHCP. Toutefois, cette opération est uniquement conseillée aux administrateurs système DHCP très expérimentés.
# ifconfig interface IPv4-address netmask+netmask |
Par exemple, procédez selon l'une des méthodes suivantes pour assigner l'adresse IP 192.168.84.3 à qfe1 :
À l'aide de la numérotation IPv4 classique, tapez les informations suivantes :
# ifconfig qfe1 192.168.84.3 netmask + 255.255.255.0 |
À l'aide de la numérotation CIDR, tapez les informations suivantes :
# ifconfig qfe1 192.168.84.3/24 |
Le préfixe /24 assigne automatiquement le réseau 255.255.255.0 à qfe1. La table de la Figure 2–2 répertorie les préfixes CIDR et leurs équivalents décimaux avec points.
(Facultatif) Pour garantir la conservation de la configuration d'interface après les réinitialisations, créez un fichier /etc/hostname.interface pour chaque interface physique supplémentaire.
Vous pouvez par exemple créer les fichiers /etc/hostname.qfe1 et /etc/hostname.qfe2 et saisir le nom d'hôte timbuktu dans le fichier /etc/hostname.qfe1 et le nom d'hôte timbuktu-201 dans le fichier /etc/hostname.qfe1 . Pour plus d'informations sur la configuration des interfaces uniques, reportez-vous à la section Configuration d'une interface physique après l'installation du système.
Veillez à réinitialiser la configuration après la création de ce fichier :
# reboot -- -r |
Ajoutez le nom d'hôte et l'adresse IP de chaque interface au fichier /etc/inet/hosts.
Exemple :
172.16.26.232 deadsea #interface for network 172.16.0.0 192.168.200.20 timbuktu #interface for network 192.168.200 192.168.201.20 timbuktu-201 #interface for network 192.168.201 192.168.200.9 gobi 192.168.200.10 mojave 192.168.200.110 saltlake 192.168.200.12 chilean |
Les interfaces timbuktu et timbuktu-201 résident sur le même système. Notez que l'adresse réseau de timbuktu-201 est différente de l'interface réseau de timbuktu. En effet, le média physique du réseau 192.168.201 est connecté à l'interface réseau timbuktu-201 tandis que le média du réseau 192.168.200 est connecté à l'interface timbuktu.
Pour Solaris 10 11/06 et les versions antérieures à Solaris 10 uniquement, ajoutez l'adresse IP et le nom d'hôte de chaque nouvelle interface dans le fichier /etc/inet/ipnodes ou la base de données équivalente ipnodes.
Exemple :
vi /etc/inet/ipnodes 172.16.26.232 deadsea #interface for network 172.16.0.0 192.168.200.20 timbuktu #interface for network 192.168.200 192.168.201.20 timbuktu-201 #interface for network 192.168.201 |
Si le routeur est connecté à un réseau de sous-réseaux, ajoutez le numéro du réseau et le masque de réseau dans le fichier /etc/inet/netmasks, fichier.
Pour une adresse IPv4 de numérotation classique, telle que 192.168.83.0 , vous devez taper :
192.168.83.0 255.255.255.0 |
Pour une adresse CIDR, utilisez la version à décimale avec points du préfixe dans l'entrée du fichier /etc/inet/netmask. Les préfixes réseau et leur équivalent décimal avec points sont répertoriés sur la Figure 2–2. Par exemple, vous devez utiliser l'entrée suivante dans /etc/netmasks pour exprimer le préfixe réseau CIDR 192.168.3.0/22 :
192.168.3.0 255.255.252.0 |
Activez le transfert de paquets IPv4 sur le routeur.
Pour cela, exécutez l'une des commandes suivantes :
Utilisez la commande routeadm comme suit :
# routeadm -e ipv4-forwarding -u |
Utilisez la commande SMF (Service Management Facility, utilitaire de gestion de service) suivante :
# svcadm enable ipv4-forwarding |
À ce stade, le routeur peut transférer des paquets au-delà du réseau local. Il prend également en charge le routage statique, un processus qui permet d'ajouter manuellement des routes à la table de routage. Si vous envisagez de recourir au routage statique, la configuration du routeur est terminée. Toutefois, vous devez gérer les routes dans la table de routage du système. Pour plus d'informations sur l'ajout de routes, reportez-vous à la section Configuration des routes et à la page de manuel route(1M).
(Facultatif) Lancez le protocole de routage.
Le démon de routage /usr/sbin/in.routed met automatiquement à jour la table de routage, un processus connu sous le nom de routage dynamique. Activez les protocoles de routage IPv4 par défaut de l'une des façons suivantes :
Utilisez la commande routeadm comme suit :
# routeadm -e ipv4-routing -u |
Pour lancer un protocole de routage, tel que RIP, utilisez la commande SMF suivante :
# svcadm enable route:default |
Le FMRI SMF associé au démon in.routed est svc:/network/routing/route.
Pour plus d'informations sur la commande routeadm, reportez-vous à la page de manuel routeadm(1M).
Cet exemple illustre la configuration d'un système existant doté de plusieurs interfaces en routeur par défaut. Le but consiste à faire du Routeur 2 de la Figure 5–3 le routeur par défaut du réseau 172.20.1.0. Le routeur 2 contient deux connexions réseau câblées, une connexion au réseau 172.20.1.0 et une connexion au réseau 10.0.5.0. L'exemple part du principe que le routeur s'exécute en mode Fichiers locaux, comme décrit à la section Configuration d'un hôte en mode Fichiers locaux.
Une fois que vous êtes superutilisateur ou avez un rôle équivalent, vous devez déterminer le statut des interfaces du système. Depuis Solaris 10 1/06, vous pouvez utiliser la commande dladm comme suit :
# dladm show-link ce0 type: legacy mtu: 1500 device: ce0 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.20.1.10 netmask ffff0000 broadcast 172.20.10.100 ether 8:0:20:c1:1b:c6 |
D'après la sortie de la commande dladm show-link, trois liens sont disponibles sur le système. Seule l'interface ce0 a été montée. Pour commencer la configuration du routeur par défaut, vous devez connecter physiquement l'interface bge0 au réseau 10.0.5.0. Ensuite, vous devez monter l'interface et la rendre persistante d'une session à l'autre.
# ifconfig bge0 plumb up # ifconfig bge0 10.0.5.10 # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.20.1.10 netmask ffff0000 broadcast 172.255.255.255 ether 8:0:20:c1:1b:c6 bge0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.5.10 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:e5:95:c4 # vi /etc/hostname.bge0 10.0.5.10 255.0.0.0 |
Réinitialisez le système à l'aide de la commande de reconfiguration au démarrage :
# reboot -- -r |
Configurez les bases de données réseau suivantes à l'aide des informations sur l'interface que vous venez de monter et le réseau auquel elle est connectée.
# vi /etc/inet/hosts 127.0.0.1 localhost 172.20.1.10 router2 #interface for network 172.20.1 10.0.5.10 router2-out #interface for network 10.0.5 # vi /etc/inet/netmasks 172.20.1.0 255.255.0.0 10.0.5.0 255.0.0.0 |
Enfin, activez le transfert de paquet, à l'aide de SMF, et le démon de routage in.routed .
# svcadm enable ipv4-forwarding # svcadm enable route:default |
La transmission de paquets IPv4 et le routage dynamique via RIP sont maintenant activés sur le Routeur 2. La configuration du routeur par défaut 172.20.1.0 n'est cependant pas terminée. Procédez comme suit :
Modifiez les hôtes du réseau 172.10.1.10 pour qu'ils reçoivent leurs informations de routage du nouveau routeur par défaut. Pour plus d'informations, reportez-vous à la section Activation du routage statique sur un hôte à interface unique.
Définissez une route statique menant au routeur de bordure dans la table de routage du Routeur 2. Pour plus d'informations, reportez-vous à la section Tables et types de routage.
Les routeurs et les hôtes gèrent une table de routage. Le démon de routage de chaque système actualise la table avec toutes les routes connues. Le noyau du système lit la table de routage avant de transférer des paquets au réseau local. La table de routage dresse la liste des adresses IP des réseaux connus du système, notamment le réseau local par défaut. Elle répertorie également la liste des adresses IP d'un système de passerelle pour chaque réseau connu. Un système de passerelle permet de recevoir des paquets sortants et de les envoyer un saut au-delà du réseau local. L'écran suivant représente une table de routage simple d'un système résidant sur un réseau exclusivement IPv4.
Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- default 172.20.1.10 UG 1 532 ce0 224.0.0.0 10.0.5.100 U 1 0 bge0 10.0.0.0 10.0.5.100 U 1 0 bge0 127.0.0.1 127.0.0.1 UH 1 57 lo0 |
Dans un système Oracle Solaris, vous pouvez configurer deux types de routage : statique et dynamique. Vous pouvez configurer l'un ou l'autre, ou les deux sur un même système. Dans le cadre de la gestion de sa table de routage, un système dont le routage est dynamique s'appuie sur les protocoles de routage, tels que RIP pour les réseaux IPv4 et RIPng pour les réseaux IPv6. Un système où s'applique le routage statique uniquement ne fait pas appel à un protocole de routage pour obtenir les informations de routage et mettre à jour sa table de routage. Vous devez gérer les routes connues du système manuellement à l'aide de la commande route. Pour plus d'informations, reportez-vous à la page de manuel route(1M).
Lors de la configuration du routage du réseau local ou d'un système autonome, réfléchissez au type de routage à prendre en charge sur des hôtes et des routeurs particuliers.
Le tableau suivant présente les différents types de routage et les scénarios de mise en réseau auquel chaque type de routage convient le mieux.
Sur la Figure 5–3, l'AS allie le routage statique au routage dynamique.
Dans le cadre de la mise en œuvre du routage dynamique d'un réseau IPv4, exécutez la commande routeadm ou svcadm afin de lancer le démon de routage in.routed. La section Configuration d'un routeur IPv4 décrit la procédure à suivre. Le routage dynamique est la stratégie privilégiée appliquée à la plupart des réseaux et des systèmes autonomes. Toutefois, votre topologie réseau ou un système spécifique sur votre réseau peut exiger un routage statique. Si tel est le cas, vous devez modifier manuellement la table de routage système afin d'y intégrer la route connue vers la passerelle. La procédure suivante décrit l'ajout d'une route statique.
Lorsque deux routes présentent la même destination, le système ne procède pas automatiquement à un basculement ou à un équilibrage des charges. Pour bénéficier de ces fonctions, utilisez IPMP, comme l'explique le Chapitre 30Présentation d'IPMP.
Examinez l'état actuel de la table de routage.
Pour exécuter la forme suivante de la commande netstat, utilisez votre compte utilisateur normal :
% netstat -rn |
La sortie doit ressembler à ceci :
Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- 192.168.5.125 192.168.5.10 U 1 5879 ipge0 224.0.0.0 198.168.5.10 U 1 0 ipge0 default 192.168.5.10 UG 1 91908 127.0.0.1 127.0.0.1 UH 1 811302 lo0 |
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
(Facultatif) Supprimez les entrées existantes de la table de routage.
# route flush |
Ajoutez une route qui persiste aux réinitialisations du système.
# route -p add -net network-address -gateway gateway-address |
Crée une route qui doit être conservée après les réinitialisations du système. Si vous souhaitez configurer la route pour la session en cours uniquement, n'utilisez pas l'option - p.
Indique que vous êtes sur le point d'ajouter la route suivante.
Indique que la route intègre le réseau avec l'adresse adresse-réseau.
Indique que le système de passerelle pour la route spécifiée possède l'adresse IP adresse-passerelle.
L'exemple suivant illustre l'ajout d'une route statique à un système. Le système est Routeur 2, le routeur par défaut du réseau 172.20.1.0 illustré à la Figure 5–3. Dans l'Exemple 5–4, le Routeur 2 est configuré pour un routage dynamique. Pour améliorer son service de routeur par défaut auprès des hôtes du réseau 172.20.1.0, Router 2 a également besoin d'une route statique vers le routeur de bordure de l'AS, 10.0.5.150 .
Pour afficher la table de routage sur Router 2, effectuez l'opération suivante :
# netstat -rn Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- default 172.20.1.10 UG 1 249 ce0 224.0.0.0 172.20.1.10 U 1 0 ce0 10.0.5.0 10.0.5.20 U 1 78 bge0 127.0.0.1 127.0.0.1 UH 1 57 lo0 |
D'après la table de routage, Router 2 a connaissance de deux routes. La route par défaut utilise l'interface 172.20.1.10 de Router 2 comme passerelle. La deuxième route, 10.0.5.0, a été détectée par le démon in.routed exécuté sur le Routeur 2. La passerelle de cette route est Routeur 1, avec l'adresse IP 10.0.5.20 .
Pour ajouter une seconde route au réseau 10.0.5.0, dont la passerelle est le routeur de bordure, procédez comme suit :
# route -p add -net 10.0.5.0/24 -gateway 10.0.5.150/24 add net 10.0.5.0: gateway 10.0.5.150 |
La table de routage contient désormais une route destinée au routeur de bordure dont l'adresse IP est 10.0.5.150/24.
# netstat -rn Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- default 172.20.1.10 UG 1 249 ce0 224.0.0.0 172.20.1.10 U 1 0 ce0 10.0.5.0 10.0.5.20 U 1 78 bge0 10.0.5.0 10.0.5.150 U 1 375 bge0 127.0.0.1 127.0.0.1 UH 1 57 lo0 |
Dans Oracle Solaris, un système comptant plusieurs interfaces est considéré comme un hôte multiréseau. Un hôte multiréseau ne transfère pas de paquets IP. Toutefois, il peut être configuré pour exécuter des protocoles de routage. Les systèmes habituellement configurés en tant qu'hôtes multiréseaux sont les suivants :
Les serveurs NFS (en particulier ceux qui fonctionnent en tant que vastes centres de données) peuvent être reliés à plusieurs réseaux et permettre ainsi à un grand nombre d'utilisateurs de partager des fichiers. Ils ne doivent pas forcément gérer des tables de routage.
Tout comme les serveurs NFS, les serveurs de bases de données peuvent posséder plusieurs interfaces réseau en vue de mettre des ressources à la disposition d'un grand nombre d'utilisateurs.
Les passerelles pare-feu connectent un réseau d'entreprise avec des réseaux publics, tels qu'Internet. Un pare-feu constitue une mesure de sécurité mise en œuvre par les administrateurs. Configuré en tant que pare-feu, l'hôte ne transmet pas de paquets entre les réseaux qui sont reliés à ses interfaces. Toutefois, l'hôte peut toujours fournir des services TCP/IP standard, tels que ssh, aux utilisateurs autorisés.
Lorsque les pare-feux sur les interfaces d'un hôte multiréseau sont différents, évitez au maximum toute perturbation accidentelle des paquets de l'hôte. Ce problème se produit particulièrement avec les pare-feux avec état. Une des solutions consiste à configurer des pare-feux sans état. Pour plus d'informations sur les pare-feux, reportez-vous à la section Firewall Systems du System Administration Guide: Security Services ou à la documentation relative aux pare-feux tiers utilisés sur le réseau.
Sur le futur hôte multiréseau, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Configurez et montez toutes les interfaces réseau supplémentaires qui n'ont pas été configurées lors de l'installation de Oracle Solaris.
Reportez-vous à la section Configuration d'une interface physique après l'installation du système.
Assurez-vous que le transfert IP n'est pas activé sur l'hôte multiréseau.
# routeadm |
La commande routeadm sans option signale l'état des démons de routage. D'après la sortie de la commande routeadm ci-dessous, le transfert IPv4 est activé.
Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding enabled disabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
Désactivez le transfert de paquet s'il est activé sur le système.
Exécutez l'une des commandes suivantes :
Si vous exécutez la commande routeadm, tapez ce qui suit :
# routeadm -d ipv4-forwarding -u |
Si vous utilisez l'utilitaire SMF, tapez ce qui suit :
# svcadm disable ipv4-forwarding |
(Facultatif) Activez le routage dynamique pour l'hôte multiréseau.
Exécutez l'une des commandes suivantes pour activer le démon in.routed :
Si vous exécutez la commande routeadm, tapez ce qui suit :
# routeadm -e ipv4-routing -u |
Si vous utilisez l'utilitaire SMF, tapez ce qui suit :
# svcadm enable route:default |
L'exemple suivant décrit la configuration de l'hôte multiréseau de la Figure 5–3. Dans cet exemple, le nom d'hôte du système est hostc. Cet hôte présente deux interfaces connectées au réseau 192.168.5.0 .
Commencez par afficher l'état des interfaces du système.
# dladm show-link hme0 type: legacy mtu: 1500 device: hme0 qfe0 type: legacy mtu: 1500 device: qfe0 qfe1 type: legacy mtu: 1500 device: qfe1 qfe2 type: legacy mtu: 1500 device: qfe2 qfe3 type: legacy mtu: 1500 device: qfe3 # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.5.82 netmask ff000000 broadcast 192.255.255.255 ether 8:0:20:c1:1b:c6 |
La commande dladm show-link signale que hostc présente deux interfaces avec un total de cinq liens possibles. Toutefois, seul hme0 a fait l'objet d'un montage. Pour configurer hostc en tant qu'hôte multiréseau, vous devez ajouter le lien qfe0 ou un autre lien sur la carte d'interface réseau qfe. Vous devez d'abord connecter l'interface qfe0 au réseau 192.168.5.0. Vous devez ensuite monter l'interface qfe0 et la rendre persistante après les réinitialisations.
# ifconfig qf0 plumb up # ifconfig qfe0 192.168.5.85 # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.5.82 netmask ff0000 broadcast 192.255.255.255 ether 8:0:20:c1:1b:c6 qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.5.85 netmask ff000000 broadcast 192.255.255.255 ether 8:0:20:e1:3b:c4 # vi /etc/hostname.qfe0 192.168.5.85 255.0.0.0 |
Réinitialisez le système à l'aide de la commande de reconfiguration :
# reboot -- -r |
Ensuite, vous devez ajouter l'interface qfe0 à la base de données hosts :
# vi /etc/inet/hosts 127.0.0.1 localhost 192.168.5.82 host3 #primary network interface for host3 192.168.5.85 host3-2 #second interface |
Vous devez alors vérifier l'état du transfert de paquet et du routage sur host3 :
# routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing enabled enabled IPv6 routing disabled disabled IPv4 forwarding enabled enabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
La commande routeadm signale l'activation du routage dynamique via le démon in.routed et du transfert de paquet. Vous devez désactiver le transfert de paquet.
# svcadm disable ipv4-forwarding |
Pour désactiver le transfert de paquet, vous pouvez aussi exécuter les commandes routeadm comme illustré à la section Création d'un hôte multiréseau Une fois le transfert de paquet désactivé, host3 devient un hôte multiréseau.
Les hôtes à interface unique doivent pouvoir implémenter une forme de routage. S'ils doivent obtenir leurs routes à partir d'un ou de plusieurs routeurs locaux par défaut, configurez-les en vue d'un routage statique. Si ce n'est pas le cas, il est conseillé de recourir au routage dynamique. Les sections suivantes décrivent les procédures d'activation des deux types de routage.
Cette procédure active le routage statique sur un hôte à interface unique. Les hôtes utilisant le routage statique n'exécutent aucun protocole de routage dynamique (par exemple, RIP). Pour le routage d'informations, ils utilisent les services d'un routeur par défaut. La figure Topologie du système autonome IPv4 représente plusieurs routeurs par défaut et leurs hôtes client. Si vous avez fourni le nom d'un routeur par défaut lors de l'installation d'un hôte, ce dernier est configuré de manière à utiliser le routage statique.
Vous pouvez également suivre la procédure ci-dessous pour configurer le routage statique sur un hôte multiréseau.
Pour plus d'informations sur le fichier /etc/defaultrouter, reportez-vous à la section Fichier /etc/defaultrouter. Pour plus d'informations sur le routage statique et la table de routage, reportez-vous à la section Tables et types de routage.
Sur l'hôte à interface unique, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Vérifiez la présence du fichier /etc/defaultrouter sur l'hôte.
# cd /etc # ls | grep defaultrouter |
Créez ou modifiez le fichier /etc/defaultrouter à l'aide d'un éditeur de texte.
Ajoutez une entrée pour le routeur par défaut.
# vi /etc/defaultrouter router-IP |
où IP-routeur désigne l'adresse IP du routeur par défaut de l'hôte à utiliser.
Assurez-vous que le routage et le transfert de paquets ne sont pas en cours d'exécution sur l'hôte.
# routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding disabled disabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
Ajoutez une entrée pour le routeur par défaut dans le fichier local /etc/inet/hosts .
Pour plus d'informations sur la configuration du fichier /etc/inet/hosts , reportez-vous à la section Modification de l'adresse IPv4 et des autres paramètres de configuration réseau.
L'exemple suivant illustre la configuration du routage statique d'hostb, hôte à interface unique sur le réseau 172.20.1.0 de la Figure 5–3. L'hôte hostb doit utiliser le routeur 2 en tant que routeur par défaut.
Vous devez d'abord vous connecter à hostb en tant que superutilisateur ou utilisateur possédant un rôle équivalent. Vérifiez ensuite la présence du fichier /etc/defaultrouter sur l'hôte.
# cd /etc # ls | grep defaultrouter |
Si vous n'obtenez aucune réponse de grep, vous devez créer le fichier /etc/defaultrouter.
# vi /etc/defaultrouter 172.20.1.10 |
L'entrée du fichier /etc/defaultrouter correspond à l'adresse IP de l'interface sur le routeur 2 reliée au réseau 172.20.1.0 . Vérifiez ensuite si l'hôte autorise actuellement le transfert de paquet et le routage.
# routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding enabled enabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
Le transfert de paquet est activé pour cet hôte. Désactivez-le comme suit :
# svcadm disable ipv4-forwarding |
Enfin, assurez-vous que le fichier /etc/inet/hosts possède une entrée pour le nouveau routeur par défaut.
# vi /etc/inet/hosts 127.0.0.1 localhost 172.20.1.18 host2 #primary network interface for host2 172.20.1.10 router2 #default router for host2 |
Le routage dynamique simplifie la gestion du routage sur un hôte. Les hôtes utilisant le routage dynamique exécutent les protocoles de routage fournis par le démon in.routed pour IPv4 ou le démon in.ripngd pour IPv6. Procédez comme suit pour activer le routage dynamique IPv4 sur un hôte à interface unique. Pour plus d'informations sur le routage dynamique, reportez-vous à la section Transfert et routage de paquets sur des réseaux IPv4.
Sur l'hôte, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Assurez-vous que le fichier /etc/defaultrouter existe.
# cd /etc # ls | grep defaultrouter |
Si /etc/defaultrouter existe, supprimez toutes les entrées qu'il contient.
Un fichier /etc/defaultrouter vide oblige l'hôte à utiliser le routage dynamique.
Assurez-vous que le transfert de paquets et le routage sont activés sur l'hôte.
# routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding enabled enabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
Si le transfert de paquet est activé, désactivez-le.
Exécutez l'une des commandes suivantes :
Si vous exécutez la commande routeadm, tapez ce qui suit :
# routeadm -d ipv4-forwarding -u |
Si vous utilisez l'utilitaire SMF, tapez ce qui suit :
# svcadm disable ipv4-forwarding |
Activez les protocoles de routage sur l'hôte.
Exécutez l'une des commandes suivantes :
Si vous exécutez la commande routeadm, tapez ce qui suit :
# routeadm -e ipv4-routing -u |
Si vous utilisez l'utilitaire SMF, tapez ce qui suit :
# svcadm enable route:default |
Le routage dynamique IPv4 est à présent activé. La table de routage de l'hôte est gérée dynamiquement par le démon in.routed.
L'exemple suivant illustre la configuration du routage dynamique d'hosta, hôte à interface unique sur le réseau 192.168.5.0 de la Figure 5–3. L'hôte hosta utilise actuellement le routeur 1 en tant que routeur par défaut. Cependant, hosta doit maintenant recourir au routage dynamique.
Vous devez d'abord vous connecter à hosta en tant que superutilisateur ou utilisateur possédant un rôle équivalent. Vérifiez ensuite la présence du fichier /etc/defaultrouter sur l'hôte.
# cd /etc # ls | grep defaultrouter defaultrouter |
La réponse de grep signale l'existence d'un fichier /etc/defaultrouter pour hosta.
# vi /etc/defaultrouter 192.168.5.10 |
Le fichier contient l'entrée 192.168.5.10, qui est l'adresse IP du Routeur 1. Supprimez cette entrée pour activer le routage statique. Ensuite, vous devez déterminer si le transfert de paquet et le routage sont activés pour l'hôte.
# routeadm Configuration Current Current Option Configuration System State --------------------------------------------------------------- IPv4 routing disabled disabled IPv6 routing disabled disabled IPv4 forwarding disabled disabled IPv6 forwarding disabled disabled Routing services "route:default ripng:default" |
Le routage et le transfert de paquet sont désactivés pour hosta . Pour terminer la configuration du routage dynamique pour hosta , activez le routage comme suit :
# svcadm enable route:default |
Les protocoles de couche de transport TCP, SCTP et UDP font partie du package Oracle Solaris standard. Généralement, ces protocoles fonctionnent correctement sans que l'utilisateur ait à intervenir. Toutefois, dans certaines conditions, vous serez peut-être amené à consigner ou modifier des services exécutés via les protocoles de couche transport. Vous devez ensuite modifier les profils de ces services à l'aide de l'utilitaire SMF (Service Management Facility). Pour plus d'informations sur cet utilitaire, reportez-vous au Chapitre 18, Managing Services (Overview) du System Administration Guide: Basic Administration.
Le démon inetd est chargé de lancer les services Internet standard lors de l'initialisation d'un système. Ces services incluent les applications utilisant les protocoles de couche transport TCP, SCTP ou UDP. Vous pouvez modifier les services Internet existants ou ajouter de nouveaux services à l'aide des commandes SMF. Pour plus d'informations sur inetd, reportez-vous à la section Démon de services Internet inetd.
Opérations impliquant les protocoles de couche transport :
Journalisation de toutes les connexions TCP entrantes
Ajout de services faisant appel à un protocole de couche transport, utilisant SCTP comme exemple
Configuration des wrappers TCP dans le cadre du contrôle d'accès
Pour plus d'informations sur le démon inetd, reportez-vous à la page de manuel inetd(1M).
Sur le système local, connectez-vous en tant qu'administrateur réseau ou superutilisateur.
Les rôles contiennent des autorisations et des commandes privilégiées. Pour de plus amples informations sur les rôles, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Activez le suivi TCP pour tous les services gérés par inetd.
# inetadm -M tcp_trace=TRUE |
Le protocole de transport SCTP fournit des services aux protocoles de couche d'application de façon similaire à TCP. Toutefois, SCTP permet la communication entre deux systèmes multiréseaux ou deux systèmes dont l'un est multiréseau. La connexion SCTP s'appelle une association. Dans une association, une application divise les données à transmettre en plusieurs flux de messages. Une connexion SCTP peut atteindre les extrémités à l'aide de plusieurs adresses IP, ce qui s'avère particulièrement important dans le cadre d'applications de téléphonie. Les capacités multiréseau de SCTP améliorent la sécurité des sites ayant recours à IP Filter ou IPsec. La page de manuel sctp(7P) répertorie les points à prendre en considération au niveau de la sécurité.
Par défaut, le protocole SCTP fait partie de Oracle Solaris et ne nécessite aucune configuration supplémentaire. Toutefois, vous devrez peut-être configurer explicitement certains services de couche d'application pour utiliser SCTP. echo et discard sont des exemples d'applications. La procédure suivante illustre l'ajout d'un service d'écho qui utilise un socket de type SCTP bi-univoque.
La procédure suivante permet également d'ajouter des services pour les protocoles de couche transport TCP et UDP.
La tâche suivante illustre l'ajout dans le référentiel SMF d'un service inet SCTP géré par le démon inetd. La tâche décrit ensuite la procédure d'ajout du service à l'aide des commandes SMF (Service Management Facility).
Pour plus d'informations sur les commandes SMF, reportez-vous à la section SMF Command-Line Administrative Utilities du System Administration Guide: Basic Administration .
Pour plus d'informations sur la syntaxe, consultez les pages de manuel sur les commandes SMF citées dans la procédure.
Pour plus d'informations sur SMF, reportez-vous à la page de manuel smf(5).
Avant d'effectuer la procédure suivante, créez un fichier manifeste pour le service. En exemple, la procédure fait référence à un fichier manifeste du service echo intitulé echo.sctp.xml .
Connectez-vous au système local avec un compte utilisateur disposant de privilèges d'écriture sur les fichiers système.
Modifiez le fichier /etc/services et ajoutez la définition du nouveau service.
Définissez le service à l'aide de la syntaxe suivante.
service-name |port/protocol | aliases |
Ajoutez le nouveau service.
Accédez au répertoire de stockage du manifeste de service et tapez ce qui suit :
# cd dir-name # svccfg import service-manifest-name |
La page de manuel svccfg(1M) contient la syntaxe complète de svccfg.
Admettons que vous voulez ajouter un service echo SCTP à l'aide du manifeste echo.sctp.xml résidant dans le répertoire service.dir. Vous devez taper ce qui suit :
# cd service.dir # svccfg import echo.sctp.xml |
Assurez-vous que le manifeste de service a été ajouté :
# svcs FMRI |
Pour l'argument FMRI, utilisez le FMRI (Fault Managed Resource Identifier, identificateur de ressources gérées erronées) du manifeste de service. Par exemple, pour le service SCTP echo, vous devez utiliser la commande suivante :
# svcs svc:/network/echo:sctp_stream |
La sortie doit ressembler à ceci :
STATE STIME FMRI disabled 16:17:00 svc:/network/echo:sctp_stream |
Pour plus d'informations sur la commande svcs, reportez-vous à la page de manuel svcs(1).
D'après la sortie, le nouveau manifeste de service est désactivé.
Dressez la liste des propriétés du service afin d'identifier les modifications à apporter.
# inetadm -l FMRI |
Pour plus d'informations sur la commande inetadm, reportez-vous à la page de manuel inetadm(1M).
Par exemple, pour le service SCTP echo, vous devez saisir les informations suivantes :
# inetadm -l svc:/network/echo:sctp_stream SCOPE NAME=VALUE name="echo" endpoint_type="stream" proto="sctp" isrpc=FALSE wait=FALSE exec="/usr/lib/inet/in.echod -s" . . default tcp_trace=FALSE default tcp_wrappers=FALSE |
Activez le nouveau service :
# inetadm -e FMRI |
Assurez-vous que le service est activé.
Par exemple, pour le nouveau service echo, vous devez taper :
# inetadm | grep sctp_stream . . enabled online svc:/network/echo:sctp_stream |
L'exemple suivant indique les commandes à utiliser et les entrées de fichier requises pour que le service d'écho utilise le protocole de couche transport SCTP.
$ cat /etc/services . . echo 7/tcp echo 7/udp echo 7/sctp # cd service.dir # svccfg import echo.sctp.xml # svcs network/echo* STATE STIME FMRI disabled 15:46:44 svc:/network/echo:dgram disabled 15:46:44 svc:/network/echo:stream disabled 16:17:00 svc:/network/echo:sctp_stream # inetadm -l svc:/network/echo:sctp_stream SCOPE NAME=VALUE name="echo" endpoint_type="stream" proto="sctp" isrpc=FALSE wait=FALSE exec="/usr/lib/inet/in.echod -s" user="root" default bind_addr="" default bind_fail_max=-1 default bind_fail_interval=-1 default max_con_rate=-1 default max_copies=-1 default con_rate_offline=-1 default failrate_cnt=40 default failrate_interval=60 default inherit_env=TRUE default tcp_trace=FALSE default tcp_wrappers=FALSE # inetadm -e svc:/network/echo:sctp_stream # inetadm | grep echo disabled disabled svc:/network/echo:stream disabled disabled svc:/network/echo:dgram enabled online svc:/network/echo:sctp_stream |
Le programme tcpd met en œuvre les wrappers TCP. Les wrappers TCP représentent une mesure de sécurité supplémentaire pour les démons de services, notamment pour ftpd . En effet, ils s'interposent entre le démon et les requêtes de service entrantes. Les wrappers TCP consignent les réussites et les échecs des tentatives de connexion. En outre, ils offrent un contrôle d'accès en autorisant ou en refusant la connexion en fonction de l'origine de la requête. Enfin, ils permettent de protéger les démons, notamment SSH, Telnet et FTP. L'application sendmail peut également avoir recours aux wrappers TCP (voir la section Support for TCP Wrappers From Version 8.12 of sendmail du System Administration Guide: Network Services .)
Sur le système local, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Activez les wrappers TCP.
# inetadm -M tcp_wrappers=TRUE |
Configurez la stratégie de contrôle d'accès des wrappers TCP, telle que décrite à la page de manuel hosts_access(3).
Cette page de manuel se trouve sous le répertoire /usr/sfw/man du CD-ROM SFW livré avec le CD-ROM Oracle Solaris.
Cette section décrit les procédures d'administration des interfaces physiques suivantes :
Ajout d'interfaces physiques après l'installation du système
Ajout d'un VLAN à un adaptateur réseau
Cette section contient des informations relatives à la configuration des interfaces pour les utilisateurs du SE Solaris 10 3/05 uniquement. Si vous utilisez la mise à jour Oracle Solaris 10, reportez-vous au Chapter 6, Administration d'interfaces réseau (tâches). Vous trouverez une liste complète des nouvelles fonctionnalités de Oracle Solaris la description des différentes versions de cette application dans le document Nouveautés apportées à Oracle Solaris 10 9/10.
Un système Oracle Solaris contient généralement deux types d'interface : physique et logique. Une interface physique comporte un pilote et un connecteur permettant la connexion du média réseau, tel qu'un câble Ethernet. Les interfaces logiques sont configurées logiquement sur des interfaces physiques existantes, notamment des interfaces configurées pour les tunnels ou avec des adresses IPv6. Cette section décrit la configuration des interfaces physiques après l'installation. Des instructions relatives à la configuration des interfaces logiques sont incluses avec des tâches pour les fonctions requérant des interfaces logiques, par exemple Procédure de configuration manuelle de tunnels IPv6 sur un réseau IPv4.
Parmi les interfaces physiques figurent les interfaces incorporées au système ainsi que les interfaces acquises séparément. Chaque interface réside sur une NIC (Network Interface Card, carte d'interface réseau).
Les NIC intégrées sont présentes sur le système dès l'achat. Un exemple d'interface résidant sur une NIC intégrée est l'interface réseau principale, eri0 ou hme0 notamment. Vous devez configurer l'interface réseau principale du système lors de l'installation.
Les NIC telles que eri et hme sont dotées d'une seule interface. Toutefois, de nombreuses marques de NIC présentent plusieurs interfaces. Une NIC multi-interface, comme la carte qfe présente quatre interfaces, qfe0 – qfe3. Le programme d'installation de Oracle Solaris détecte toutes les interfaces présentes lors de l'installation et vous invite à les configurer. Vous pouvez effectuer la configuration lors de l'initialisation ou à une date ultérieure.
Les NIC sont également appelées des adaptateurs réseau.
Outre les NIC intégrées, vous pouvez ajouter au système des NIC acquises séparément. Pour installer une NIC achetée séparément, vous devez suivre les instructions du fabricant. Ensuite, vous devez configurer les interfaces sur les NIC en vue de les utiliser pour la transmission du trafic des données.
La liste ci-dessous répertorie les raisons de configurer des interfaces supplémentaires sur un système après l'installation :
Vous souhaitez convertir le système en hôte multiréseau. Pour plus d'informations sur les hôtes multiréseaux, reportez-vous à la section Configuration des hôtes multiréseaux.
Vous souhaitez remplacer l'hôte par un routeur. Pour obtenir les instructions relatives à la configuration de routeurs, reportez-vous à la section Configuration d'un routeur IPv4.
Vous souhaitez ajouter une interface à un groupe IPMP. Pour plus d'informations sur les interfaces dans un groupe IPMP, reportez-vous à la section Configurations d'interfaces IPMP.
Identifiez les adresses IPv4 à utiliser pour les interfaces supplémentaires.
L'interface physique à configurer doit résider sur le système. Pour plus d'informations sur l'installation de NIC achetées séparément, consultez les instructions correspondantes fournies par le fabricant.
La procédure suivante part du principe que vous avez réalisé une reconfiguration au démarrage après avoir installé une nouvelle interface.
La procédure suivante s'applique aux utilisateurs du SE Solaris 10 3/05 uniquement. Si vous utilisez la mise à jour Oracle Solaris 10, reportez-vous à la section Configuration d'une interface physique après l'installation du système.
Sur le système sur lequel vous devez configurer les interfaces, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Configurez et montez chaque interface.
# ifconfig interface plumb up |
Par exemple, pour qfe0, vous devez taper :
# ifconfig qfe0 plumb up |
Les interfaces explicitement configurées à l'aide de la commande ifconfig ne sont pas conservées à la réinitialisation.
Assignez un masque de réseau et une adresse IPv4 à l'interface.
# ifconfig interface IPv4-address netmask+netmask |
Par exemple, pour qfe0, vous devez taper :
# ifconfig qfe0 10.0.0.32 netmask + 255.255.255.0 |
Assure-vous que les interfaces nouvellement configurées sont montées et configurées ou affichent l'indicateur d'état « UP ».
# ifconfig -a |
Vérifiez la ligne d'état de chaque interface affichée. Veillez à ce que la sortie contienne l'indicateur UP sur la ligne d'état, par exemple :
qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 |
(Facultatif) Pour conserver la configuration des interfaces après les réinitialisations, suivez les instructions ci-dessous :
Créez un fichier /etc/hostname.interface pour chaque interface à configurer.
Par exemple, pour ajouter l'interface qfe0, vous devez créer le fichier suivant :
# vi /etc/hostname.qfe0 |
Modifiez le fichier /etc/hostname.interface.
Ajoutez l'adresse IPv4 de l'interface dans le fichier. Vous pouvez également ajouter au fichier un masque de réseau et des informations de configuration supplémentaires.
Pour ajouter une adresse IPv6 à une interface, reportez-vous à la section Modification de la configuration d'interface IPv6 pour les hôtes et les serveurs
Ajoutez les entrées des nouvelles interfaces dans le fichier /etc/inet/hosts .
Effectuez une reconfiguration au démarrage.
# reboot -- -r |
Assurez-vous que l'interface créée dans le fichier /etc/hostname. interface a été configurée.
# ifconfig -a |
L'exemple suivant illustre l'ajout de deux interfaces, qfe0 et qfe1, reliées au même réseau en tant qu'interface réseau principale, hme0. Notez que cette configuration d'interface est supprimée après réinitialisation du système. L'Exemple 6–2 illustre comment rendre persistantes les configurations d'interface après les redémarrages. Toutefois, la commande dladm utilisée dans cet exemple n'est disponible qu'à partir du SE Solaris 10 1/06.
# ifconfig qfe0 plumb up # ifconfig qfe1 plumb up # ifconfig qfe0 10.0.0.32 netmask 255.0.0.0 # ifconfig qfe1 10.0.0.33 netmask 255.0.0.0 |
# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.14 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 10.0.0.32 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:c8:f4:1d qfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4 inet 10.0.0.33 netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:c8:f4:1e |
Pour configurer une adresse IPv6 sur une interface, reportez-vous à la section Activation d'une interface IPv6 pour la session actuelle.
Pour configurer la détection de basculement et le rétablissement des interfaces à l'aide d'IPMP (IP Network Multipathing, multiacheminement sur réseau IP), reportez-vous au Chapitre 31Administration d'IPMP (tâches).
La procédure suivante s'applique aux utilisateurs du SE Solaris 10 3/05 uniquement. Si vous utilisez la mise à jour Oracle Solaris 10, reportez-vous à la section Suppression d'une interface physique.
Sur le système sur lequel vous devez supprimer l'interface, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Supprimez l'interface physique.
Utilisez la forme suivante de la commande ifconfig :
# ifconfig interfacedown unplumb |
Par exemple, pour supprimer l'interface eri1, tapez ce qui suit :
# ifconfig eri1 down unplumb |
Cette section contient des informations relatives à la configuration des VLAN pour les utilisateurs du SE Solaris 10 3/05 uniquement. Si vous utilisez la mise à jour Oracle Solaris 10, reportez-vous à la section Administration de réseaux locaux virtuels.
Les VLAN (Virtual Local Area Networks, réseaux locaux virtuels) sont fréquemment utilisés pour diviser des groupes d'utilisateurs réseau et faciliter la gestion des domaines de diffusion, créer des segmentations logiques de groupes de travail et appliquer des stratégies de sécurité aux segments logiques. Étant donné qu'un adaptateur possède plusieurs VLAN, un serveur doté d'un seul adaptateur peut offrir une présence logique sur plusieurs sous-réseaux IP. Par défaut, les VLAN 512 peuvent être définis pour chaque adaptateur utilisant des VLAN sur votre serveur.
Si votre réseau ne requiert pas plusieurs VLAN, vous pouvez utiliser la configuration par défaut ; auquel cas, aucune configuration supplémentaire n'est nécessaire.
La section Présentation de la topologie du VLAN contient une présentation des VLAN.
La création des VLAN peut s'effectuer selon plusieurs critères. Toutefois, vous devez leur assigner une balise VLAN ou un VID (VLAN ID, identificateur de VLAN). Le VID est un identificateur 12 bits compris entre 1 et 4 094 permettant d'identifier un VLAN unique. Pour chaque interface réseau (par exemple, ce0, ce1, ce2, etc.), vous pouvez créer 512 VLAN. En raison de leur utilisation courante, les sous-réseaux IP peuvent être utilisés lors de la configuration d'une interface réseau VLAN. En d'autres termes, chaque VID assigné à l'interface VLAN d'une interface réseau physique appartient à différents sous-réseaux.
Pour baliser un cadre Ethernet, vous devez y ajouter un en-tête de balise. Insérez l'en-tête immédiatement après les adresses MAC cible et source. L'en-tête de balise est constitué de deux octets du TPID (Ethernet Tag Protocol Identifier (0x8100) et de deux octets du TCI (Tag Control Information). La figure suivante illustre le format de l'en-tête de balise Ethernet.
Cette procédure contient des informations relatives à la configuration des VLAN pour les utilisateurs du SE Solaris 10 3/05 uniquement. Si vous utilisez la mise à jour Oracle Solaris 10, reportez-vous à la section Procédure de configuration d'un VLAN.
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Identifiez le type des interfaces du système.
Il est possible que l'adaptateur réseau ne soit pas référencé par les lettres ce, condition obligatoire pour un VLAN.
# ifconfig -a lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 129.156.200.77 netmask ffffff00 broadcast 129.156.200.255 |
Créez un fichier hostname.ce num (fichier hostname6.cenum pour IPv6) pour chaque VLAN à configurer pour chacun des adaptateurs du serveur.
Utilisez le format de nom suivant qui inclut le VID et le point physique de connexion PPA (Physical Point of Attachment) :
PPA logique VLAN = 1000 * VID + PPA Périphérique ce123000 = 1000*123 + 0
Par exemple : hostname.ce123000
PPA logique VLAN = 1000 * VID + PPA Périphérique ce11000 = 1000*11 + 0
Par exemple : hostname.ce11000
Ce format limite à 1 000 le nombre maximum de PPA (instances) que vous pouvez configurer dans le fichier /etc/path_to_inst.
Par exemple, sur un serveur doté de l'adaptateur Sun Gigabit Ethernet/P 3.0 présentant une instance 0, qui appartient à deux VLAN dont les VID sont 123 et 224, vous devez utiliser les PPA ce123000 et ce224000, respectivement.
Configurez un périphérique virtuel VLAN :
Vous pouvez utiliser les exemples de ifconfig suivants :
# ifconfig ce123000 plumb up # ifconfig ce224000 plumb up |
La sortie de ifconfig -a sur un système présentant les périphériques VLAN ce123000 et ce224000 doit ressembler à l'écran suivant :
# ifconfig -a lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 129.144.131.91 netmask ffffff00 broadcast 129.144.131.255 ether 8:0:20:a4:4f:b8 ce123000: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 199.199.123.3 netmask ffffff00 broadcast 199.199.123.255 ether 8:0:20:a4:4f:b8 ce224000: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4 inet 199.199.224.3 netmask ffffff00 broadcast 199.199.224.255 ether 8:0:20:a4:4f:b8 |
Sur le commutateur, définissez le balisage et les ports VLAN de telle sorte qu'ils coïncident avec les VLAN que vous avez configurés sur le serveur.
À l'aide des exemples de l'étape 4, vous configurez les ports VLAN 123 et 224 sur le commutateur ou les ports VLAN 10 et 11.
Pour obtenir les instructions relatives à la configuration du balisage et des ports VLAN, reportez-vous à la documentation livrée avec le commutateur.
Ce chapitre contient des tâches et des informations relatives aux interfaces réseau :
Les informations contenues dans ce chapitre décrivent la configuration d'interface à partir de la version Solaris 10 1/06. Si vous utilisez la version d'origine de Solaris 10, 3/05, reportez-vous à la section Gestion des interfaces dans Solaris 10 3/05. Vous trouverez une liste complète des nouvelles fonctionnalités de Oracle Solaris la description des différentes versions de cette application dans le document Nouveautés apportées à Oracle Solaris 10 9/10.
Les nouvelles fonctions de Solaris 10 1/06 sont les suivantes :
La nouvelle commande dladm permettant d'afficher le statut de l'interface est présentée à la section Configuration d'une interface physique après l'installation du système.
La prise en charge VLAN a été étendue aux interfaces GLDv3, comme expliqué à la section Administration de réseaux locaux virtuels.
La prise en charge du groupement de liens est introduite à la section Présentation des groupements de liens.
Dans Solaris 10 7/07, le fichier /etc/inet/ipnodes devient obsolète. Utilisez /etc/inet/ipnodes uniquement pour les versions Solaris 10 antérieures, comme expliqué dans chaque procédure.
Le tableau suivant répertorie les différentes tâches de configuration des interfaces réseau, notamment les configurations spéciales, telles que les configurations de VLAN et de groupements de liens. Le tableau comprend la description des actions de chaque tâche et la section de la documentation actuelle dans laquelle les étapes permettant d'effectuer ces tâches sont décrites en détails.
Tâche |
Description |
Voir |
---|---|---|
Vérification du statut des interfaces du système |
Répertoriez toutes les interfaces du système et vérifiez celles qui sont déjà reliées à un nom de périphérique. | |
Ajout d'une seule interface après l'installation du système |
Transformez un système en routeur ou hôte multiréseau en configurant une autre interface. |
Configuration d'une interface physique après l'installation du système |
SPARC : vérification de l'unicité de l'adresse MAC d'une interface |
Veillez à ce que l'interface soit configurée avec l'adresse MAC par défaut, plutôt qu'avec l'adresse MAC système (SPARC uniquement). |
SPARC : Garantie de l'unicité de l'adresse MAC d'une interface |
Planification d'un réseau local virtuel (VLAN) |
Réalisez les tâches de planification requises avant la création du VLAN. | |
Configuration d'un VLAN |
Créez et modifiez les VLAN sur le réseau. | |
Planification des groupements |
Concevez le groupement et effectuez les tâches de planification requises avant la configuration de groupements. | |
Configuration d'un groupement |
Réalisez les diverses tâches en relation avec le groupement de liens. | |
Planification et configuration d'un groupe IPMP |
Configurez le basculement et le rétablissement pour les interfaces membres d'un groupe IPMP. |
Procédure de planification pour un groupe IPMP Procédure de configuration d'un groupe IPMP avec plusieurs interfaces |
Une fois l'installation de Oracle Solaris terminée, vous pouvez être amené à configurer ou à gérer des interfaces pour effectuer les opérations suivantes :
Mise à niveau du système en hôte multiréseau. Pour plus d'informations, reportez-vous à la section Configuration des hôtes multiréseaux.
Conversion d'un hôte en routeur. Pour obtenir les instructions relatives à la configuration de routeurs, reportez-vous à la section Configuration d'un routeur IPv4.
Configuration d'interfaces dans le cadre d'un réseau local virtuel. Pour plus d'informations, reportez-vous à la section Administration de réseaux locaux virtuels.
Configuration d'interfaces dans le cadre d'un groupement. Pour plus d'informations, reportez-vous à la section Présentation des groupements de liens.
Ajout d'une interface à un groupe IPMP. Pour obtenir les instructions relatives à la configuration d'un groupe IPMP, reportez-vous à la section Configuration de groupes IPMP
Cette section contient des informations relatives à la configuration d'une interface réseau, à partir de la version Solaris 10 1/06. Reportez-vous aux sections suivantes pour plus d'informations sur la configuration d'interfaces au sein d'un groupe :
Pour configurer une interface dans le cadre d'un réseau local virtuel, reportez-vous à la section Administration de réseaux locaux virtuels.
Pour configurer une interface dans le cadre d'un groupement, reportez-vous à la section Présentation des groupements de liens.
Pour configurer une interface dans le cadre d'un groupe IPMP, reportez-vous à la section Configuration de groupes IPMP.
À partir de la version Solaris 10 1/06, cette procédure permet d'identifier les interfaces disponibles sur un système et d'afficher leur statut. Elle indique également les interfaces actuellement montées. Si vous exécutez une version antérieure à Solaris 10 3/05, reportez-vous à la section Méthode d'obtention d'informations sur une interface spécifique.
Sur le système sur lequel vous devez configurer les interfaces, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Identifiez les interfaces installées sur le système.
# dladm show-link |
Lors de cette étape, vous exécutez la commande dladm décrite à la page de manuel dladm(1M). Cette commande signale tous les pilotes d'interface qu'elle détecte, que les interfaces soient configurées ou non.
Identifiez les interfaces du système actuellement montées.
# ifconfig -a |
La commande ifconfig compte de nombreuses fonctions, dont le montage d'interface. Pour plus d'informations, reportez-vous à la page de manuel ifconfig(1M).
L'exemple suivant illustre l'affichage du statut à l'aide de la commande dladm.
# dladm show-link ce0 type: legacy mtu: 1500 device: ce0 ce1 type: legacy mtu: 1500 device: ce1 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 bge2 type: non-vlan mtu: 1500 device: bge2 |
D'après la sortie de la commande dladm show-link, quatre pilotes d'interface sont disponibles pour l'hôte local. Les interfaces ce et bge peuvent être configurées pour des réseaux locaux virtuels (VLAN). Toutefois, seules les interfaces GLDV3 de type non-VLAN peuvent être utilisées pour des groupements de liens.
L'exemple suivant illustre l'affichage du statut à l'aide de la commande ifconfig - a.
# ifconfig -a lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 3 inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255 ether 0:3:ba:7:84:5e bge0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4>mtu 1500 index 2 inet 10.8.57.39 netmask ffffff00 broadcast 10.8.57.255 ether 0:3:ba:29:fc:cc |
La sortie de la commande ifconfig -a affiche les statistiques des interfaces ce0 et bge0 uniquement. Seules les interfaces ce0 et bge0 ont été montées et sont en mesure de recevoir le trafic réseau. Elles peuvent être utilisées dans le cadre d'un VLAN. Le montage de bge0 empêche son utilisation dans le cadre d'un groupement.
Pour configurer une interface, effectuez la procédure suivante. Si vous utilisez la version Solaris 10 3/05, suivez la procédure Ajout d'une interface physique après l'installation dans Solaris 10 3/05 UNIQUEMENT.
Sélectionnez les adresses IPv4 à utiliser pour les interfaces supplémentaires.
Assurez-vous de l'installation sur le système de l'interface physique à configurer. Pour plus d'informations sur l'installation de NIC achetées séparément, consultez les instructions correspondantes fournies par le fabricant.
Si vous venez d'installer l'interface, exécutez une reconfiguration au démarrage avant de passer à l'étape suivante.
Sur le système sur lequel vous devez configurer les interfaces, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Identifiez les interfaces installées sur le système.
# dladm show-link |
Configurez et montez chaque interface.
# ifconfig interface plumb up |
Par exemple, pour qfe0, vous devez taper :
# ifconfig qfe0 plumb up |
Les interfaces explicitement configurées à l'aide de la commande ifconfig ne sont pas conservées à la réinitialisation.
Assignez un masque de réseau et une adresse IPv4 à l'interface.
# ifconfig interface IPv4-address netmask+netmask |
Par exemple, pour qfe0, vous devez taper :
# ifconfig qfe0 192.168.84.3 netmask + 255.255.255.0 |
Vous pouvez indiquer une adresse IPv4 en notation IPv4 standard ou CIDR.
Assurez-vous que les interfaces nouvellement configurées sont montées et configurées ou affichent l'indicateur d'état « UP ».
# ifconfig -a |
Vérifiez la ligne d'état de chaque interface affichée. Veillez à ce que la sortie contienne l'indicateur UP sur la ligne d'état, par exemple :
qfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 |
(Facultatif) Pour conserver la configuration des interfaces après les réinitialisations, suivez les instructions ci-dessous :
Créez un fichier /etc/hostname.interface pour chaque interface à configurer.
Par exemple, pour ajouter l'interface qfe0, vous devez créer le fichier suivant :
# vi /etc/hostname.qfe0 |
Si vous créez d'autres fichiers de nom d'hôte pour la même interface, ces fichiers doivent également suivre le format de nom hostname.[0-9]*, par exemple : hostname.qfe0.a123. Des noms tels que hostname.qfe0.bak ou hostname.qfe0.old ne sont pas valides et seront ignorés par les scripts pendant l'initialisation du système.
Une interface ne doit contenir qu'un seul fichier de nom d'hôte correspondant. Si vous créez un autre fichier de nom d'hôte pour une interface avec un nom de fichier valide, tels que /etc/hostname.qfe et /etc/hostname.qfe.a123 , les scripts d'initialisation tenteront de configurer les données en référençant le contenu des deux fichiers de nom d'hôte et cela peut générer des erreurs. Pour éviter ce genre d'erreurs, indiquez un nom de fichier non valide pour le fichier de nom d'hôte à ne pas utiliser dans la configuration.
Modifiez le fichier /etc/hostname.interface.
Ajoutez l'adresse IPv4 de l'interface dans le fichier. Vous pouvez pour cela utiliser la notation IPv4 standard ou la notation CIDR. Vous pouvez également ajouter au fichier un masque de réseau et des informations de configuration supplémentaires.
Pour ajouter une adresse IPv6 à une interface, reportez-vous à la section Modification de la configuration d'interface IPv6 pour les hôtes et les serveurs
Pour les versions Solaris 10 11/06 et les versions précédentes de Oracle Solaris 10, ajoutez les entrées des nouvelles interfaces dans le fichier /etc/inet/ipnodes.
Ajoutez les entrées des nouvelles interfaces dans le fichier /etc/inet/hosts .
Effectuez une reconfiguration au démarrage.
# reboot -- -r |
Assurez-vous que l'interface créée dans le fichier /etc/hostname. interface a été configurée.
# ifconfig -a |
Reportez-vous à l'Exemple 6–2.
L'exemple illustre la configuration des interfaces qfe0 et qfe1 sur un hôte. Ces interfaces sont persistantes en cas de réinitialisation.
# dladm show-link eri0 type: legacy mtu: 1500 device: eri0 qfe0 type: legacy mtu: 1500 device: qfe0 qfe1 type: legacy mtu: 1500 device: qfe1 qfe2 type: legacy mtu: 1500 device: qfe2 qfe3 type: legacy mtu: 1500 device: qfe3 bge0 type: non-vlan mtu: 1500 device: bge0 # vi /etc/hostname.qfe0 192.168.84.3 netmask 255.255.255.0 # vi /etc/hostname.qfe1 192.168.84.72 netmask 255.255.255.0 # vi /etc/inet/hosts # Internet host table # 127.0.0.1 localhost 10.0.0.14 myhost 192.168.84.3 interface-2 192.168.84.72 interface-3 For Solaris 10 11/06 and earlier releases:# vi /etc/inet/ipnodes 10.0.0.14 myhost 192.168.84.3 interface-2 192.168.84.72 interface-3 |
À ce stade, vous devez réinitialiser le système.
# reboot -- -r |
Une fois le système réinitialisé, vous devez vérifier la configuration des interfaces.
ifconfig -a # ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.14netmask ff000000 broadcast 10.255.255.255 ether 8:0:20:c1:8b:c3 qfe0:flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 192.168.84.3 netmask ffffff00 broadcast 192.255.255.255 ether 8:0:20:c8:f4:1d qfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 4 inet 192.168.84.72 netmask ffffff00 broadcast 10.255.255.255 ether 8:0:20:c8:f4:1e |
Pour configurer une adresse IPv6 sur une interface, reportez-vous à la section Activation d'une interface IPv6 pour la session actuelle.
Pour configurer la détection de basculement et le rétablissement à l'aide d'IPMP (IP Network Multipathing, multiacheminement sur réseau IP), reportez-vous au Chapitre 31Administration d'IPMP (tâches).
Pour supprimer une interface physique, effectuez la procédure suivante. Si vous utilisez la version antérieure Solaris 10 3/05, reportez-vous à la section Suppression d'une interface physique dans Solaris 10 3/05 UNIQUEMENT.
Sur le système sur lequel vous devez supprimer l'interface, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Supprimez l'interface physique.
# ifconfig interface down unplumb |
Par exemple, pour supprimer l'interface qfe1, tapez :
# ifconfig qfe1 down unplumb |
Pour configurer les adresses MAC, procédez comme suit.
Certaines applications exigent que les adresses MAC de toutes les interfaces d'un hôte soient uniques. Toutefois, les systèmes SPARC possèdent une adresse MAC à l'échelle du système appliquée à toutes les interfaces par défaut. Vous devez configurer les adresses MAC d'origine des interfaces d'un système SPARC dans les deux contextes suivants :
Dans le cadre d'un regroupement de liens, vous devez utiliser les adresses MAC d'origine des interfaces de la configuration de regroupement.
Dans le cadre des groupes IPMP, chaque interface doit posséder une adresse MAC unique. Ces interfaces doivent utiliser les adresses MAC d'origine.
Le paramètre EEPROM local-mac-address? détermine si les interfaces du système SPARC utilisent l'adresse MAC du système ou leur adresse MAC unique. La procédure suivante indique comment vérifier la valeur actuelle du paramètre local-mac-address? à l'aide de la commande eeprom et la modifier, au besoin.
Sur le système sur lequel vous devez configurer les interfaces, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Déterminez si toutes les interfaces du système utilisent l'adresse MAC système.
# eeprom local-mac-address? local-mac-address?=false |
Dans cet exemple, la réponse à la commande eeprom, local-mac-address?=false, indique que toutes les interfaces utilisent l'adresse MAC du système. Pour que les interfaces puissent devenir membres d'un groupe IPMP, vous devez remplacer local-mac-address?=false par local-mac-address?=true. Vous devez également remplacer local-mac-address?=false par local-mac-address?=true pour les regroupements.
Si nécessaire, modifiez la valeur de local-mac-address? comme suit :
# eeprom local-mac-address?=true |
À la réinitialisation du système, les interfaces avec adresses MAC d'origine utilisent celles-ci plutôt que l'adresse MAC du système. Les interfaces sans adresses MAC d'origine continuent d'utiliser les adresses MAC d'origine.
Vérifiez l'adresse MAC de toutes les interfaces du système.
Recherchez des cas dans lesquels plusieurs interfaces possèdent la même adresses MAC. Dans cet exemple, toutes les interfaces utilisent l'adresse MAC système 8:0:20:0:0:1 .
ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.112 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:0:0:1 ce0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.114 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:0:0:1 ce1: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.118 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:0:0:1 |
Passez à l'étape suivante uniquement si plusieurs interfaces réseau possèdent une même adresse MAC. Sinon, passez à la dernière étape.
Au besoin, configurez manuellement les interfaces restantes de sorte que chaque interface possède une adresse MAC unique.
Indiquez une adresse MAC unique dans le fichier /etc/hostname.interface pour l'interface en question.
Dans l'exemple de l'étape 4, vous devez configurer les interfaces ce0 et ce1 avec des adresses MAC gérées localement. Par exemple, pour reconfigurer l'interface ce1 avec l'adresse MAC gérée localement 06:05:04:03:02, vous devez ajouter au fichier /etc/hostname.ce1 la ligne suivante :
ether 06:05:04:03:02 |
Pour éviter tout risque de conflit entre des adresses MAC configurées manuellement avec d'autres adresses MAC de votre réseau, configurez toujours les adresses MAC administrées localement tel que défini par la norme IEEE 802.3.
La commande ifconfig ether permet également de configurer l'adresse MAC d'une interface pour la session actuelle. Cependant, les modifications effectuées directement avec la commande ifconfig ne sont pas conservées après la réinitialisation. Consultez la page de manuel ifconfig(1M) pour obtenir des informations supplémentaires.
Redémarrez le système.
Une interface réseau connecte un système à un réseau. Un système Oracle Solaris peut contenir deux types d'interfaces : physique et logique. Une interface physique comporte un pilote logiciel et un connecteur permettant la connexion du média réseau, tel qu'un câble Ethernet. Pour des raisons de gestion ou de disponibilité, il est possible de regrouper les interfaces physiques. Configurée au sein d'une interface physique, une interface logique permet d'ajouter des adresses et de créer des points extrémités de tunnel.
Les interfaces réseau logiques sont décrites dans les tâches pour lesquelles elles sont utilisées : tâches IPv6, IPMP, DHCP et autres.
En général, les systèmes informatiques présentent au moins une interface physique intégrée par le fabricant sur la carte mère. Certains systèmes peuvent être dotés de plusieurs interfaces intégrées.
Outre les interfaces intégrées, vous pouvez ajouter au système des interfaces acquises séparément. Une interface ayant fait l'objet d'un achat distinct est appelée une NIC (Network Interface Card, carte d'interface réseau). Pour installer une NIC, vous devez suivre les instructions du fabricant.
Les NIC sont également appelées des adaptateurs réseau.
Lors de l'installation du système, le programme d'installation Oracle Solaris détecte les interfaces installées et affiche leur nom. Vous devez configurer au moins une interface de la liste. La première interface configurée lors de l'installation devient l'interface réseau principale. L'adresse IP de l'interface réseau principale est associée au nom d'hôte configuré du système, stocké dans le fichier /etc/nodename. Toutefois, si vous le souhaitez, vous pouvez configurer des interfaces supplémentaires lors de l'installation ou ultérieurement.
Chaque interface physique est identifiée par un nom de périphérique unique. La syntaxe des noms de périphérique est la suivante :
<driver-name><instance-number> |
Les noms de périphérique sur les systèmes Oracle Solaris peuvent comprendre les noms ce, hme, bge, e1000g et de nombreux autres noms de périphérique. La variable numéro_instance peut présenter une valeur comprise entre zéro et n, en fonction du nombre d'interfaces de ce type de pilote installées sur le système.
Par exemple, pour une interface Fast Ethernet 100BASE-TX, fréquemment utilisée en tant qu'interface réseau principale sur les systèmes hôte et serveur, eri, qfe et hme sont des noms de pilote typiques. Si l'interface Fast Ethernet est utilisée tant qu'interface réseau principale, son nom de périphérique est du type eri0 ou qfe0.
Les NIC telles que eri et hme sont dotées d'une seule interface. Toutefois, de nombreuses marques de NIC présentent plusieurs interfaces. Par exemple, la carte Quad Fast Ethernet (qfe) possède quatre interfaces, nommées de qfe0 à qfe3 respectivement.
Une interface doit être montée avant de transporter le trafic entre le système et le réseau. Le montage consiste à associer une interface à un nom de périphérique. Ensuite, les flux sont configurés de manière à ce que le protocole IP puisse utiliser l'interface. Le montage concerne aussi bien les interfaces physiques que les interfaces logiques. Il intervient dans le cadre de la séquence d'initialisation ou de la syntaxe appropriée de la commande ifconfig.
Une interface configurée lors de l'installation est montée automatiquement. Si vous décidez de ne pas configurer les interfaces supplémentaires du système lors de l'installation, celles-ci ne sont pas montées.
À partir de la version Solaris 10 1/06, Oracle Solaris prend en charge les deux types d'interfaces suivants :
Interfaces héritées : il s'agit d'interfaces DLPI et GLDv2. Les interfaces eri, qfe et ce sont toutes trois des interfaces héritées. Lorsque vous vérifiez le statut d'interface à l'aide de la commande dladm show-link, ces interfaces sont signalées comme étant "héritées".
Interfaces non-VLAN : il s'agit d'interfaces GLDv3.
À présent, GLDv3 est pris en charge sur les types d'interfaces suivants : bge, xge et e1000g.
Si vous utilisez Solaris 3/05, reportez-vous à la section Configuration de VLAN sous Solaris 10 3/05 UNIQUEMENT.
Un réseau local virtuel (Virtual Local Network, VLAN) est une sous-division d'un réseau local située sur la couche de liaison de données de la pile du protocole TCP/IP. Vous pouvez créer des VLAN pour tout réseau local utilisant la technologie de commutation. L'assignation de groupes d'utilisateurs à des VLAN permet d'améliorer l'administration et la sécurité du réseau local entier. Vous pouvez également assigner les interfaces d'un même système à des VLAN différents.
La création de VLAN est utile dans les cas suivants :
Création de divisions logiques de groupes de travail
Supposons par exemple que tous les hôtes d'un étage d'un immeuble sont connectés à un réseau local commuté. Vous pouvez dans ce cas créer un VLAN distinct pour chaque groupe de travail de cet étage.
Application de stratégies de sécurité différentes selon les groupes de travail
Par exemple, les besoins en matière de sécurité varient considérablement entre un service financier et un service informatique. Si les systèmes de ces deux services partagent le même réseau local, vous pouvez alors créer un VLAN distinct pour chaque service et appliquer la stratégie de sécurité qui convient à chaque VLAN.
Division de groupes de travail en domaines de diffusion gérables
Les VLAN réduisent la taille des domaines de diffusion et améliorent ainsi l'efficacité du réseau.
La technologie de commutation du réseau local permet d'organiser les systèmes d'un réseau local en plusieurs VLAN. Pour diviser un réseau local en VLAN, vous devez obtenir des commutateurs qui prennent en charge la technologie de réseau local virtuel. Vous pouvez configurer tous les ports d'un commutateur de manière à ce qu'ils servent un VLAN unique ou plusieurs VLAN (selon la topologie du réseau). La configuration des ports d'un commutateur varie en fonction du fabricant de ce dernier.
La figure suivante illustre un réseau local dont l'adresse de sous-réseau est 192.168.84.0. Ce réseau local est divisé en trois VLAN (rouge, jaune et bleu).
La connectivité sur le LAN 192.168.84.0 est gérée par les commutateurs 1 et 2. Le VLAN rouge contient des systèmes dans le groupe de travail de la comptabilité. ceux des ressources humaines au VLAN jaune. Les systèmes du groupe de travail des technologies de l'information sont assignés au VLAN bleu.
Chaque VLAN inclus dans un réseau local est identifié par un repère de VLAN, ou ID de VLAN (VID). Le VID est assigné pendant la configuration du VLAN. Il s'agit d'un identificateur à 12 bits, compris entre 1 et 4094, qui fournit une identité unique à chaque VLAN. Sur la Figure 6–1, les VLAN possèdent les VID suivants : 123 (bleu), 456 (jaune) et 789 (rouge).
Pour que les commutateurs prennent en charge ces VLAN, vous devez leur assigner un VID à chaque port lors de la configuration. Le VID du port doit être identique à celui assigné à l'interface de connexion du port (voir figure suivante).
La Figure 6–2 présente plusieurs hôtes qui sont connectés à des VLAN. Deux hôtes appartiennent au même VLAN. Sur cette figure, les interfaces réseau principales des trois hôtes se connectent au commutateur 1. L'hôte A est membre du VLAN bleu. L'interface de l'hôte A est de ce fait configurée à l'aide du VID 123. Cette interface se connecte au port 1 du commutateur 1, qui est ensuite configuré à l'aide du VID 123. L'hôte B est membre du VLAN jaune dont le VID est 456. L'interface de l'hôte B se connecte au port 5 du commutateur 1, qui est configuré à l'aide du VID 456. Enfin, l'interface de l'hôte C se connecte au port 9 du commutateur 1. Le VLAN bleu est configuré à l'aide du VID 123.
Cette figure montre également qu'un seul hôte peut appartenir à plusieurs VLAN. Par exemple, l'hôte A comporte deux VLAN configurés sur l'interface. Le deuxième VLAN est configuré avec le numéro VID 456 et est connecté au port 3 qui est également configuré avec le numéro VID 456. Par conséquent, l'hôte A est membre des VLAN bleu et jaune.
Lors de la configuration d'un VLAN, vous devez spécifier le point de connexion physique du VLAN. La valeur du point de connexion physique s'obtient par la formule suivante :
driver-name + VID * 1000 + device-instance |
Remarque : le numéro de instance périphérique doit être inférieur à 1 000.
Exemple : la formule suivante permet de créer le point de connexion physique d'une interface ce1 configurée sur le VLAN 456 :
ce + 456 * 1000 + 1= ce456001 |
Pour planifier la configuration des VLAN de votre réseau, suivez la procédure ci-dessous :
Observez la topologie du réseau local et déterminez les emplacements appropriés pour créer des VLAN.
La Figure 6–1 illustre un exemple simple de topologie de réseau.
Créez un schéma de numérotation pour les VID et assignez un VID à chaque VLAN.
Votre réseau dispose peut-être déjà d'un tel schéma de numérotation. Dans ce cas, créez des VID compris dans le schéma de numérotation existant.
Sur chaque système, déterminez quelles interfaces seront membres de quel VLAN.
Déterminez les interfaces configurées sur un système.
# dladm show-link |
Déterminez les VID associés aux liaisons de données du système.
Créez des points de connexion physiques pour chaque interface devant être configurée avec un VLAN.
Vous pouvez configurer les interfaces d'un même système sur des VLAN différents.
Vérifiez les connexions des interfaces sur les commutateurs du réseau.
Notez le VID de chaque interface ainsi que le port du commutateur auquel elle est connectée.
Configurez chaque port du commutateur avec le même VID que celui de l'interface à laquelle il est connecté.
Reportez-vous aux instructions fournies par le fabricant du commutateur pour de plus amples informations sur la configuration.
Si vous utilisez Solaris 3/05, reportez-vous à la section Configuration de VLAN sous Solaris 10 3/05 UNIQUEMENT.
Oracle Solaris prend désormais en charge les VLAN sur les types d'interface suivants :
ce
bge
xge
e1000g
Sur les interfaces héritées, seule l'interface ce peut devenir membre d'un VLAN. Vous pouvez configurer des interfaces de types différents sur le même VLAN.
Vous pouvez configurer plusieurs VLAN dans un groupe IPMP. Pour plus d'informations sur les groupes IPMP, reportez-vous à la section Configurations d'interfaces IPMP.
Si vous utilisez Solaris 10 3/05, reportez-vous à la procédure décrite à la section Configuration de VLAN statiques dans Solaris 10 3/05 UNIQUEMENT.
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Déterminez les types d'interface utilisés sur votre système.
# dladm show-link |
La sortie suivante énumère les types d'interface disponibles :
ce0 type: legacy mtu: 1500 device: ce0 ce1 type: legacy mtu: 1500 device: ce1 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 bge2 type: non-vlan mtu: 1500 device: bge2 |
Configurez une interface en tant que membre d'un VLAN.
# ifconfig interface-PPA plumb IP-address up |
Exemple : la commande suivante permet de configurer l'interface ce1 avec l'adresse IP 10.0.0.2 sur un VLAN portant le VID 123 :
# ifconfig ce123001 plumb 10.0.0.2 up |
Vous pouvez assigner des adresses IPv4 et IPv6 à des VLAN tout comme pour les autres interfaces.
(Facultatif) Pour conserver les paramètres du VLAN à chaque réinitialisation, créez un fichier nommé nom d'hôte.point de connexion physique pour chaque interface membre du VLAN.
# cat hostname.interface-PPA IPv4-address |
Sur le commutateur, définissez les repères des VLAN ainsi que leurs ports afin qu'ils correspondent avec les VLAN configurés sur le système.
L'exemple suivant illustre la commande de configuration des périphériques bge1 et bge2 sur un VLAN portant le VID 123.
# dladm show-link ce0 type: legacy mtu: 1500 device: ce0 ce1 type: legacy mtu: 1500 device: ce1 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 bge2 type: non-vlan mtu: 1500 device: bge2 # ifconfig bge123001 plumb 10.0.0.1 up # ifconfig bge123002 plumb 10.0.0.2 up # cat hostname.bge123001 10.0.0.1 # cat hostname.bge123002 10.0.0.2 # ifconfig -a lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 bge123001: flags=201000803<UP,BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 2 inet 10.0.0.1 netmask ff000000 broadcast 10.255.255.255 ether 0:3:ba:7:84:5e bge123002:flags=201000803 <UP,BROADCAST,MULTICAST,IPv4,CoS> mtu 1500 index 3 inet 10.0.0.2 netmask ff000000 broadcast 10.255.255.255 ether 0:3:ba:7:84:5e ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4>mtu 1500 index 4 inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255 ether 0:3:ba:7:84:5e # dladm show-link ce0 type: legacy mtu: 1500 device: ce0 ce1 type: legacy mtu: 1500 device: ce1 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 bge2 type: non-vlan mtu: 1500 device: bge2 bge123001 type: vlan 123 mtu: 1500 device: bge1 bge123002 type: vlan 123 mtu: 1500 device: bge2 |
Dans la version d'origine de Oracle Solaris 10 et les versions précédentes, les groupements de liens n'étaient pas pris en charge. Pour créer des groupements de liens dans une version précédente de Oracle Solaris, vous pouvez utiliser la fonction Sun Trunking (reportez-vous au Sun Trunking 1.3 Installation and Users Guide).
Oracle Solaris permet d'organiser les interfaces réseaux sous la forme de groupements de liens. Un groupement de liens est un ensemble de plusieurs interfaces d'un système configurées en une seule unité logique. Le groupement de liens, aussi appelé jonction, est défini par la norme IEEE 802.3ad Link Aggregation Standard.
La norme IEEE 802.3ad décrit la manière d'associer les capacités de plusieurs liens Ethernet duplex intégral à un seul lien logique. Un tel groupement de liens est ensuite traité en tant que lien unique.
Le groupement de liens fournit les fonctions suivantes :
Plus grande bande passante – Les capacités de plusieurs liens sont réunies en un seul lien logique.
Basculement/rétablissement automatique – Le trafic sur un lien rompu est basculé vers un lien actif du groupement.
Équilibrage de charge – Le trafic entrant et sortant est distribué en fonction des stratégies d'équilibrage de charge sélectionnées par l'utilisateur (par exemple, adresses sources et cibles MAC ou IP).
Prise en charge de la redondance – Deux systèmes peuvent être configurés avec des groupements parallèles.
Administration améliorée – Toutes les interfaces sont administrées de façon unitaire.
Réduction du nombre de drains dans le pool d'adresses réseau – Le groupement entier peut être assigné à une seule adresse IP.
La topologie élémentaire d'un groupement de liens se définit par un ensemble unique contenant plusieurs interfaces physiques. La création de groupements de liens élémentaires est utile dans les cas suivants :
Systèmes exécutant une application avec un trafic distribué intense. Dédiez dans ce cas un groupement de liens au trafic de cette application.
Sites avec un nombre d'adresses IP limité, mais sur lesquels une large bande passante est nécessaire. Grâce au groupement de liens, vous pouvez réunir un grand nombre d'interfaces sous une seule adresse IP.
Sites sur lesquels les interfaces internes doivent être masquées. Avec l'adresse IP d'un groupement de liens, les applications externes n'ont pas accès aux interfaces.
La Figure 6–3 illustre un groupement de liens créé sur un serveur hébergeant un site Web connu. La bande passante doit être élargie afin d'assurer le bon fonctionnement du trafic de requêtes entre les clients en ligne et le serveur de la base de données du site. Pour des raisons de sécurité, les interfaces individuelles de ce serveur doivent être masquées aux applications externes. La solution consiste à créer un groupement aggr1 avec l'adresse IP 192.168.50.32. Ce groupement se compose de trois interfaces, de bge0 à bge2. Chaque interface est dédiée à la transmission du trafic sortant en réponse aux requêtes des clients. Toutes ces interfaces possèdent la même adresse sortante sur le trafic de paquets, aggr1 : 192.168.50.32.
La Figure 6–4 décrit un réseau local constitué de deux systèmes possédant chacun un groupement. Les deux systèmes sont connectés par un commutateur. Pour exécuter un groupement par le biais d'un commutateur, celui-ci doit prendre en charge la technologie de groupement. Ce type de configuration s'applique particulièrement bien aux systèmes à haute disponibilité ainsi qu'aux systèmes redondants.
Sur cette figure, le système A possède un groupement composé de deux interfaces, bge0 et bge1. Ces interfaces sont connectées au commutateur par le biais de ports groupés. Le système B possède un groupement de quatre interfaces, allant de e1000g0 àe1000g3. Ces interfaces sont également connectées au commutateur par le biais de ports groupés.
La topologie d'un groupement de liens dos à dos consiste en deux systèmes distincts directement connectés l'un à l'autre (voir figure suivante). Ces systèmes exécutent deux groupements parallèles.
Sur cette figure, le périphérique bge0 du système A est directement connecté au périphérique bge0 du système B, etc. Cela permet aux systèmes A et B de prendre en charge la redondance ainsi que les services de haute disponibilité et d'assurer des communications haut débit entre les deux systèmes. Chaque système possède une interface ce0 dédiée au flux du trafic au sein du réseau local.
Les groupements de liens dos à dos sont le plus fréquemment utilisés avec les serveurs de base de données mis en miroir. Chaque serveur doit être mis à jour en même temps que l'autre et nécessite pour cela une large bande passante ainsi qu'un flux haut débit et une grande fiabilité. Les groupements de liens dos à dos sont le plus fréquemment utilisés dans les centres de données.
Avant de mettre en oeuvre un groupement de liens, définissez une stratégie pour le trafic sortant. Cette stratégie peut spécifier la manière dont les paquets doivent être distribués entre les différents liens disponibles dans le groupement, établissant ainsi un équilibrage de charge. Vous pouvez élaborer la stratégie pour le groupement avec l'un des spécificateurs de couche décrits ci-dessous :
L2 – Détermine le lien sortant en hachant l'en-tête MAC (L2) de chaque paquet.
L3 – Détermine le lien sortant en hachant l'en-tête IP (L3) de chaque paquet.
L4 – Détermine le lien sortant en hachant l'en-tête TCP, UDP ou autre en-tête ULP (L4) de chaque paquet.
Vous pouvez également combiner plusieurs de ces stratégies. L4 constitue la stratégie par défaut. Pour plus d'informations, reportez-vous à la page de manuel dladm(1M).
Si la topologie du groupement nécessite une connexion à un commutateur, vérifiez si le commutateur prend en charge le protocole de contrôle des groupements de liens (Link Aggregation Control Protocol, LACP). Si c'est le cas, vous devez configurer le LACP de manière à ce qu'il fonctionne avec le commutateur et le groupement. Cependant, vous pouvez définir l'un des modes de fonctionnement suivants pour le LACP :
Off (inactif) – Mode des groupements par défaut. Ce mode ne génère pas les paquets LACP, ou PDULACP.
Active (actif) – Ce mode génère des PDULACP à une fréquence d'intervalle personnalisable.
Passive (passif) – Ce mode ne génère un PDULACP que lorsqu'il en reçoit un du commutateur. Si le commutateur et le groupement sont définis sur le mode passif, ils ne peuvent échanger aucun PDULACP.
Pour plus d'informations sur la syntaxe à utiliser, reportez-vous à la page de manuel dladm(1M) ainsi qu'à la documentation fournie par le fabricant du commutateur.
Vous devez respecter les conditions suivantes pour configurer un groupement de liens :
Le groupement doit être créé à l'aide de la commande dladm.
Une interface montée ne peut pas être membre d'un groupement.
Les interfaces doivent être de type GLDv3 : xge, e1000g et bge.
Toutes les interfaces du groupement doivent s'exécuter à la même vitesse et en mode duplex intégral.
Vous devez définir les adresses MAC sur True dans le paramètre EEPROM local-mac-address? (voir les instructions de la section Garantie de l'unicité de l'adresse MAC d'une interface).
Les groupements de liens ne fonctionnent qu'avec des liens de même vitesse, en mode duplex intégral et point à point. Assurez-vous que les interfaces de votre groupement répondent à ces critères.
Configurez les éléments suivants avant d'insérer un commutateur dans la topologie du groupement :
Les ports du commutateur doivent pouvoir être utilisés dans un groupement.
Si le commutateur prend en charge le LACP, celui-ci doit être configuré en mode actif ou passif.
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Identifiez les interfaces installées sur le système.
# dladm show-link |
Identifiez les interfaces montées.
# ifconfig -a |
# dladm create-aggr -d interface -d interface [...]key |
Nom du périphérique correspondant à l'interface membre du groupement.
Numéro identifiant le groupement. Le plus petit numéro de clé est 1. Une clé de ne peut avoir le numéro zéro.
Exemple :
# dladm create-aggr -d bge0 -d bge1 1 |
Configurez et montez le nouveau groupement créé.
# ifconfig aggrkey plumb IP-address up |
Exemple :
# ifconfig aggr1 plumb 192.168.84.14 up |
Vérifiez le statut du groupement que vous venez de créer.
# dladm show-aggr |
La sortie suivante s'affiche :
key: 1 (0x0001) policy: L4 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby |
Cette sortie indique qu'un groupement avec la clé 1 et la stratégie L4 a été créé.
(Facultatif) Pour conserver la configuration des adresses IP du groupement de liens à chaque réinitialisation :
Si le groupement possède des adresses IPv4, créez un fichier nommé /etc/hostname.aggrclé. Si le groupement possède des adresses IPv6, créez un fichier nommé /etc/hostname6.aggrclé.
Saisissez l'adresse IPv4 ou IPv6 du groupement de liens dans le fichier.
Par exemple, pour conserver la configuration des adresses IP du groupement créé dans cette procédure, créez le fichier suivant :
# vi /etc/hostname.aggr1 192.168.84.14 |
Effectuez une reconfiguration au démarrage.
# reboot -- -r |
Assurez-vous que la configuration du groupement de liens définie dans le fichier /etc/hostname.aggr.key a été appliquée.
# ifconfig -a . . aggr1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 192.168.84.14 netmask ff000000 broadcast 192.255.255. |
Cet exemple présente les commandes à exécuter pour créer un groupement de liens constitués de deux périphériques, bge0 et bge1, ainsi que la sortie obtenue.
# dladm show-link ce0 type: legacy mtu: 1500 device: ce0 ce1 type: legacy mtu: 1500 device: ce1 bge0 type: non-vlan mtu: 1500 device: bge0 bge1 type: non-vlan mtu: 1500 device: bge1 bge2 type: non-vlan mtu: 1500 device: bge2 # ifconfig -a lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255 ether 0:3:ba:7:84:5e # dladm create-aggr -d bge0 -d bge1 1 # ifconfig aggr1 plumb 192.168.84.14 up # dladm show-aggr key: 1 (0x0001) policy: L4 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby # ifconfig -a lo0: flags=2001000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ce0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.84.253 netmask ffffff00 broadcast 192.168.84.255 ether 0:3:ba:7:84:5e aggr1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 192.168.84.14 netmask ff000000 broadcast 192.255.255.255 ether 0:3:ba:7:84:5e |
Remarque : les deux interfaces utilisées pour ce groupement n'ont pas été montées au préalable par ifconfig.
Cette procédure permet d'apporter les modifications suivantes à la définition d'un groupement :
modification de la stratégie pour le groupement ;
modification du mode pour le groupement.
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Modifiez le groupement afin de changer de stratégie.
# dladm modify-aggr -Ppolicy key |
Nom de la stratégie ou des stratégies telles que L2, L3 et L4 (voir l'explication de la section Stratégies et équilibrage de charge).
Numéro identifiant le groupement. Le plus petit numéro de clé est 1. Une clé de ne peut avoir le numéro zéro.
Si LACP est exécuté sur le commutateur auquel les périphériques du groupement sont connectés, modifiez le groupement afin qu'il prenne en charge le protocole LACP.
Si le commutateur exécute le LACP en mode passif, veillez à définir le groupement sur le mode actif.
# dladm modify-aggr -l LACP mode -t timer-value key |
Mode LACP dans lequel le groupement s'exécute. Les valeurs de cette variable sont les suivantes : active, passive et off.
Valeur de l'horloge du LACP (short ou long).
Numéro identifiant le groupement. Le plus petit numéro de clé est 1. Une clé de ne peut avoir le numéro zéro.
L'exemple suivant décrit la procédure à suivre pour modifier la stratégie de groupement aggr1 en L2 et activer le mode LACP utilisé.
# dladm modify-aggr -P L2 1 # dladm modify-aggr -l active -t short 1 # dladm show-aggr key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby |
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Supprimez une interface du groupement.
# dladm remove-aggr -d interface |
Cet exemple décrit la procédure de suppression des interfaces du groupement aggr1.
# dladm show-aggr key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby # dladm remove-aggr -d bge1 1 # dladm show-aggr key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached |
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Supprimez le groupement.
# dladm delete-aggr key |
Numéro identifiant le groupement. Le plus petit numéro de clé est 1. Une clé de ne peut avoir le numéro zéro.
Cet exemple décrit la procédure de suppression du groupement aggr1.
# dladm show-aggr key: 1 (0x0001) policy: L2 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state # dladm delete-aggr -d 1 |
De la même manière que vous configurez des réseaux VLAN par le biais d'une interface, vous pouvez également créer des VLAN via un groupement de liens. Les réseaux VLAN sont décrits à la section Administration de réseaux locaux virtuels. Cette section décrit la configuration des réseaux VLAN et les groupements de liens.
Configurez d'abord le groupement de liens avec une adresse IP valide. Notez la valeur key du groupement. Vous en aurez besoin pour créer des réseaux VLAN via le groupement. Pour créer des groupements de liens, reportez-vous à la section Procédure de création d'un groupement de liens.
Si un groupement de liens a déjà été créé auparavant, retrouvez la clé de groupement correspondante.
# dladm show-aggr |
Créez les réseaux VLAN via le groupement de liens.
# ifconfig aggrVIDkey plumb |
où
L'ID du VLAN
La clé du groupement de liens par le biais duquel le réseau VLAN est créé. La clé doit comporter trois chiffres. Par exemple, si la clé du groupement est 1, le numéro de clé inclus dans le nom du réseau local virtuel est 001.
Répétez l'étape 2 pour créer d'autres VLAN via le groupement.
Configurez les VLAN avec des adresses IP valides.
Pour créer des configurations persistantes VLAN, ajoutez les informations d'adresse IP correspondant aux fichiers de configuration /etc/hostname.VLAN.
Dans cet exemple, deux réseaux VLAN sont configurés sur un groupement de liens. Le résultat de la commande dladm show-aggr indique que la clé du groupement de liens est 1. Les identifiants VLAN (VID) 193 et 194 sont respectivement assignés aux réseaux VLAN.
# dladm show-aggr key: 1 (0x0001) policy: L4 address: 0:3:ba:7:84:5e (auto) device address speed duplex link state bge0 0:3:ba:7:b5:a7 1000 Mbps full up attached bge1 0:3:ba:8:22:3b 0 Mbps unknown down standby # ifconfig aggr193001 plumb # ifconfig aggr193001 192.168.10.5/24 up # ifconfig aggr194001 plumb # ifconfig aggr194001 192.168.10.25/24 up # vi /etc/hostname.aggr193001 192.168.10.5/24 # vi /etc/hostname.aggr194001 192.168.10.25/24 |
Ce chapitre contient les informations de configuration du protocole IPv6 sur un réseau. Il aborde les principaux thèmes suivants :
Activation du protocole IPv6 sur une interface (liste des tâches)
Modification de la configuration d'interface IPv6 pour les hôtes et les serveurs
Modification de la configuration d'une interface IPv6 (liste des tâches)
Tâches de configuration de tunnels pour la prise en charge d'IPv6 (liste des tâches)
Configuration de prise en charge de services d'attribution de noms pour IPv6
Pour une présentation des concepts IPv6, reportez-vous au Chapitre 3Présentation d'IPv6. Pour obtenir le détail des tâches de planification IPv6, reportez-vous au Chapitre 4Planification d'un réseau IPv6 (tâches). Pour consulter des informations plus détaillées sur les tâches abordées dans ce chapitre, reportez-vous au Chapitre 11Présentation détaillée de IPv6 (référence).
La première étape du processus de configuration IPv6 consiste à activer le protocole sur une interface. Vous pouvez activer la prise en charge du protocole IPv6 lors de l'installation de Oracle Solaris 10 ou de la configuration du protocole sur les interfaces d'un système installé.
Lors de l'installation de Oracle Solaris 10, vous pouvez activer le protocole IPv6 sur une ou plusieurs interfaces d'un système. Une fois l'installation terminée, les fichiers et les tables IPv6 suivants sont définis :
Chacune des interfaces sur lesquelles le protocole IPv6 a été activé est associée à un fichier /etc/hostname6.interface (par exemple, hostname6.dmfe0).
Sur Solaris 10 11/06 et les versions précédentes, le fichier /etc/inet/ipnodes est créé. Une fois l'installation terminée, ce fichier contient en principe uniquement les adresses loopback IPv6 et IPv4.
Le fichier /etc/nsswitch.conf est modifié de manière à autoriser les recherches à l'aide des adresses IPv6.
La table des règles de sélection des adresses IPv6 est créée. Cette table définit l'ordre de priorité des formats d'adresse IP à utiliser pour la transmission des données sur une interface IPv6.
Cette section décrit la procédure d'activation du protocole IPv6 sur les interfaces d'un système installé.
Le tableau suivant répertorie les différentes tâches de configuration des interfaces IPv6. Le tableau comprend la description des actions de chaque tâche et la section de la documentation actuelle dans laquelle les étapes permettant d'effectuer ces tâches sont décrites en détails.
Tâche |
Description |
Voir |
---|---|---|
Activation du protocole IPv6 sur une interface d'un système sur lequel Oracle Solaris 10 est déjà installé. |
Cette tâche permet d'activer le protocole IPv6 sur une interface après l'installation de Oracle Solaris 10. | |
Définition d'une interface IPv6 persistante après les réinitialisations. |
Cette tâche permet de conserver l'adresse IPv6 de l'interface. | |
Désactivation de la configuration automatique de l'adresse IPv6. |
Cette tâche permet de configurer manuellement l'ID d'interface de l'adresse IPv6. |
Procédure de désactivation de la configuration automatique des adresses IPv6 |
La première étape du processus de configuration IPv6 consiste à activer le protocole sur les interfaces des systèmes à définir en tant que nœuds IPv6. En principe, l'adresse IPv6 de l'interface est définie via le processus de configuration automatique décrit à la section Configuration automatique d'adresse IPv6. Vous pouvez alors personnaliser la configuration du nœud selon sa fonction au sein du réseau IPv6 (hôte, serveur ou routeur).
Si l'interface est définie sur un lien sur lequel un routeur publie un préfixe IPv6, ce préfixe de site figure dans les adresses configurées automatiquement. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'un routeur compatible IPv6.
La procédure suivante explique comment activer le protocole IPv6 sur une interface ajoutée après l'installation de Oracle Solaris 10.
Effectuez les différentes procédures de planification du réseau IPv6 (mise à jour des composants matériels et logiciels, préparation du plan d'adressage, etc.). Pour plus d'informations, reportez-vous à la section Planification IPv6 (liste des tâches).
Connectez-vous au futur nœud IPv6 en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Activez le protocole IPv6 sur une interface.
# ifconfig inet6 interface plumb up |
Démarrez le démon IPv6 in.ndpd.
# /usr/lib/inet/in.ndpd |
Pour afficher l'état des interfaces IPv6 d'un nœud, exécutez la commande ifconfig-a6.
Cet exemple illustre l'activation du protocole IPv6 sur l'interface qfe0. Avant de commencer, vérifiez l'état de toutes les interfaces configurées sur le système.
# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 qfe0: flags=1000863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.16.27.74 netmask ffffff00 broadcast 172.16.27.255 ether 0:3:ba:13:14:e1 |
L'interface qfe0 est la seule interface actuellement configurée sur le système. Pour activer le protocole IPv6 sur cette interface, effectuez la procédure suivante :
# ifconfig inet6 qfe0 plumb up # /usr/lib/inet/in.ndpd # ifconfig -a6 lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 0:3:ba:13:14:e1 inet6 fe80::203:baff:fe13:14e1/10 |
Cet exemple illustre l'état de l'interface du système avant et après l'activation du protocole IPv6 sur qfe0. L'option -a6 de la commande ifconfig affiche uniquement les informations IPv6 de qfe0 ainsi que l'interface de loopback. La sortie indique que seule l'adresse lien-local fe80::203:baff:fe13:14e1/10 est configurée pour qfe0. Cette adresse signale que pour l'instant, aucun routeur ne publie de préfixe de site sur la liaison locale du nœud.
Une fois le protocole IPv6 activé, vous pouvez afficher les adresses IPv4 et IPv6 de toutes les interfaces d'un système à l'aide de la commande ifconfig - a.
Pour configurer le nœud IPv6 en tant que routeur, reportez-vous à la section Configuration d'un routeur IPv6.
Pour conserver la configuration de l'interface IPv6 après la réinitialisation du système, reportez-vous à la section Activation d'interfaces IPv6 persistantes.
Pour désactiver la configuration automatique sur le nœud, reportez-vous à la section Procédure de désactivation de la configuration automatique des adresses IPv6.
Pour personnaliser un nœud et le définir en tant que serveur, reportez-vous aux suggestions de la section Administration d'interfaces compatibles IPv6 sur des serveurs.
Cette section décrit la procédure d'activation d'interfaces IPv6 persistantes après la réinitialisation du système avec configuration automatique des adresses IPv6.
Si l'interface est définie sur un lien sur lequel un routeur publie un préfixe IPv6, ce préfixe de site figure dans les adresses configurées automatiquement. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'un routeur compatible IPv6.
Connectez-vous au nœud IPv6 en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Créez des adresses IPv6 pour les interfaces ajoutées après l'installation.
Créer une route IPv6 statique par défaut.
# /usr/sbin/route -p add -inet6 default ipv6-address |
(Facultatif) Créez un fichier /etc/inet/ndpd.conf définissant les paramètres des variables d'interface du nœud.
Si vous devez créer des adresses temporaires pour l'interface de l'hôte, reportez-vous à la section Utilisation d'adresses temporaires pour une interface. Pour de plus amples informations sur /etc/inet/ndpd.conf, reportez-vous à la page de manuel ndpd.conf(4), ainsi qu'à la section Fichier de configuration ndpd.conf.
Réinitialisez le nœud.
# reboot -- -r |
Le processus de réinitialisation envoie des paquets de découverte de routeur. Si un routeur répond avec un préfixe de site, le nœud peut configurer n'importe quelle interface associée à un fichier /etc/hostname6.interface avec une adresse IPv6 globale. Dans le cas contraire, les interfaces IPv6 sont configurées uniquement avec des adresses lien-local. La réinitialisation entraîne le redémarrage de in.ndpd et des autres démons réseau en mode IPv6.
Cet exemple illustre la procédure de conservation de la configuration IPv6 de l'interface qfe0 après réinitialisation. Dans cet exemple, un routeur situé sur la liaison locale publie le préfixe de site et l'ID de sous-réseau 2001:db8:3c4d:15/64.
Commencez par vérifier l'état des interfaces du système.
# ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 qfe0: flags=1000863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.16.27.74 netmask ffffff00 broadcast 172.16.27.255 ether 0:3:ba:13:14:e1 |
# touch /etc/hostname6.qfe0 # vi /etc/hostname6.qfe0 inet6 fe80::203:baff:fe13:1431/10 up addif inet6 2001:db8:3c4d:15:203:baff:fe13:14e1/64 up # route -p add -inet6 default fe80::203:baff:fe13:1431 # reboot -- -r |
Assurez-vous que l'adresse IPv6 configurée est toujours appliquée à l'interface qfe0.
# ifconfig -a6 qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 0:3:ba:13:14:e1 inet6 fe80::203:baff:fe13:14e1/10 qfe0:1: flags=2180841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2 inet6 2001:db8:3c4d:15:203:baff:fe13:14e1/64 |
La sortie de ifconfig -a6 indique deux entrées pour qfe0. L'entrée standard qfe0 inclut l'adresse MAC et l'adresse lien-local. Une seconde entrée, qfe0:1, indique la création d'une pseudo-interface pour l'adresse IPv6 supplémentaire de l'interface qfe0. La nouvelle adresse IPv6 globale 2001:db8:3c4d:15:203:baff:fe13:14e1/64 inclut le préfixe de site et l'ID de sous-réseau publiés par le routeur local.
Pour configurer le nouveau nœud IPv6 en tant que routeur, reportez-vous à la section Configuration d'un routeur IPv6.
Pour désactiver la configuration automatique sur le nœud, reportez-vous à la section Procédure de désactivation de la configuration automatique des adresses IPv6.
Pour personnaliser le nouveau nœud et le définir en tant que serveur, reportez-vous aux suggestions de la section Administration d'interfaces compatibles IPv6 sur des serveurs.
En règle générale, la configuration automatique d'adresse permet de générer les adresses IPv6 pour les interfaces des hôtes et des serveurs. Cependant, la désactivation de la configuration automatique peut s'avérer nécessaire, en particulier pour configurer un jeton manuellement, suivant les explications de la section Configuration d'un jeton IPv6.
Connectez-vous au nœud IPv6 en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Créez un fichier /etc/inet/ndpd.conf pour le nœud.
Le fichier /etc/inet/ndpd.conf définit les variables d'interface pour le nœud. Pour désactiver la configuration automatique de la totalité des interfaces du serveur, le fichier doit contenir les éléments suivants :
if-variable-name StatelessAddrConf false |
Pour de plus amples informations sur /etc/inet/ndpd.conf, reportez-vous à la page de manuel ndpd.conf(4), ainsi qu'à la section Fichier de configuration ndpd.conf.
Mettez le démon IPv6 à jour avec vos modifications.
# pkill -HUP in.ndpd |
La première étape de configuration d'IPv6 sur un réseau consiste à configurer IPv6 sur un routeur. La configuration de routeur implique d'effectuer un certain nombre de tâches distinctes, lesquelles sont décrites dans cette section. Vous pouvez effectuer une partie ou la totalité de ces tâches, en fonction des exigences de votre site.
Effectuez les tâches suivantes selon leur ordre d'affichage dans le tableau suivant pour configurer le réseau IPv6. Le tableau comprend la description des actions de chaque tâche et la section de la documentation actuelle dans laquelle les étapes permettant d'effectuer ces tâches sont décrites en détails.
Tâche |
Description |
Voir |
---|---|---|
1. Assurez-vous de bien remplir les conditions préalables avant de commencer la configuration d'IPv6. |
Vous devez terminer la planification des tâches et l'installation de Oracle Solaris avec des interfaces compatibles avec le protocole IPv6 avant de configurer un routeur compatible avec le protocole IPv6. |
Chapitre 4Planification d'un réseau IPv6 (tâches) et Configuration d'une interface IPv6. |
2. Configurez un routeur. |
Définissez le préfixe de site pour le réseau. | |
3. Configurez les interfaces de tunnel sur le routeur. |
Paramétrez un tunnel manuel ou une interface de tunnel 6to4 sur le routeur. Les tunnels sont nécessaires car ils permettent au réseau local IPv6 de communiquer avec d'autres réseaux IPv6 isolés. | |
4. Configurez les commutateurs sur le réseau. |
Si votre configuration réseau inclut des commutateurs, configurez-les pour IPv6 à ce stade du processus de configuration. |
Reportez-vous à la documentation du fabricant du commutateur. |
5. Configurez tout hub présent sur votre réseau. |
Si votre configuration réseau inclut des hubs, configurez-les pour IPv6 à ce stade du processus de configuration. |
Reportez-vous à la documentation du fabricant du commutateur. |
6. Configurez le service de noms de réseau pour IPv6. |
Configurez votre service de noms principal (DNS, NIS ou LDAP) afin de reconnaître les adresses IPv6 après la configuration du routeur pour IPv6. | |
7. (Facultatif) Modifiez les adresses pour les interfaces compatibles IPv6 sur les hôtes et les serveurs. |
Une fois la configuration du routeur IPv6, effectuez des modifications supplémentaires sur les hôtes et les serveurs compatibles IPv6. |
Modification de la configuration d'interface IPv6 pour les hôtes et les serveurs |
Configurez les applications pour la prise en charge d'IPv6. |
Différentes applications peuvent requérir différentes actions afin de prendre en charge IPv6. |
Reportez-vous à la documentation des applications. |
Cette procédure suppose que toutes les interfaces du routeur ont été configurées en fonction du protocole IPv6 lors de l'installation de Oracle Solaris.
Sur le système destiné à devenir le routeur IPv6, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Répertoriez les interfaces du routeur qui ont été configurées pour IPv6 lors de l'installation.
# ifconfig -a |
Vérifiez la sortie afin de vous assurer que les interfaces que vous souhaitiez configurer pour IPv6 sont bien montées avec des adresses lien-local. L'exemple de sortie de la commande ifconfig -a indique les adresses IPv4 et IPv6 configurées pour les interfaces du routeur.
lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 dmfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.16.26.232 netmask ffffff00 broadcast 172.16.26.255 ether 0:3:ba:11:b1:15 dmfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 3 inet 172.16.26.220 netmask ffffff00 broadcast 172.16.26.255 ether 0:3:ba:11:b1:16 lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 dmfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 0:3:ba:11:b1:15 inet6 fe80::203:baff:fe11:b115/10 dmfe1: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 3 ether 0:3:ba:11:b1:16 inet6 fe80::203:baff:fe11:b116/10 |
La sortie indique également que l'interface réseau principale dmfe0 et l'interface supplémentaire dmfe1 ont été configurée lors de l'installation avec les adresses IPv6 lien-local fe80::203:baff:fe11:b115/10 et fe80::203:baff:fe11:b116/10.
Configurez le transfert de paquets IPv6 sur toutes les interfaces du routeur.
Pour Solaris 10 11/03 et versions antérieures, utilisez la commande suivante :
# routeadm -e ipv6-forwarding -u |
Utilisez l'un des éléments suivants pour activer le transfert de paquets :
Utilisez la commande routeadm comme suit :
# routeadm -e ipv6-forwarding -u |
Utilisez la commande SMF (Service Management Facility, utilitaire de gestion des services) suivante, comme suit :
# svcadm enable ipv6-forwarding |
Le démon in.ripngd gère le routage IPv6.
Dans le cas de Solaris 10 11/06 et des versions antérieures, lancez in.ripngd en saisissant la commande suivante :
# routeadm -e ipv6-routing # routeadm -u |
Activez le routage IPv6 à l'aide de l'une des méthodes suivantes :
Utilisez la commande routeadm comme suit :
# routeadm -e ipv6-routing -u |
Utilisez SMF pour activer le routage IPv6 :
# svcadm enable ripng:default |
Pour obtenir des informations sur la syntaxe de la commande routeadm, reportez-vous à la page de manuel routeadm(1M).
Créez le fichier /etc/inet/ndpd.conf.
Spécifiez le préfixe de site que doit publier le routeur et les autres informations de configuration dans /etc/inet/ndpd.conf. Ce fichier est lu par le démon in.ndpd, qui implémente le protocole de détection de voisins IPv6.
Pour obtenir une liste des variables et des valeurs autorisables, reportez-vous à la section Fichier de configuration ndpd.conf et à la page de manuel ndpd.conf(4).
Saisissez le texte suivant dans le fichier /etc/inet/ndpd.conf :
ifdefault AdvSendAdvertisements true prefixdefault AdvOnLinkFlag on AdvAutonomousFlag on |
Ce texte indique au démon in.ndpd qu'il doit envoyer les publications de routeur à toutes les interfaces du routeur qui sont configurées pour IPv6.
Ajoutez du texte supplémentaire au fichier /etc/inet/ndpd.conf pour configurer le préfixe de site sur les différentes interfaces du routeur.
Le texte doit posséder le format suivant :
prefix global-routing-prefix:subnet ID/64 interface |
Le fichier d'exemple /etc/inet/ndpd.conf suivant configure le routeur de sorte qu'il publie le préfixe de site 2001:0db8:3c4d::/48 sur les interfaces dmfe0 et dmfe1.
ifdefault AdvSendAdvertisements true prefixdefault AdvOnLinkFlag on AdvAutonomousFlag on if dmfe0 AdvSendAdvertisements 1 prefix 2001:0db8:3c4d:15::0/64 dmfe0 if dmfe1 AdvSendAdvertisements 1 prefix 2001:0db8:3c4d:16::0/64 dmfe1 |
Redémarrez le système.
Le routeur IPv6 commence la publication sur la liaison locale de tout préfixe de site dans le fichier ndpd.conf.
L'exemple suivant illustre la sortie de la commande ifconfig - a telle que vous la recevriez une fois la procédure Configuration d'un routeur IPv6 terminée.
lo0: flags=1000849 <UP LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 dmfe0: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.16.15.232 netmask ffffff00 broadcast 172.16.26.255 ether 0:3:ba:11:b1:15 dmfe1: flags=1000843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4 mtu 1500 index 3 inet 172.16.16.220 netmask ffffff00 broadcast 172.16.26.255 ether 0:3:ba:11:b1:16 lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 dmfe0: flags=2100841 <UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 2 ether 0:3:ba:11:b1:15 inet6 fe80::203:baff:fe11:b115/10 dmfe0:1: flags=2180841 <UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 2 inet6 2001:db8:3c4d:15:203:baff:fe11:b115/64 dmfe1: flags=2100841 <UP,RUNNING,MULTICAST,ROUTER,IPv6> mtu 1500 index 3 ether 0:3:ba:11:b1:16 inet6 fe80::203:baff:fe11:b116/10 dmfe1:1: flags=2180841 <UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 3 inet6 2001:db8:3c4d:16:203:baff:fe11:b116/64 |
Dans cet exemple, chaque interface configurée pour IPv6 possède maintenant deux adresses. L'entrée avec le nom de l'interface, comme dmfe0, indique l'adresse lien-local de l'interface. L'entrée avec le format interface:n, tel que dmfe0:1, indique une adresse globale IPv6. Cette adresse inclut le préfixe de site que vous avez configuré dans le fichier /etc/ndpd.conf, en plus de l'ID d'interface.
Pour configurer des tunnels à partir des routeurs identifiés dans la topologie de réseau IPv6, reportez-vous à la section Configuration de tunnels pour la prise en charge d'IPv6.
Pour obtenir des informations sur la configuration de commutateurs et de hubs sur votre réseau, reportez-vous à la documentation du fabricant.
Pour configurer les hôtes IPv6, reportez-vous à la section Modification de la configuration d'interface IPv6 pour les hôtes et les serveurs.
Pour améliorer la prise en charge d'IPv6 sur les serveurs, reportez-vous à la section Administration d'interfaces compatibles IPv6 sur des serveurs.
Pour plus d'informations sur les commandes, fichiers et démons IPv6, reportez-vous à la section Implémentation du protocole IPv6 sous Oracle Solaris 10.
Cette section explique comment modifier la configuration d'interfaces compatibles IPv6 sur les nœuds qui sont des hôtes ou des serveurs. Dans la plupart des cas, il est conseillé d'utiliser la configuration automatique d'interfaces compatibles IPv6, comme expliqué dans la section Présentation de la configuration automatique sans état. Vous pouvez cependant, le cas échéant, modifier l'adresse IPv6 d'une interface comme expliqué dans les tâches décrites dans cette section.
Le tableau suivant répertorie les différentes tâches permettant de modifier un réseau IPv6. Le tableau comprend la description des actions de chaque tâche et la section de la documentation actuelle dans laquelle les étapes permettant d'effectuer ces tâches sont décrites en détails.
Tâche |
Description |
Voir |
---|---|---|
Désactivation de la configuration automatique de l'adresse IPv6. |
Cette tâche permet de configurer manuellement l'ID d'interface de l'adresse IPv6. |
Procédure de désactivation de la configuration automatique des adresses IPv6 |
Créez une adresse temporaire pour un hôte. |
Masquez l'ID d'interface de l'hôte en configurant une adresse temporaire créée de façon aléatoire, utilisée comme les 64 bits inférieurs de l'adresse. | |
Configurez un jeton pour l'ID d'interface d'un système. |
Créez un jeton de 64 bits à utiliser en tant qu'ID d'interface dans une adresse IPv6. |
Procédure de configuration d'un jeton IPv6 spécifié par l'utilisateur |
Une adresse temporaire IPv6 contient un numéro de 64 bits généré de manière aléatoire en tant qu'ID d'interface, plutôt que l'adresse MAC d'une interface. Vous pouvez utiliser des adresses temporaires pour toute interface d'un nœud IPv6 dont vous souhaitez préserver l'anonymat. Par exemple, il peut s'avérer utile d'employer des adresses temporaires pour les interfaces d'un hôte devant accéder à des serveurs Web publics. Les adresses temporaires implémentent des améliorations de confidentialité pour IPv6. Ces améliorations sont décrites dans le document RFC 3041, disponible à l'adresse “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”.
L'activation d'une adresse temporaire s'effectue dans le fichier /etc/inet/ndpd.conf, pour une ou plusieurs interfaces, le cas échéant. Cependant, à la différence des adresses IPv6 standard configurées automatiquement, une adresse temporaire se compose d'un préfixe de sous-réseau de 64 bits et d'un numéro de 64 bits généré de façon aléatoire. Ce numéro devient le segment correspondant à l'ID d'interface de l'adresse IPv6. Une adresse lien-local n'est pas générée avec l'adresse temporaire en tant qu'ID d'interface.
Notez que la durée de vie préférée par défaut des adresses temporaires est d'un jour. Lors de l'activation de la génération d'adresses temporaires, il est également possible de configurer les variables suivantes dans le fichier /etc/inet/ndpd.conf :
Durée d'existence de l'adresse temporaire ; une fois la durée écoulée, l'adresse est supprimée de l'hôte.
Temps écoulé avant que l'adresse temporaire soit désapprouvée. Cette durée doit être inférieure à la durée de vie valide.
Durée avant l'expiration de la durée de vie préférée, pendant laquelle l'hôte devrait générer une nouvelle adresse temporaire.
La durée des adresses temporaires s'exprime comme suit :
n nombre de secondes, valeur par défaut
n nombre d'heures (h)
n nombre de jours (d)
Connectez-vous à l'hôte IPv6 en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Si nécessaire, activez IPv6 sur les interfaces de l'hôte.
Reportez-vous à la section Activation d'une interface IPv6 pour la session actuelle.
Modifiez le fichier /etc/inet/ndpd.conf afin d'activer la génération d'adresses temporaires.
Pour configurer des adresses temporaires sur les interfaces d'un hôte, ajoutez la ligne suivante au fichier /etc/inet/ndpd.conf :
ifdefault TmpAddrsEnabled true |
Pour configurer une adresse temporaire pour une interface spécifique, ajoutez la ligne suivante au fichier /etc/inet/ndpd.conf :
if interface TmpAddrsEnabled true |
(Facultatif) Spécifiez la durée de vie valide de l'adresse temporaire.
ifdefault TmpValidLifetime duration |
Cette syntaxe spécifie la durée de vie valide de toutes les interfaces d'un hôte. La durée s'exprime en secondes, en heures ou en jours. La durée de vie valide par défaut est de 7 jours. Vous pouvez également utiliser TmpValidLifetime avec des mots-clés d'interface if afin de spécifier la durée de vie valide de l'adresse temporaire d'une interface en particulier.
(Facultatif) Spécifiez une durée de vie préférée pour l'adresse temporaire après laquelle celle-ci est désapprouvée.
if interface TmpPreferredLifetime duration |
Cette syntaxe spécifie la durée de vie préférée de l'adresse temporaire d'une interface donnée. La durée de vie préférée par défaut est d'un jour. Vous pouvez également utiliser TmpPreferredLifetime avec le mot-clé ifdefault afin de spécifier la durée de vie préférée des adresses temporaires de toutes les interfaces d'un hôte.
La sélection d'adresse par défaut attribue une priorité moindre aux adresses IPv6 désapprouvées. Si une adresse temporaire IPv6 est désapprouvée, la sélection d'adresses par défaut choisit une adresse qui n'a pas été désapprouvées en tant qu'adresse source d'un paquet. Une adresse non désapprouvée peut être l'adresse IPv6 générée automatiquement ou, éventuellement, l'adresse IPv4 de l'interface. Pour de plus amples informations sur la sélection d'adresses par défaut, reportez-vous à la section Administration de la sélection des adresses par défaut.
(Facultatif) Spécifiez la durée de production en avance de la désapprobation d'adresse, pendant laquelle l'hôte devrait générer une nouvelle adresse temporaire.
ifdefault TmpRegenAdvance duration |
Cette syntaxe spécifie le délai qui doit s'écouler avant la désapprobation d'adresse pour les adresses temporaires de toutes les interfaces d'un hôte. La valeur par défaut est 5 secondes.
Modifiez la configuration du démon in.ndpd.
# pkill -HUP in.ndpd # /usr/lib/inet/in.ndpd |
Assurez-vous que les adresses temporaires ont été créées en exécutant la commande ifconfig -a6, tel que décrit dans l'Exemple 7–5.
La sortie de ifconfig doit comporter le mot TEMPORARY dans la même ligne que la définition d'interface.
L'exemple suivant comporte un segment d'un fichier /etc/inet/ndpd.conf avec les adresses temporaires activées pour l'interface du réseau principal.
ifdefault TmpAddrsEnabled true ifdefault TmpValidLifetime 14d ifdefault TmpPreferredLifetime 7d ifdefault TmpRegenAdvance 6s |
Cet exemple indique la sortie de la commande ifconfig une fois les adresses temporaires créées.
# ifconfig -a6 lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 hme0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 8:0:20:b9:4c:54 inet6 fe80::a00:20ff:feb9:4c54/10 hme0:1: flags=2080841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2 inet6 2001:db8:3c4d:15:a00:20ff:feb9:4c54/64 hme0:2: flags=802080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,TEMPORARY> mtu 1500 index 2 inet6 2001:db8:3c4d:15:7c37:e7d1:fc9c:d2cb/64 |
Notez que la ligne suivant l'interface hme0:2 comprend le mot TEMPORARY. Cette désignation indique que l'adresse 2001:db8:3c4d:15:7c37:e7d1:fc9c:d2cb/64 possède un ID d'interface temporaire.
Pour définir la prise en charge du service d'attribution de noms pour les adresses IPv6, reportez-vous à la section Configuration de prise en charge de services d'attribution de noms pour IPv6.
Pour configurer des adresses IPv6 pour un serveur, reportez-vous à la section Procédure de configuration d'un jeton IPv6 spécifié par l'utilisateur.
Pour contrôler les activités sur les nœuds IPv6, reportez-vous au Chapitre 8Gestion d'un réseau TCP/IP (tâches).
L'ID d'interface 64 bits d'une adresse IPv6 est également nommé jeton, tel que décrit dans la section Présentation de l'adressage IPv6. Lors de la configuration automatique d'adresses, le jeton est associé à l'adresse MAC de l'interface. Dans la plupart des cas, les nœuds qui n'effectuent pas de routage, c'est-à-dire les hôtes et les serveurs IPv6, doivent utiliser leurs jetons configurés automatiquement.
Cependant, l'utilisation de jetons configurés automatiquement peut être problématique pour les serveurs dont les interfaces sont régulièrement dans le cadre de la maintenance système. Lorsque la carte de l'interface est modifiée, l'adresse MAC l'est également. Cela peut entraîner des problèmes pour les serveurs qui dépendent d'adresses IP. Différentes parties de l'infrastructure de réseau, comme le DNS ou le NIS, peuvent disposer d'adresses IPv6 stockées pour les interfaces du serveur.
Pour les problèmes liés aux modifications d'adresses, vous pouvez configurer un jeton manuellement pour l'utiliser en tant qu'ID d'interface dans une adresse IPv6. Pour créer le jeton, spécifiez un numéro hexadécimal de 64 bits maximum afin d'occuper la portion d'ID d'interface de l'adresse IPv6. Par la suite, lors de la configuration automatique d'adresses, le protocole de détection de voisins ne crée pas d'ID d'interface basé sur l'adresse MAC de l'interface. Le jeton créé manuellement devient l'ID d'interface. Ce jeton reste assigné à l'interface, même en cas de remplacement d'une carte.
La différence entre les jetons spécifiés par les utilisateurs et les adresses temporaires réside dans le fait que ces dernières sont générées de façon aléatoire et non pas créées explicitement par un utilisateur.
Les instructions suivantes sont particulièrement utiles pour les serveurs dont les interfaces sont régulièrement remplacées. Elles sont également valides pour la configuration de jetons spécifiés par l'utilisateur sur tout nœud IPv6.
Assurez-vous que l'interface à configurer avec un jeton est montée.
Avant de configurer un jeton pour l'adresse IPv6 d'une interface, vous devez monter l'interface.
# ifconfig -a6 |
qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 0:3:ba:13:14:e1 inet6 fe80::203:baff:fe13:14e1/10 |
Cette sortie indique que l'interface réseau qfe0 est montée et dispose d'une adresse lien-local fe80::203:baff:fe13:14e1/10. Cette adresse a été configurée automatiquement lors de l'installation.
Créez un ou plusieurs numéros hexadécimaux de 64 bits à utiliser en tant que jetons pour l'interface du nœud. Pour des exemples de jetons, reportez-vous à la section Adresse unicast lien-local.
Configurez chaque interface avec un jeton.
Utilisez le format suivant de la commande ifconfig pour chaque interface afin de disposer d'un ID d'interface spécifiée par l'utilisateur (jeton) :
ifconfig interface inet6 token address/64 |
Par exemple, exécutez la commande suivante afin de configurer l'interface qfe0 avec un jeton :
# ifconfig qfe0 inet6 token ::1a:2b:3c:4d/64 |
Répétez cette étape pour chaque interface disposant d'un jeton spécifié par l'utilisateur.
(Facultatif) Configurez les adresses IPv6 de sorte qu'elles persistent après réinitialisation.
Modifiez ou créez un fichier /etc/hostname6.interface pour chaque interface configurée avec un jeton.
Ajoutez le texte suivant au bas du fichier /etc/hostname.6 interface :
token ::token-name/64 |
Par exemple, vous pouvez ajouter le texte suivant au bas du fichier /etc/hostname6.interface :
token ::1a:2b:3c:4d/64 |
Une fois le système réinitialisé, le jeton configuré dans le fichier /etc/hostname6. interface est appliqué à l'adresse IPv6 de l'interface. Cette adresse IPv6 persiste après réinitialisation.
Mettez le démon IPv6 à jour avec vos modifications.
# pkill -HUP -in.ndpd |
Dans l'exemple suivant, l'interface bge0:1 possède une adresse IPv6 configurée automatiquement. Le préfixe de sous-réseau 2001:db8:3c4d:152:/64 est publié par un routeur sur la liaison locale du nœud. L'ID d'interface 2c0:9fff:fe56:8255 est généré à partir de l'adresse MAC de bge0:1.
# ifconfig -a6 lo0: flags=2002000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1 inet6 ::1/128 bge0: flags=2100801 <UP,MULTICAST,IPv6> mtu 1500 index 5 inet6 fe80::2c0:9fff:fe56:8255/10 ether 0:c0:9f:56:82:55 bge0:1: flags=2180801 <UP, MULTICAST,ADDRCONF,IPv6>mtu 1500 index 5 inet6 2001:db8:3c4d:152:c0:9fff:fe56:8255/64 # ifconfig bge0 inet6 token ::1a:2b:3c:4d/64 # vi /etc/hostname6.bge0 token ::1a:2b:3c:4d/64 # pkill -HUP -in.ndpd # ifconfig -a6 lo0: flags=2002000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1 inet6 ::1/128 bge0: flags=2100801 <UP,MULTICAST,IPv6> mtu 1500 index 5 inet6 fe80::2c0:9fff:fe56:8255/10 ether 0:c0:9f:56:82:55 bge0:1: flags=2180801 <UP, MULTICAST,ADDRCONF,IPv6>mtu 1500 index 5 inet6 2001:db8:3c4d:152:1a:2b:3c:4d/64 |
Une fois le jeton configuré, l'adresse globale sur la seconde ligne d'état bge0:1 dispose alors de 1a:2b:3c:4d configuré pour son ID d'interface.
Pour la mise à jour des services d'attribution de noms pour les adresses IPv6 du serveur, reportez-vous à la section Configuration de prise en charge de services d'attribution de noms pour IPv6.
Pour contrôler les performances de serveur, reportez-vous au Chapitre 8Gestion d'un réseau TCP/IP (tâches).
Lors de la planification d'IPv6 sur un serveur, vous devez prendre un certain nombre de décisions relatives à l'activation d'IPv6 sur les interfaces du serveur. Vos décisions affectent la stratégie à utiliser pour la configuration des ID d'interface, également appelés jetons, de l'adresse IPv6 d'une interface.
Cette procédure suppose les conditions suivantes :
Oracle Solaris 10 est déjà installé sur le serveur.
Vous avez activé le protocole IPv6 sur les interfaces du serveur lors de l'installation de Oracle Solaris ou par la suite, selon les procédures décrites dans la section Configuration d'une interface IPv6.
Le cas échéant, mettez le logiciel de l'application à niveau afin d'assurer la prise en charge d'IPv6. Notez que de nombreuses applications s'exécutant sur la pile de protocole IPv4 s'exécutent également sur IPv6. Pour de plus amples informations, reportez-vous à la section Procédure de préparation de services réseau pour la prise en charge d'IPv6.
Sur le serveur, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Assurez-vous qu'un préfixe de sous-réseau IPv6 est configuré sur un routeur situé sur la même liaison que le serveur.
Pour plus d'informations, reportez-vous à la section Configuration d'un routeur IPv6.
Utilisez la stratégie adéquate pour l'ID des interfaces compatibles IPv6 du serveur.
Par défaut, la configuration automatique d'adresses IPv6 utilise l'adresse MAC d'une interface lors de la création de la partie ID d'interface de l'adresse IPv6. Si l'adresse IPv6 de l'interface est bien connue, remplacer une interface par une autre peut entraîner des problèmes. L'adresse MAC de la nouvelle interface sera différente. Un nouvel ID d'interface est généré lors de la configuration automatique d'adresses.
Dans le cas d'une interface compatible IPv6 que vous ne souhaitez pas remplacer, utilisez l'adresse IPv6 configurée automatiquement, tel que présenté dans la section Configuration automatique d'adresse IPv6.
Dans le cas d'interfaces compatibles IPv6 devant apparaître anonymes hors du réseau local, vous pouvez utiliser un jeton généré de façon aléatoire comme ID d'interface. Pour obtenir des instructions et un exemple, reportez-vous à la section Procédure de configuration d'une adresse temporaire.
Dans le cas d'interfaces compatibles IPv6 que vous pensez échanger régulièrement, créez des jetons pour les ID d'interface. Pour obtenir des instructions et un exemple, reportez-vous à la section Procédure de configuration d'un jeton IPv6 spécifié par l'utilisateur.
Le tableau suivant répertorie les différentes tâches permettant de configurer différents types de tunnels IPv6. Le tableau comprend la description des actions de chaque tâche et la section de la documentation actuelle dans laquelle les étapes permettant d'effectuer ces tâches sont décrites en détails.
Tâche |
Description |
Voir |
---|---|---|
Configuration manuelle de tunnels IPv6 sur IPv4. |
Créez un tunnel IPv6 sur un réseau IPv4 manuellement. Cette solution permet d'atteindre des réseaux IPv6 distants au sein d'un réseau d'entreprise de plus grande taille, principalement IPv4. |
Procédure de configuration manuelle de tunnels IPv6 sur un réseau IPv4 |
Configuration manuelle de tunnels IPv6 sur IPv6. |
Configurez manuellement un tunnel IPv6 sur un réseau IPv6. Cette solution est généralement utilisée au sein d'un réseau d'entreprise de grande taille. |
Procédure de configuration manuelle de tunnels IPv6 sur un réseau IPv6 |
Configuration manuelle de tunnels IPv4 sur IPv6. |
Configurez manuellement un tunnel IPv4 sur un réseau IPv6. Cette solution est utile pour des réseaux de grande taille disposant de réseaux IPv4 et IPv6. |
Procédure de configuration de tunnels IPv4 sur un réseau IPv6 |
Configuration automatique de tunnels IPv6 sur IPv4 (tunnels 6to4). |
Créez un tunnel automatique 6to4. Cette solution permet d'atteindre un site IPv6 externe sur Internet. | |
Configuration d'un tunnel entre un routeur 6to4 et un routeur relais 6to4. |
Activez un tunnel pour un routeur relais 6to4 à l'aide de la commande 6to4relay. |
Procédure de configuration d'un tunnel 6to4 relié à un routeur relais 6to4 |
Les réseaux IPv6 sont souvent des entités isolées au sein d'un univers IPv4 de plus grande taille. Les nœuds situés sur votre réseau IPv6 peuvent avoir besoin de communiquer avec des nœuds situés sur des réseaux IPv6 isolés, soit au sein de votre entreprise, soit à distance. En règle générale, un tunnel se configure entre routeurs IPv6, mais les hôtes IPv6 peuvent également fonctionner en tant qu'extrémités de tunnels. Pour obtenir des informations relatives à la planification de tunnels, reportez-vous à la section Planification de tunnels dans la topologie réseau.
Vous pouvez définir des tunnels configurés automatiquement ou manuellement pour les réseaux IPv6. L'implémentation de Oracle Solaris IPv6 prend en charge les types d'encapsulation de tunnel suivants :
tunnels IPv6 sur IPv4 ;
tunnels IPv6 sur IPv6 ;
tunnels IPv4 sur IPv6 ;
tunnels 6to4.
Pour obtenir des descriptions conceptuelles de tunnels, reportez-vous à la section Tunnels IPv6.
Cette procédure permet de configurer un tunnel entre un noeud IPv6 et un noeud IPv6 distant faisant partie d'un réseau IPv4.
Connectez-vous au point d'extrémité local du tunnel en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Créez le fichier /etc/hostname6.ip.tun n.
Remplacez n par le numéro du tunnel (le premier tunnel possédant le numéro zéro). Ajoutez les entrées suivantes :
Ajoutez l'adresse source et l'adresse cible du tunnel.
tsrc IPv4-source-address tdst IPv4-destination-address up |
(Facultatif) Ajoutez une interface logique pour l'adresse source et l'adresse cible du tunnel IPv6.
addif IPv6-source-address IPv6-destination-address |
Ignorez cette étape si vous souhaitez que ces adresses soient configurées automatiquement. Il n'est pas nécessaire de configurer les adresses locales des liens pour le tunnel.
Redémarrez le système.
Répétez cette procédure sur l'autre point d'extrémité du tunnel.
L'exemple de fichier /etc/hostname6.ip.tun suivant est celui d'un tunnel dont les adresses source et cible globales ont été configurées manuellement.
tsrc 192.168.8.20 tdst 192.168.7.19 up addif 2001:db8:3c4d:8::fe12:528 2001:db8:3c4d:7:a00:20ff:fe12:1234 up |
Cette procédure permet de configurer un tunnel entre un nœud IPv6 et un nœud IPv6 distant faisant partie d'un réseau IPv6.
Connectez-vous au point d'extrémité local du tunnel en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Créez le fichier /etc/hostname6.ip6.tunn.
Remplacez n par les valeurs 0, 1, 2, etc. Ajoutez les entrées suivantes :
Ajoutez l'adresse source et l'adresse cible du tunnel.
tsrc IPv6-source-address tdst IPv6-destination-address IPv6-packet-source-address IPv6-packet-destination-address up |
(Facultatif) Ajoutez une interface logique pour l'adresse source et l'adresse cible du tunnel IPv6.
addif IPv6-source-address IPv6-destination-address up |
Ignorez cette étape si vous souhaitez que ces adresses soient configurées automatiquement. Il n'est pas nécessaire de configurer les adresses locales des liens pour le tunnel.
Redémarrez le système.
Répétez cette procédure sur l'autre point d'extrémité du tunnel.
Cet exemple décrit la commande à saisir pour configurer un tunnel IPv6 sur un réseau IPv6.
tsrc 2001:db8:3c4d:22:20ff:0:fe72:668c tdst 2001:db8:3c4d:103:a00:20ff:fe9b:a1c3 fe80::4 fe80::61 up |
Cette procédure permet de configurer un tunnel entre deux hôtes IPv4 sur un réseau IPv6. Elle s'applique aux réseaux hétérogènes possédant des sous-réseaux IPv4 séparant des sous-réseaux IPv6.
Connectez-vous au point d'extrémité local du tunnel IPv4 en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Créez le fichier /etc/hostname.ip6.tunn.
Remplacez n par les valeurs 0, 1, 2, etc. Ajoutez les entrées suivantes :
Redémarrez l'hôte local.
Répétez cette procédure sur l'autre point d'extrémité du tunnel.
Cet exemple décrit la commande à saisir pour configurer un tunnel IPv4 sur un réseau IPv6.
tsrc 2001:db8:3c4d:114:a00:20ff:fe72:668c tdst 2001:db8:3c4d:103:a00:20ff:fe9b:a1c3 10.0.0.4 10.0.0.61 up |
Si un réseau IPv6 doit communiquer avec un réseau IPv6 distant, il est recommandé de configurer des tunnels 6to4 automatiques. Le processus de configuration d'un tunnel 6to4 inclut la définition du routeur de bordure en tant que routeur 6to4. Ce routeur joue le rôle de point d'extrémité du tunnel 6to4 entre le réseau local et le point d'extrémité du réseau IPv6 distant.
Avant de configurer le routage 6to4 sur un réseau IPv6, effectuez les opérations suivantes :
Configurez le réseau IPv6 sur tous les noeuds adéquats du site 6to4 concerné, comme décrit à la section Modification de la configuration d'interface IPv6 pour les hôtes et les serveurs.
Sélectionnez au moins un routeur avec une connexion sur un réseau IPv4 et définissez-le en tant que routeur 6to4.
Configurez une adresse IPv4 unique pour la future interface du routeur 6to4 sur le réseau IPv4. L'adresse IPv4 doit être statique.
N'utilisez pas les adresses IPv4 allouées de façon dynamique, comme expliqué dans le Chapitre 12Service DHCP Oracle Solaris (présentation). Les adresses dynamiques varient, ce qui peut entraver la planification d'adresses IPv6.
Connectez-vous sur le routeur 6to4 en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Configurez une pseudointerface 6to4 sur le routeur en créant un fichier nommé /etc/hostname6.ip.6to4tun0.
Si vous envisagez d'utiliser la convention recommandée (ID de sous-réseau=0 et ID d'hôte=1), choisissez le format court (short) pour le fichier /etc/hostname6.ip.6to4tun0 :
tsrc IPv4-address up |
Si vous envisagez d'utiliser une autre convention pour les ID hôte et sous-réseau, choisissez le format long pour le fichier /etc/hostname6.ip.6to4tun0 :
tsrc IPv4-address 2002:IPv4-address:subnet-ID:interface-ID:/64 up |
Les paramètres suivants sont requis pour le fichier /etc/hostname6.ip.6to4tun0 :
Indique que cette interface est utilisée en tant que source du tunnel.
Spécifie (au format décimal avec points) l'adresse IPv4 configurée sur l'interface physique devant servir de pseudointerface 6to4.
Les autres paramètres sont facultatifs. Cependant, si vous décidez d'en spécifier certains, vous devrez tous les spécifier.
Spécifie le préfixe 6to4.
Spécifie (au format hexadécimal) l'adresse IPv4 de la pseudointerface.
Spécifie (au format hexadécimal) un sous-réseau différent de zéro.
Spécifie un ID d'interface différent de 1.
Indique que le préfixe 6to4 possède une longueur de 64 bits.
Définit l'interface 6to4 sur "up".
Les deux tunnels IPv6 du réseau doivent posséder une adresse source et une adresse cible unique. Des paquets sont déposés en conséquence. Ce type d'événement peut se produire si un routeur 6to4 crée également des tunnels par le biais de la commande atun. Pour plus d'informations sur la commande atun, reportez-vous à la page de manuel tun(7M).
(Facultatif) Créez des pseudointerfaces 6to4 supplémentaires sur le routeur.
Chacune d'entre elles doit posséder une adresse IPv4 déjà configurée et unique.
Redémarrez le routeur 6to4.
Vérifiez le statut de l'interface.
# ifconfig ip.6to4tun0 inet6 |
Si l'interface est correctement configurée, une sortie similaire à celle-ci s'affiche :
ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11 inet tunnel src 111.222.33.44 tunnel hop limit 60 inet6 2002:6fde:212c:10:/64 |
Pour publier le routage 6to4, modifiez le fichier /etc/inet/ndpd.conf.
Pour plus d'informations, reportez-vous à la page de manuel ndpd.conf(4).
Sur la première ligne, spécifiez le sous-réseau devant recevoir la publication.
Créez une entrée if au format suivant :
if subnet-interface AdvSendAdvertisements 1 |
Exemple : pour publier le routage 6to4 sur un sous-réseau connecté à l'interface hme0, remplacez interface sous-réseau par hme0.
if hme0 AdvSendAdvertisements 1 |
Sur la deuxième ligne du fichier de publication, ajoutez le préfixe 6to4.
Créez une entrée prefix au format suivant :
prefix 2002:IPv4-address:subnet-ID::/64 subnet-interface |
Redémarrez le routeur.
Vous pouvez également exécuter la commande sighup sur le démon de /etc/inet/in.ndpd pour commencer la publication du routeur. Les noeuds IPv6 de chaque sous-réseau devant recevoir le préfixe 6to4 sont alors automatiquement définis sur les nouvelles adresses 6to4 dérivées.
Ajoutez ces nouvelles adresses au service de noms utilisé par le site 6to4.
Vous trouverez les instructions correspondantes dans la section Configuration de prise en charge de services d'attribution de noms pour IPv6.
L'exemple suivant présente le fichier /etc/hostname6.ip.6to4tun0 dans sa forme courte :
# cat /etc/hostname6.ip.6to4tun0 tsrc 111.222.33.44 up |
Voici un exemple du fichier /etc/hostname6.ip.6to4tun0 dans sa forme longue :
# cat /etc/hostname6.ip.6to4tun0 tsrc 111.222.33.44 2002:6fde:212c:20:1/64 up |
L'exemple suivant présente la sortie de la commande ifconfig pour une pseudointerface 6to4 :
# ifconfig ip.6to4tun0 inet6 ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6> mtu 1480 index 11 inet tunnel src 192.168.87.188 tunnel hop limit 60 inet6 2002:c0a8:57bc::1/64 |
L'exemple de fichier /etc/inet/ndpd.conf suivant publie le routage 6to4 sur deux sous-réseaux :
if qfe0 AdvSendAdvertisements 1 prefix 2002:c0a8:57bc:10::/64 qfe0 if qfe1 AdvSendAdvertisements 1 prefix 2002:c0a8:57bc:2::/64 qfe1 |
Si le site dispose de plusieurs routeurs, ceux qui se trouvent derrière le routeur 6to4 doivent pouvoir prendre en charge le routage 6to4. Si ce n'est pas le cas, configurez-les. Si le site utilise RIP, configurez la route statique du routeur 6to4 sur les autres routeurs. S'il utilise un protocole de routage commercial, il n'est pas nécessaire de créer de route statique vers le routeur 6to4.
Pour des raisons de sécurité, la prise en charge des routeurs relais 6to4 est désactivée par défaut dans Oracle Solaris. Voir Problèmes de sécurité lors de la création d'un tunnel vers un routeur relais 6to4.
Avant de configurer un tunnel relié à un routeur relais 6to4, vous devez avoir effectué les tâches suivantes :
configuration d'un routeur 6to4 sur site, comme expliqué à la section Procédure de configuration d'un tunnel 6to4 ;
vérification des problèmes de sécurité susceptibles de se produire avec un tunnel relié à un routeur relais 6to4.
Connectez-vous sur le routeur 6to4 en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Vous pouvez relier un tunnel à un routeur relais 6to4 de deux façons :
Liaison a un routeur relais 6to4 de type anycast.
# /usr/sbin/6to4relay -e |
L'option -e configure un tunnel entre le routeur 6to4 et un routeur relais 6to4 anycast. Les routeurs relais 6to4 anycast possèdent l'adresse IPv4 courante 192.88.99.1. Le routeur relais anycast le plus proche (physiquement) de votre site devient le point d'extrémité du tunnel 6to4. Ce routeur relais gère ensuite l'envoi des paquets entre votre site 6to4 et un site IPv6 natif.
Pour de plus amples informations sur les routeurs relais 6to4 Anycast, reportez-vous à la page RFC 3068, "An Anycast Prefix for 6to4 Relay Routers".
Liaison a un routeur relais 6to4 de type spécifique.
# /usr/sbin/6to4relay -e -a relay-router-address |
L'option -a est toujours suivie d'une adresse de routeur spécifique. Remplacez adresse routeur relais par l'adresse IPv4 du routeur relais 6to4 spécifique que vous souhaitez relier au tunnel.
Le tunnel relié au routeur relais 6to4 reste actif pendant la suppression de la pseudointerface du tunnel 6to4.
Supprimez le tunnel relié au routeur relais 6to4 lorsqu'il n'est plus nécessaire :
# /usr/sbin/6to4relay -d |
(Facultatif) Configurez un tunnel au routeur relais 6to4 qui conserve ses paramètres après chaque redémarrage.
Si votre site requiert, pour quelque raison qu'il soit, que les paramètres du tunnel relié au routeur relais 6to4 soient redéclarés à chaque redémarrage du routeur, effectuez la procédure suivante :
Modifiez le fichier/etc/default/inetinit.
La ligne à modifier se trouve à la fin du fichier.
Remplacez la valeur "NO" de la ligne ACCEPT6TO4RELAY=NO par "YES".
(Facultatif) Créez un tunnel relié à un routeur relais 6to4 spécifique dont les paramètres sont conservés après chaque redémarrage.
Pour le paramètre RELAY6TO4ADDR, remplacez l'adresse 192.88.99.1 par l'adresse IPv4 du routeur relais 6to4 à utiliser.
La commande /usr/bin/6to4relay vous permet de savoir si les routeurs relais 6to4 sont pris en charge ou non par votre site. L'exemple suivant présente la sortie obtenue lorsque les routeurs relais 6to4 ne sont pas pris en charge (sortie par défaut de Oracle Solaris) :
# /usr/sbin/6to4relay 6to4relay: 6to4 Relay Router communication support is disabled. |
Lorsque les routeurs relais 6to4 sont pris en charge, la sortie suivante s'affiche :
# /usr/sbin/6to4relay 6to4relay: 6to4 Relay Router communication support is enabled. IPv4 remote address of Relay Router=192.88.99.1 |
Cette section décrit la procédure de configuration des services d'attribution de noms DNS et NIS pour la prise en charge de services IPv6.
LDAP prend en charge IPv6 sans aucune configuration supplémentaire nécessaire.
Pour obtenir des informations détaillées sur l'administration DNS, NIS et LDAP, reportez-vous à la section System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .
Connectez-vous au serveur DNS principal ou secondaire en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Modifiez le fichier de zone DNS adéquat en ajoutant les enregistrements AAAA pour chaque nœud compatible IPv6 :
host-name IN AAAA host-address |
Modifiez les fichiers de zone inversée DNS et ajoutez des enregistrements PTR :
host-address IN PTR hostname |
Pour obtenir des informations détaillées sur l'administration de DNS, reportez-vous à la section System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .
Cet exemple représente une adresse IPv6 dans le fichier de zone inversée.
$ORIGIN ip6.int. 8.2.5.0.2.1.e.f.f.f.9.2.0.0.a.0.6.5.2.9.0.0.0.0.0.0.0.0.2.0.0.0 \ IN PTR vallejo.Eng.apex.COM. |
Dans Solaris 10 11/06 et les versions antérieures, deux cartes ont été ajoutées au service de noms NIS : ipnodes.byname et ipnodes.byaddr. Ces cartes contiennent des noms d'hôtes IPv4 et IPv6 ainsi que des associations d'adresses. Les outils compatibles IPv6 utilisent les cartes NIS ipnodes. Les cartes hosts.byname et hosts.byaddr ne contiennent que les noms d'hôtes IPv4 et des associations d'adresses. Ces cartes ne sont pas modifiées. Ainsi, elles peuvent être utilisées pour les applications existantes. L'administration des cartes ipnodes est similaire à celle des cartes hosts.byname et hosts.byaddr. Pour Solaris 10 11/06, lors de la mise à jour des cartes hosts avec des adresses IPv4, mettez les cartes ipnode à jour avec les mêmes informations.
Les versions suivantes de Oracle Solaris 10 n'utilisent pas les cartes ipnodes. La fonctionnalité IPv6 des cartes ipnodes est à présent maintenue dans les cartes hosts.
Pour obtenir des instructions sur l'administration de cartes NIS, reportez-vous au Chapitre 5, Setting Up and Configuring NIS Service du System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
La commande nslookup permet d'afficher des informations relatives au service d'attribution de noms IPv6.
Après vous être connecté à l'aide de votre compte utilisateur, exécutez la commande nslookup.
% /usr/sbin/nslookup |
Le nom et l'adresse par défaut du serveur s'affichent, suivis du crochet d'invite de la commande nslookup.
Pour obtenir des informations sur un hôte en particulier, saisissez les commandes suivantes à partir du crochet d'invite :
>set q=any >host-name |
Saisissez la commande suivante afin d'afficher les enregistrements AAAA :
>set q=AAAA hostname |
Quittez la commande nslookup en saisissant exit.
Cet exemple illustre les résultats de l'exécution de nslookup dans un environnement de réseau IPv6.
% /usr/sbin/nslookup Default Server: dnsserve.local.com Address: 10.10.50.85 > set q=AAAA > host85 Server: dnsserve.local.com Address: 10.10.50.85 host85.local.com IPv6 address = 2::9256:a00:fe12:528 > exit |
Dans cette procédure, utilisez la commande nslookup afin d'afficher les enregistrements PTR pour le service DNS IPv6.
Une fois connecté à votre compte utilisateur, exécutez la commande nslookup.
% /usr/sbin/nslookup |
Le nom et l'adresse par défaut du serveur s'affichent, suivis du crochet d'invite de la commande nslookup.
Saisissez ce qui suit devant le crochet d'invite afin de visualiser les enregistrements PTR :
>set q=PTR |
Quittez la commande en saisissant exit.
L'exemple suivant illustre l'affichage d'enregistrements PTR à l'aide de la commande nslookup.
% /usr/sbin/nslookup Default Server: space1999.Eng.apex.COM Address: 192.168.15.78 > set q=PTR > 8.2.5.0.2.1.e.f.f.f.0.2.0.0.a.0.6.5.2.9.0.0.0.0.0.0.0.0.2.0.0.0.ip6.int 8.2.5.0.2.1.e.f.f.f.0.2.0.0.a.0.6.5.2.9.0.0.0.0.0.0.0.0.2.0.0.0.ip6.int name = vallejo.ipv6.Eng.apex.COM ip6.int nameserver = space1999.Eng.apex.COM > exit |
Dans cette procédure, la commande ypmatch permet d'afficher des informations IPv6 par le biais de NIS :
Une fois connecté à votre compte utilisateur, saisissez ce qui suit afin d'afficher les adresses IPv6 dans NIS :
% ypmatch hostname hosts ipnodes.byname |
Les informations sur l'hôte hostname spécifié s'affichent.
Les versions suivantes de Oracle Solaris 11/06 ne contiennent plus les cartes ipnodes. La maintenance de la fonctionnalité IPv6 de ipnodes s'effectue à présent dans les cartes hosts.
Dans le cas de Solaris 10 11/06 et versions antérieures, l'exemple suivant illustre les résultas d'une opération de ypmatch sur la base de données ipnodes.byname.
% ypmatch farhost hosts ipnodes.byname 2001:0db8:3c4d:15:a00:20ff:fe12:5286 farhost |
Cette procédure s'utilise uniquement pour Solaris 10 11/06 et les versions antérieures. Pour les versions ultérieures, vous pouvez effectuer la même opération sur la base de données hosts.
Une fois connecté à votre compte utilisateur, saisissez la commande suivante :
% getent ipnodes hostname |
Les informations sur l'hôte nom-hôte s'affichent.
L'exemple suivant illustre la sortie de la commande getent :
% getent ipnodes vallejo 2001:0db8:8512:2:56:a00:fe87:9aba myhost myhost fe80::56:a00:fe87:9aba myhost myhost |
Ce chapitre présente les tâches permettant d'administrer un réseau TCP/IP. Il aborde les sujets suivants :
Principales tâches d'administration TCP/IP (liste des tâches)
Contrôle de la configuration de l'interface avec la commande ifconfig
Contrôle du statut du réseau à l'aide de la commande netstat
Administration et journalisation des affichages de statut du réseau
Affichage des informations de routage à l'aide de la commande traceroute
Contrôle du transfert des paquets à l'aide de la commande snoop
L'exécution des tâches présentées dans ce chapitre nécessite l'installation d'un réseau TCP/IP opérationnel sur votre site (IPv4 uniquement ou IPv4/IPv6 double pile). Pour plus d'informations sur l'implémentation d'un réseau IPv6, reportez-vous aux chapitres suivants :
Pour planifier une implémentation IPv6, reportez-vous au Chapitre 4Planification d'un réseau IPv6 (tâches).
Pour configurer un réseau IPv6 et créer un environnement double pile, reportez-vous au Chapitre 7Configuration d'un réseau IPv6 (tâches).
Le tableau suivant répertorie les autres tâches permettant de gérer le réseau après la configuration initiale, notamment l'affichage des informations réseau. Le tableau comprend la description des actions de chaque tâche et la section de la documentation actuelle dans laquelle les étapes permettant d'effectuer ces tâches sont décrites en détails.
Tâche |
Description |
Référence |
---|---|---|
Affichage des informations de configuration d'une interface. |
Déterminez la configuration actuelle des différentes interfaces du système. |
Méthode d'obtention d'informations sur une interface spécifique |
Affichage des assignations d'adresses d'interface. |
Déterminez les assignations d'adresse de toutes les interfaces du système local. |
Procédure d'affichage des assignations d'adresses de l'interface |
Affichage des statistiques par protocole. |
Contrôlez les performances des protocoles réseau sur un système donné. | |
Affichage du statut du réseau. |
Contrôlez le système en affichant tous les sockets et toutes les entrées de table de routage. La sortie inclut la famille d'adresses inet pour les réseaux IPv4 et la famille d'adresses inet6 pour les réseaux IPv6. | |
Affichage du statut des interfaces réseau. |
Contrôlez les performances des interfaces réseau, notamment afin de dépanner les transmissions de données. | |
Affichage du statut de transmission des paquets. |
Contrôlez le statut des paquets lors de leur transmission sur le réseau câblé. |
Affichage du statut des transmissions de paquets associés à un type d'adresse spécifique |
Contrôle de l'affichage des sorties de commandes IPv6. |
Contrôlez la sortie des commandes ping, netstat, ifconfig et traceroute. Créez un fichier intitulé inet_type. Définissez la variable DEFAULT_IP de ce fichier. | |
Contrôle du trafic réseau. |
Affichez tous les paquets IP à l'aide de la commande snoop. | |
Affichage de toutes les routes connues par les routeurs du réseau. |
Affichez toutes les routes à l'aide de la commande traceroute. |
La commande ifconfig vous permet d'assigner des adresses IP à des interfaces et de configurer des paramètres d'interface manuellement. De plus, les scripts de démarrage Oracle Solaris exécutent la commande ifconfig pour configurer des pseudo-interfaces, telles que des points d'extrémité de tunnels 6to4.
Ce manuel décrit les nombreuses tâches qui s'accomplissent avec les diverses options de la commande ifconfig. Pour de plus amples informations sur cette commande, ses options et ses variables, reportez-vous à la page de manuel ifconfig(1M) La commande ifconfig possède la syntaxe de base suivante :
ifconfig interface [famille protocole]
La commande ifconfig permet de déterminer les informations de base relatives aux interfaces d'un système particulier. Par exemple, une simple requête ifconfig peut indiquer les informations suivantes :
noms des périphériques de toutes les interfaces d'un système ;
toutes les adresses IPv4 et IPv6 (le cas échéant) assignées aux interfaces ;
statut de configuration de ces interfaces.
La procédure suivante décrit la façon dont la commande ifconfig doit être utilisée pour fournir des informations de configuration de base sur les interfaces d'un système.
Sur l'hôte local, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Récupérez les informations sur l'interface qui vous intéresse.
# ifconfig interface |
La commande ifconfig affiche la sortie suivante :
Ligne relative au statut
La première ligne de la sortie de la commande ifconfig indique le nom de l'interface ainsi que le statut qui lui est actuellement associé (par le biais d'un indicateur). Sur cette ligne figurent également l'unité de transmission maximale configurable sur l'interface ainsi qu'un numéro d'index. La ligne relative au statut vous permet de connaître l'état actuel de l'interface.
Ligne d'informations sur l'adresse IP
La deuxième ligne de la sortie de la commande ifconfig inclut l'adresse IPv4 ou IPv6 configurée sur l'interface. S'il s'agit d'une adresse IPv4, cette ligne indique également le masque de réseau configuré et l'adresse de diffusion.
Ligne relative à l'adresse MAC
Lorsque vous exécutez la commande ifconfig en tant que superutilisateur ou avec un rôle similaire, la sortie contient une troisième ligne. Si une adresse IPv4 est configurée, cette ligne indique l'adresse MAC (adresse de couche Ethernet) assignée à l'interface. S'il s'agit d'une adresse IPv6, cette troisième ligne contient l'adresse locale du lien que le démon IPv6 in.ndpd génère à partir de l'adresse MAC.
L'exemple suivant décrit la syntaxe de la commande ifconfig à rédiger pour obtenir des informations sur l'interface eri configurée sur un hôte particulier.
# ifconfig eri eri0: flags=863<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 1 inet 10.0.0.112 netmask ffffff80 broadcast 10.8.48.127 ether 8:0:20:b9:4c:54 |
Le tableau suivant décrit les informations de la variable de la requête de la commande ifconfig et comprend également la description de la variable qui peut s'afficher à l'écran et le type d'informations fournies. Il se base sur l'exemple de sortie précédent.
Variable |
Sortie écran |
Description |
---|---|---|
Nom de l'interface |
eri0 |
Indique le nom du périphérique de l'interface dont le statut a été requis par la commande ifconfig. |
Statut de l'interface |
flags=863<UP |
Indique le statut de l'interface et spécifie notamment les indicateurs actuellement associés à celle-ci. Cette information vous permet de savoir si l'interface est initialisée (UP) ou non (DOWN ). |
Statut de la diffusion |
BROADCAST |
Indique si l'interface prend en charge les diffusions sur IPv4. |
Etat de transmission |
RUNNING |
Indique si le système transmet actuellement des paquets via l'interface. |
Statut de la multidiffusion |
MULTICAST, IPv4 |
Indique si l'interface prend en charge les transmissions multidiffusions. Dans cet exemple, l'interface prend en charge les transmissions multidiffusions IPv4. |
Unité de transmission maximale |
mtu 1500 |
Indique que la taille de transfert maximale de cette interface est de 1 500 octets. |
Adresse IP |
inet 10.0.0.112 |
Indique l'adresse IPv4 ou IPv6 assignée à l'interface. Dans cet exemple, l'interface eri0 possède l'adresse IPv4 10.0.0.112. |
Masque de réseau |
netmask ffffff80 |
Indique le masque de réseau IPv4 de l'interface. Notez que les adresses IPv6 n'utilisent pas de masques de réseau. |
Adresse MAC |
ether 8:0:20:b9:4c:54 |
Indique l'adresse de couche Ethernet de l'interface. |
Les routeurs et hôtes multiréseaux possèdent plusieurs interfaces auxquelles sont souvent assignées plus d'une adresse IP. La commande ifconfig vous permet dans ce cas d'afficher toutes les adresses assignées aux interfaces d'un système. Elle peut n'indiquer que les assignations d'adresses IPv4 ou IPv6. Pour afficher également les adresses MAC des interfaces, vous devez d'abord vous connecter en tant que superutilisateur ou assumer un rôle similaire.
Pour de plus amples informations sur la commande ifconfig, reportez-vous à la page de manuel ifconfig(1M).
Sur le système local, connectez-vous en tant qu'administrateur réseau ou superutilisateur.
Les rôles contiennent des autorisations et des commandes privilégiées. Pour de plus amples informations sur les rôles, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Récupérez les informations sur toutes les interfaces.
Vous pouvez exécuter la commande ifconfig -a pour obtenir les informations suivantes :
adresses de toutes les interfaces du système ;
# ifconfig -a |
toutes les adresses IPv4 assignées aux interfaces du système ;
# ifconfig -a4 |
toutes les adresses IPv6 assignées aux interfaces du système, à condition que celui-ci soit compatible avec IPv6.
ifconfig -a6 |
L'exemple suivant correspond à un hôte ne possédant qu'une interface du réseau principal nommée qfe0. La sortie de la commande ifconfig indique néanmoins que trois formes d'adresses sont actuellement assignées à qfe0 : loopback (lo0), IPv4 (inet) et IPv6 (inet6). Dans la section de la sortie relative à IPv6, la ligne de l'interface qfe0 indique une adresse IPv6 locale du lien. La seconde adresse de qfe0 figure sur la ligne qfe0:1.
% ifconfig -a lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 qfe0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.112 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:b9:4c:54 lo0: flags=2000849 <UP,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 8:0:20:b9:4c:54 inet6 fe80::a00:20ff:feb9:4c54/10 qfe0:1: flags=2080841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2 inet6 2001:db8:3c4d:48:a00:20ff:feb9:4c54/64 |
Dans l'exemple suivant, l'adresse IPv4 est configurée pour un hôte multiréseau. Pour exécuter ce type de commande ifconfig, vous devez vous connecter en tant que superutilisateur.
% ifconfig -a4 lo0: flags=1000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 qfe0: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.112 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:b9:4c:54 qfe1: flags=1004843 <UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.0.0.118 netmask ffffff80 broadcast 10.0.0.127 ether 8:0:20:6f:5e:17 |
Cet exemple n'indique que les adresses IPv6 configurée pour un hôte particulier. Pour exécuter ce type de commande ifconfig, vous devez vous connecter en tant que superutilisateur.
% ifconfig -a6 lo0: flags=2000849 <UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 qfe0: flags=2000841 <UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 ether 8:0:20:b9:4c:54 inet6 fe80::a00:20ff:feb9:4c54/10 qfe0:1: flags=2080841 <UP,RUNNING,MULTICAST,ADDRCONF,IPv6> mtu 1500 index 2 inet6 2001:db8:3c4d:48:a00:20ff:feb9:4c54/64 |
Cet exemple de sortie ifconfig indique les trois types d'adresse IPv6 assignés à une seule interface d'un hôte :
Adresse de loopback IPv6.
Adresse locale du lien assignée à l'interface du réseau principal.
Adresse IPv6 (y compris le préfixe de sous-réseau). Le terme ADDRCONF qui figure dans la sortie indique que cette adresse a été automatiquement configurée par l'hôte.
La commande netstat génère des affichages illustrant le statut du réseau ainsi que les statistiques des protocoles. Vous pouvez afficher le statut des points d'extrémité TCP, SCTP et UDP sous forme de table. Vous pouvez également afficher les informations de table de routage ainsi que les informations d'interface.
La commande netstat permet d'afficher différents types d'informations sur le réseau, suivant l'option de ligne de commande sélectionnée. Les affichages obtenus constituent la principale référence pour l'administration du système. L'exemple ci-dessous illustre la syntaxe de base de la commande netstat :
netstat [-m] [-n] [-s] [-i | -r] [-f famille-adresses]
Cette section décrit les options fréquemment utilisées avec la commande netstat. Pour obtenir une description détaillée des toutes les options netstat, reportez-vous à la page de manuel netstat(1M).
L'option -s de la commande netstat permet d'afficher les statistiques des protocoles UDP, TCP, SCTP, ICMP et IP.
Vous pouvez obtenir la sortie de la commande netstat à l'aide du compte utilisateur Oracle Solaris.
L'exemple suivant illustre la sortie de la commande netstat - s. Certaines parties de la sortie ont été tronquées. La sortie peut signaler les opérations ayant généré des problèmes pour les différents protocoles. Par exemple, les statistiques affichées pour ICMPv4 et ICMPv6 peuvent signaler les opérations ayant généré des erreurs pour le protocole ICMP.
RAWIP rawipInDatagrams = 4701 rawipInErrors = 0 rawipInCksumErrs = 0 rawipOutDatagrams = 4 rawipOutErrors = 0 UDP udpInDatagrams = 10091 udpInErrors = 0 udpOutDatagrams = 15772 udpOutErrors = 0 TCP tcpRtoAlgorithm = 4 tcpRtoMin = 400 tcpRtoMax = 60000 tcpMaxConn = -1 . . tcpListenDrop = 0 tcpListenDropQ0 = 0 tcpHalfOpenDrop = 0 tcpOutSackRetrans = 0 IPv4 ipForwarding = 2 ipDefaultTTL = 255 ipInReceives =300182 ipInHdrErrors = 0 ipInAddrErrors = 0 ipInCksumErrs = 0 . . ipsecInFailed = 0 ipInIPv6 = 0 ipOutIPv6 = 3 ipOutSwitchIPv6 = 0 IPv6 ipv6Forwarding = 2 ipv6DefaultHopLimit = 255 ipv6InReceives = 13986 ipv6InHdrErrors = 0 ipv6InTooBigErrors = 0 ipv6InNoRoutes = 0 . . rawipInOverflows = 0 ipv6InIPv4 = 0 ipv6OutIPv4 = 0 ipv6OutSwitchIPv4 = 0 ICMPv4 icmpInMsgs = 43593 icmpInErrors = 0 icmpInCksumErrs = 0 icmpInUnknowns = 0 . . icmpInOverflows = 0 ICMPv6 icmp6InMsgs = 13612 icmp6InErrors = 0 icmp6InDestUnreachs = 0 icmp6InAdminProhibs = 0 . . icmp6OutGroupQueries= 0 icmp6OutGroupResps = 2 icmp6OutGroupReds = 0 IGMP: 12287 messages received 0 messages received with too few bytes 0 messages received with bad checksum 12287 membership queries received SCTP sctpRtoAlgorithm = vanj sctpRtoMin = 1000 sctpRtoMax = 60000 sctpRtoInitial = 3000 sctpTimHearBeatProbe = 2 sctpTimHearBeatDrop = 0 sctpListenDrop = 0 sctpInClosed = 0 |
La commande netstat permet d'afficher le statut des protocoles de transport. Pour plus d'informations, reportez-vous à la page de manuel netstat(1M).
Affichez le statut des protocoles de transport TCP et SCTP sur un système.
$ netstat |
Affichez le statut d'un protocole de transport donné sur un système.
$ netstat -P transport-protocol |
La variable protocole-transport peut être définie sur les valeurs suivantes : tcp, sctp ou udp.
L'exemple ci-dessous illustre la sortie de base de la commande netstat. Les informations contenues dans la sortie se rapportent uniquement à IPv4.
$ netstat TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State ----------------- -------------------- ----- ------ ----- ------ ------- lhost-1.login abc.def.local.Sun.COM.980 49640 0 49640 0 ESTABLISHED lhost-1.login ghi.jkl.local.Sun.COM.1020 49640 1 49640 0 ESTABLISHED remhost-1.1014 mno.pqr.remote.Sun.COM.nfsd 49640 0 49640 0 TIME_WAIT SCTP: Local Address Remote Address Swind Send-Q Rwind Recv-Q StrsI/O State ---------------- -------------- ----- ------ ------ ------ ------ ------- *.echo 0.0.0.0 0 0 102400 0 128/1 LISTEN *.discard 0.0.0.0 0 0 102400 0 128/1 LISTEN *.9001 0.0.0.0 0 0 102400 0 128/1 LISTEN |
L'exemple ci-dessous illustre le résultat obtenu suite à l'exécution de la commande netstat avec l'option -P.
$ netstat -P tcp TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State ----------------- -------------------- ----- ------ ----- ------ ------- lhost-1.login abc.def.local.Sun.COM.980 49640 0 49640 0 ESTABLISHED lhost.login ghi.jkl.local.Sun.COM.1020 49640 1 49640 0 ESTABLISHED remhost.1014 mno.pqr.remote.Sun.COM.nfsd 49640 0 49640 0 TIME_WAIT TCP: IPv6 Local Address Remote Address Swind Send-Q Rwind Recv-Q State If ---------------- ---------------------- ------ ----- ------ ----------- ----- localhost.38983 localhost.32777 49152 0 49152 0 ESTABLISHED localhost.32777 localhost.38983 49152 0 49152 0 ESTABLISHED localhost.38986 localhost.38980 49152 0 49152 0 ESTABLISHED |
L'option i de la commande netstat illustre le statut des interfaces réseau configurées sur le système local. Cette option permet de déterminer le nombre de paquets transmis et reçus sur un système sur les différents réseaux.
L'exemple suivant illustre le statut du flux de paquets IPv4 et IPv6 sur les interfaces de l'hôte.
Par exemple, le nombre de paquets entrants (Ipkts) affiché pour un serveur peut augmenter à chaque tentative de démarrage d'un client alors que le nombre de paquets sortants (Opkts) reste inchangé. Ce résultat suggère que le serveur détecte les paquets de requête de démarrage envoyés par le client, mais qu'il ne parvient pas à formuler la réponse appropriée. Cette erreur peut être liée à la spécification d'une adresse incorrecte dans la base de données hosts, ipnodes ou ethers.
En revanche, si le nombre de paquets entrants reste inchangé sur la durée, l'ordinateur ne détecte même pas l'envoi des paquets. Ce résultat suggère un autre type d'erreur, vraisemblablement lié à un problème d'ordre matériel.
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue lo0 8232 loopback localhost 142 0 142 0 0 0 hme0 1500 host58 host58 1106302 0 52419 0 0 0 Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis lo0 8252 localhost localhost 142 0 142 0 0 hme0 1500 fe80::a00:20ff:feb9:4c54/10 fe80::a00:20ff:feb9:4c54 1106305 0 52422 0 0 |
L'option -a de la commande netstat permet d'afficher le statut des sockets sur l'hôte local.
Pour afficher le statut des sockets et des entrées de table de routage, saisissez la commande suivante :
L'exécution de cette option de la commande netstat peut s'effectuer à l'aide du compte utilisateur.
% netstat -a |
La sortie de la commande netstat -a contient de nombreuses statistiques. L'exemple ci-dessous illustre certaines parties d'une sortie classique de la commande netstat -a.
UDP: IPv4 Local Address Remote Address State -------------------- -------------------- ------- *.bootpc Idle host85.bootpc Idle *.* Unbound *.* Unbound *.sunrpc Idle *.* Unbound *.32771 Idle *.sunrpc Idle *.* Unbound *.32775 Idle *.time Idle . . *.daytime Idle *.echo Idle *.discard Idle UDP: IPv6 Local Address Remote Address State If --------------------------------- --------------------------------- ---------- ----- *.* Unbound *.* Unbound *.sunrpc Idle *.* Unbound *.32771 Idle *.32778 Idle *.syslog Idle . . TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ------- *.* *.* 0 0 49152 0 IDLE localhost.4999 *.* 0 0 49152 0 LISTEN *.sunrpc *.* 0 0 49152 0 LISTEN *.* *.* 0 0 49152 0 IDLE *.sunrpc *.* 0 0 49152 0 LISTEN . . *.printer *.* 0 0 49152 0 LISTEN *.time *.* 0 0 49152 0 LISTEN *.daytime *.* 0 0 49152 0 LISTEN *.echo *.* 0 0 49152 0 LISTEN *.discard *.* 0 0 49152 0 LISTEN *.chargen *.* 0 0 49152 0 LISTEN *.shell *.* 0 0 49152 0 LISTEN *.shell *.* 0 0 49152 0 LISTEN *.kshell *.* 0 0 49152 0 LISTEN *.login . . *.* 0 0 49152 0 LISTEN *TCP: IPv6 Local Address Remote Address Swind Send-Q Rwind Recv-Q State If ----------------------- ----------------------- ----- ------ ----- ------ ---- *.* *.* 0 0 49152 0 IDLE *.sunrpc *.* 0 0 49152 0 LISTEN *.* *.* 0 0 49152 0 IDLE *.32774 *.* 0 0 49152 |
L'option -f de la commande netstat permet d'afficher les statistiques relatives aux transmissions de paquets associées à une famille d'adresses donnée.
Affichez les statistiques relatives aux transmissions de paquets IPv4 ou IPv6.
$ netstat -f inet | inet6 |
Pour afficher les informations relatives aux transmissions IPv4, définissez l'argument inet pour la commande netstat -f. Pour afficher les informations relatives aux transmissions IPv6, définissez l'argument inet6 pour la commande netstat -f.
L'exemple suivant illustre la sortie de la commande netstat - f inet.
TCP: IPv4 Local Address Remote Address Swind Send-Q Rwind Recv-Q State -------------------- -------------------- ----- ------ ----- ------ ------- host58.734 host19.nfsd 49640 0 49640 0 ESTABLISHED host58.38063 host19.32782 49640 0 49640 0 CLOSE_WAIT host58.38146 host41.43601 49640 0 49640 0 ESTABLISHED host58.996 remote-host.login 49640 0 49206 0 ESTABLISHED |
L'exemple suivant illustre la sortie de la commande netstat -f inet6.
TCP: IPv6 Local Address Remote Address Swind Send-Q Rwind Recv-Q State If ------------------ ------------------------- ----- ------ ----- ------ --------- ----- localhost.38065 localhost.32792 49152 0 49152 0 ESTABLISHED localhost.32792 localhost.38065 49152 0 49152 0 ESTABLISHED localhost.38089 localhost.38057 49152 0 49152 0 ESTABLISHED |
L'option -r de la commande netstat permet d'afficher la table de routage de l'hôte local. Cette table représente le statut de toutes les routes connues de l'hôte. L'exécution de cette option de la commande netstat peut s'effectuer à l'aide du compte utilisateur.
L'exemple suivant illustre la sortie de la commande netstat -r.
Routing Table: IPv4 Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- host15 myhost U 1 31059 hme0 10.0.0.14 myhost U 1 0 hme0 default distantrouter UG 1 2 hme0 localhost localhost UH 42019361 lo0 Routing Table: IPv6 Destination/Mask Gateway Flags Ref Use If --------------------------- --------------------------- ----- --- ------ ----- 2002:0a00:3010:2::/64 2002:0a00:3010:2:1b2b:3c4c:5e6e:abcd U 1 0 hme0:1 fe80::/10 fe80::1a2b:3c4d:5e6f:12a2 U 1 23 hme0 ff00::/8 fe80::1a2b:3c4d:5e6f:12a2 U 1 0 hme0 default fe80::1a2b:3c4d:5e6f:12a2 UG 1 0 hme0 localhost localhost UH 9 21832 lo0 |
Le tableau suivant décrit les différents paramètres de la sortie à l'écran de la commande netstat —r.
Paramètre |
Description |
---|---|
Destination Destination/Mask |
Spécifie l'hôte correspondant au point d'extrémité de destination de la route. Dans la table de routage IPv6, le point d'extrémité de destination est représenté par un préfixe de point d'extrémité de tunnel 6to4 ( 2002:0a00:3010:2::/64). |
Gateway |
Spécifie la passerelle de transmission des paquets. |
Flags |
Indique le statut actuel de la route. L'indicateur U signifie que la route fonctionne. L'indicateur G signifie que la route mène à une passerelle. |
Use |
Affiche le nombre de paquets envoyés. |
Interface |
Indique l'interface de l'hôte local correspondant au point d'extrémité source de la transmission. |
La commande ping permet de déterminer le statut d'un hôte distant. Lors de l'exécution de la commande ping, le protocole ICMP envoie un datagramme à l'hôte spécifié et attend la réponse. Le protocole ICMP permet de gérer les erreurs se produisant sur les réseaux TCP/IP. L'exécution de la commande ping permet de déterminer l'existence d'une connexion IP pour l'hôte distant spécifié.
L'exemple suivant illustre la syntaxe de base de la commande ping :
/usr/sbin/ping hôte [délai]
Dans cette syntaxe, la variable hôte correspond au nom de l'hôte distant. L'argument délai indique la durée en secondes pendant laquelle la commande ping tente de contacter l'hôte distant. La valeur par défaut est de 20 secondes. Pour plus d'informations sur la syntaxe et les options de la commande, reportez-vous à la page de manuel ping(1M)
Tapez la commande ping suivante :
$ ping hostname |
Si l'hôte nom-hôte accepte les transmissions ICMP, le message suivant s'affiche :
hostname is alive |
Ce message indique que nom-hôte a répondu à la requête ICMP. En revanche, si nom-hôte ne fonctionne pas ou ne reçoit pas les paquets ICMP, la commande ping génère la réponse suivante :
no answer from hostname |
L'option -s de la commande ping permet de vérifier qu'un hôte distant est en cours d'exécution et de détecter toute perte de paquet sur cet hôte.
La commande ping -s nom-hôte envoie des paquets en continu à l'hôte spécifié pendant un laps de temps donné ou jusqu'à l'envoi d'un caractère d'interruption. Les réponses affichées sont comparables à celles de l'écran suivant :
& ping -s host1.domain8 PING host1.domain8 : 56 data bytes 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=0. time=1.67 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=1. time=1.02 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=2. time=0.986 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=3. time=0.921 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=4. time=1.16 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=5. time=1.00 ms 64 bytes from host1.domain8.COM (172.16.83.64): icmp_seq=5. time=1.980 ms ^C ----host1.domain8 PING Statistics---- 7 packets transmitted, 7 packets received, 0% packet loss round-trip (ms) min/avg/max/stddev = 0.921/1.11/1.67/0.26 |
La statistique de perte de paquet indique si l'hôte a abandonné des paquets. Si la commande ping échoue, vérifiez le statut du réseau indiqué dans les sorties des commandes ifconfig et netstat. Reportez-vous aux sections Contrôle de la configuration de l'interface avec la commande ifconfig et Contrôle du statut du réseau à l'aide de la commande netstat.
Les tâches suivantes illustrent les procédures de vérification du statut du réseau à l'aide de commandes de réseau standard.
Vous pouvez définir la sortie des commandes netstat et ifconfig de manière à afficher uniquement les informations IPv4 ou à afficher les informations IPv4 et IPv6.
Créez le fichier /etc/default/inet_type.
Ajoutez l'une des entrées suivantes au fichier /etc/default/inet_type :
Pour afficher uniquement les informations IPv4 :
DEFAULT_IP=IP_VERSION4 |
Pour afficher les informations IPv4 et IPv6 :
DEFAULT_IP=BOTH |
Ou
DEFAULT_IP=IP_VERSION6 |
Pour plus d'informations sur le fichier inet_type, reportez-vous à la page de manuel inet_type(4).
Les indicateurs -4 et -6 de la commande ifconfig ont priorité sur les valeurs définies dans le fichier inet_type. L'indicateur -f de la commande netstat a également priorité sur les valeurs définies dans le fichier inet_type.
Si vous spécifiez la variable DEFAULT_IP=BOTH ou la variable DEFAULT_IP=IP_VERSION6 dans le fichier inet_type, la sortie suivante s'affiche :
% ifconfig -a lo0: flags=1000849 mtu 8232 index 1 inet 10.10.0.1 netmask ff000000 qfe0: flags=1000843 mtu 1500 index 2 inet 10.46.86.54 netmask ffffff00 broadcast 10.46.86.255 ether 8:0:20:56:a8 lo0: flags=2000849 mtu 8252 index 1 inet6 ::1/128 qfe0: flags=2000841 mtu 1500 index 2 ether 8:0:20:56:a8 inet6 fe80::a00:fe73:56a8/10 qfe0:1: flags=2080841 mtu 1500 index 2 inet6 2001:db8:3c4d:5:a00:fe73:56a8/64 |
Si vous spécifiez la variable DEFAULT_IP=IP_VERSION4 ou la variable DEFAULT_IP=IP_VERSION6 dans le fichier inet_type, la sortie suivante s'affiche :
% ifconfig -a lo0: flags=849 mtu 8232 inet 10.10.0.1 netmask ff000000 qfe0: flags=843 mtu 1500 inet 10.46.86.54 netmask ffffff00 broadcast 10.46.86.255 ether 8:0:20:56:a8 |
Si vous pensez que le démon de routage IPv4 routed ne fonctionne pas correctement, vous pouvez créer un journal permettant d'effectuer le suivi de l'activité correspondante. Le journal inclut tous les transferts de paquets à compter du démarrage du démon routed.
Sur l'hôte local, connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Créez un fichier journal permettant d'effectuer le suivi des opérations du démon :
# /usr/sbin/in.routed /var/log-file-name |
Sur les réseaux à forte activité, la sortie de cette commande peut être générée sur une base quasi continue.
L'exemple suivant illustre le début du journal créé à l'aide de la procédure Journalisation des actions du démon de routage IPv4.
-- 2003/11/18 16:47:00.000000 -- Tracing actions started RCVBUF=61440 Add interface lo0 #1 127.0.0.1 -->127.0.0.1/32 <UP|LOOPBACK|RUNNING|MULTICAST|IPv4> <PASSIVE> Add interface hme0 #2 10.10.48.112 -->10.10.48.0/25 <UP|BROADCAST|RUNNING|MULTICAST|IPv4> turn on RIP Add 10.0.0.0 -->10.10.48.112 metric=0 hme0 <NET_SYN> Add 10.10.48.85/25 -->10.10.48.112 metric=0 hme0 <IF|NOPROP> |
Si vous pensez que le démon IPv6 in.ndpd ne fonctionne pas correctement, vous pouvez générer le suivi de l'activité correspondante. Le suivi s'affiche sur la sortie standard jusqu'à l'arrêt du processus. Il inclut tous les transferts de paquets à compter du démarrage du démon in.ndpd.
Connectez-vous au nœud IPv6 local en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Générez le suivi du démon in.ndpd.
# /usr/lib/inet/in.ndpd -t |
Pour arrêter le processus de suivi, appuyez sur les touches Ctrl-C.
La sortie suivante illustre le début du suivi du démon in.ndpd.
# /usr/lib/inet/in.ndpd -t Nov 18 17:27:28 Sending solicitation to ff02::2 (16 bytes) on hme0 Nov 18 17:27:28 Source LLA: len 6 <08:00:20:b9:4c:54> Nov 18 17:27:28 Received valid advert from fe80::a00:20ff:fee9:2d27 (88 bytes) on hme0 Nov 18 17:27:28 Max hop limit: 0 Nov 18 17:27:28 Managed address configuration: Not set Nov 18 17:27:28 Other configuration flag: Not set Nov 18 17:27:28 Router lifetime: 1800 Nov 18 17:27:28 Reachable timer: 0 Nov 18 17:27:28 Reachable retrans timer: 0 Nov 18 17:27:28 Source LLA: len 6 <08:00:20:e9:2d:27> Nov 18 17:27:28 Prefix: 2001:08db:3c4d:1::/64 Nov 18 17:27:28 On link flag:Set Nov 18 17:27:28 Auto addrconf flag:Set Nov 18 17:27:28 Valid time: 2592000 Nov 18 17:27:28 Preferred time: 604800 Nov 18 17:27:28 Prefix: 2002:0a00:3010:2::/64 Nov 18 17:27:28 On link flag:Set Nov 18 17:27:28 Auto addrconf flag:Set Nov 18 17:27:28 Valid time: 2592000 Nov 18 17:27:28 Preferred time: 604800 |
La commande traceroute permet d'obtenir le suivi de la route empruntée par un paquet IP pour accéder à un système distant. Pour plus d'informations sur la commande traceroute, reportez-vous à la page de manuel traceroute(1M).
La commande traceroute permet de détecter les erreurs de configuration de routage et les échecs de chemin de routage. Si un hôte est inaccessible, la commande traceroute permet d'afficher le chemin suivi par les paquets afin de détecter les emplacements susceptibles d'être à l'origine de l'échec.
La commande traceroute affiche également le délai d'aller-retour de chaque passerelle sur le chemin d'accès à l'hôte cible. Ces informations permettent notamment de déterminer l'emplacement des ralentissements de trafic entre les deux hôtes.
Pour déterminer la route menant à un hôte distant, exécutez la commande suivante :
% traceroute destination-hostname |
L'exécution de cette forme de la commande traceroute peut s'effectuer à l'aide du compte utilisateur.
La sortie suivante de la commande traceroute affiche le chemin à sept sauts suivi par les paquets pour circuler du système local nearhost vers le système distant farhost. La sortie illustre également le temps nécessaire à un paquet pour traverser les différents sauts.
istanbul% traceroute farhost.faraway.com traceroute to farhost.faraway.com (172.16.64.39), 30 hops max, 40 byte packets 1 frbldg7c-86 (172.16.86.1) 1.516 ms 1.283 ms 1.362 ms 2 bldg1a-001 (172.16.1.211) 2.277 ms 1.773 ms 2.186 ms 3 bldg4-bldg1 (172.16.4.42) 1.978 ms 1.986 ms 13.996 ms 4 bldg6-bldg4 (172.16.4.49) 2.655 ms 3.042 ms 2.344 ms 5 ferbldg11a-001 (172.16.1.236) 2.636 ms 3.432 ms 3.830 ms 6 frbldg12b-153 (172.16.153.72) 3.452 ms 3.146 ms 2.962 ms 7 sanfrancisco (172.16.64.39) 3.430 ms 3.312 ms 3.451 ms |
Cette procédure permet d'afficher le suivi de toutes les routes à l'aide de l'option -a de la commande traceroute.
Exécutez la commande suivante sur le système local :
% traceroute -ahost-name |
L'exécution de cette forme de la commande traceroute peut s'effectuer à l'aide du compte utilisateur.
L'exemple ci-dessous illustre toutes les routes possibles pour accéder à un hôte double pile.
% traceroute -a v6host.remote.com traceroute: Warning: Multiple interfaces found; using 2::56:a0:a8 @ eri0:2 traceroute to v6host (2001:db8:4a3b::102:a00:fe79:19b0),30 hops max, 60 byte packets 1 v6-rout86 (2001:db8:4a3b:56:a00:fe1f:59a1) 35.534 ms 56.998 ms * 2 2001:db8::255:0:c0a8:717 32.659 ms 39.444 ms * 3 farhost.faraway.COM (2001:db8:4a3b::103:a00:fe9a:ce7b) 401.518 ms 7.143 ms * 4 distant.remote.com (2001:db8:4a3b::100:a00:fe7c:cf35) 113.034 ms 7.949 ms * 5 v6host (2001:db8:4a3b::102:a00:fe79:19b0) 66.111 ms * 36.965 ms traceroute to v6host.remote.com (192.168.10.75),30 hops max,40 byte packets 1 v6-rout86 (172.16.86.1) 4.360 ms 3.452 ms 3.479 ms 2 flrmpj17u.here.COM (172.16.17.131) 4.062 ms 3.848 ms 3.505 ms 3 farhost.farway.com (10.0.0.23) 4.773 ms * 4.294 ms 4 distant.remote.com (192.168.10.104) 5.128 ms 5.362 ms * 5 v6host (192.168.15.85) 7.298 ms 5.444 ms * |
La commande snoop permet de contrôler le statut des transferts de données. La commande snoop permet de capturer les paquets réseau et d'afficher leur contenu au format spécifié. Les paquets peuvent être affichés dès leur réception ou dès l'enregistrement dans un fichier. L'écriture des données dans un fichier intermédiaire par la commande snoop permet de réduire la probabilité de perte de paquet liée à l'activité de suivi. Le fichier est alors également interprété par la commande snoop.
Pour capturer des paquets en provenance et à destination de l'interface par défaut en mode promiscuité, vous devez vous connecter en tant qu'administrateur réseau ou superutilisateur. Dans sa forme contractée, la commande snoop affiche uniquement les données en rapport avec le protocole principal. Par exemple, un paquet NFS affiche uniquement les informations NFS. Les informations RPC, UDP, IP et Ethernet sont supprimées, mais vous pouvez y accéder en sélectionnant l'une des options détaillées de la commande.
L'exécution répétée à intervalles fréquents de la commande snoop permet d'identifier les comportements normaux du système. Pour obtenir de l'aide sur l'analyse des paquets, consultez les livres blancs et documents RFC récents et demandez conseil aux experts dans les domaines concernés (par exemple, NFS ou NIS). Pour plus d'informations sur l'utilisation de la commande snoop et des options associées, reportez-vous à la page de manuel snoop(1M)
Sur l'hôte local, connectez-vous en tant qu'administrateur réseau ou superutilisateur.
Les rôles contiennent des autorisations et des commandes privilégiées. Pour de plus amples informations sur les rôles, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Imprimez les informations sur les interfaces connectées au système.
# ifconfig -a |
La commande snoop utilise normalement le premier périphérique non-loopback (en principe, l'interface réseau principale).
Commencez la capture des paquets en exécutant la commande snoop sans argument, comme illustré dans l'Exemple 8–19.
Pour arrêter le processus, appuyez sur les touches Ctrl-C.
La commande snoop standard renvoie une sortie comparable à l'écran suivant (pour un hôte double pile).
% snoop Using device /dev/hme (promiscuous mode) farhost.remote.com -> myhost RLOGIN C port=993 myhost -> farhost.remote.com RLOGIN R port=993 Using device /dev/hme router5.local.com -> router5.local.com ARP R 10.0.0.13, router5.local.com is 0:10:7b:31:37:80 router5.local.com -> BROADCAST TFTP Read "network-confg" (octet) farhost.remote.com -> myhost RLOGIN C port=993 myhost -> nisserve2 NIS C MATCH 10.0.0.64 in ipnodes.byaddr nisserve2 -> myhost NIS R MATCH No such key blue-112 -> slave-253-2 NIS C MATCH 10.0.0.112 in ipnodes.byaddr myhost -> DNSserver.local.com DNS C 192.168.10.10.in-addr.arpa. Internet PTR ? DNSserver.local.com myhost DNS R 192.168.10.10.in-addr.arpa. Internet PTR niserve2. . . farhost.remote.com-> myhost RLOGIN C port=993 myhost -> farhost.remote.com RLOGIN R port=993 fe80::a00:20ff:febb: . fe80::a00:20ff:febb:e09 -> ff02::9 RIPng R (5 destinations) |
Les paquets capturés dans cette sortie comprennent une section de connexion à distance, qui contient des requêtes vers les serveurs NIS et DNS pour la résolution d'adresse. Ils comprennent également des paquets ARP périodiques en provenance du routeur local et des publications de l'adresse IPv6 lien-local sur in.ripngd.
Sur l'hôte local, connectez-vous en tant qu'administrateur réseau ou superutilisateur.
Les rôles contiennent des autorisations et des commandes privilégiées. Pour de plus amples informations sur les rôles, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Capturez une session de commande snoop dans un fichier.
# snoop -o filename |
Exemple :
# snoop -o /tmp/cap Using device /dev/eri (promiscuous mode) 30 snoop: 30 packets captured |
Dans cet exemple, 30 paquets sont capturés dans le fichier /tmp/cap. Ce fichier peut se trouver dans tout répertoire contenant suffisamment d'espace disque. Le nombre de paquets capturés s'affiche sur la ligne de commande. Vous pouvez dès lors appuyez sur les touches Ctrl-C à tout moment pour arrêter le processus.
La commande snoop génère une charge réseau conséquente, ce qui risque de fausser légèrement les résultats. Pour garantir la précision des résultats, exécutez la commande snoop à partir d'un système tiers.
Consultez le fichier de capture de sortie de la commande snoop.
# snoop -i filename |
La sortie suivante illustre diverses captures susceptibles d'être obtenues suite à l'exécution de la commande snoop -i.
# snoop -i /tmp/cap 1 0.00000 fe80::a00:20ff:fee9:2d27 -> fe80::a00:20ff:fecd:4375 ICMPv6 Neighbor advertisement 2 0.16198 farhost.com -> myhost RLOGIN C port=985 3 0.00008 myhost -> farhost.com RLOGIN R port=985 10 0.91493 10.0.0.40 -> (broadcast) ARP C Who is 10.0.0.40, 10.0.0.40 ? 34 0.43690 nearserver.here.com -> 224.0.1.1 IP D=224.0.1.1 S=10.0.0.40 LEN=28, ID=47453, TO =0x0, TTL=1 35 0.00034 10.0.0.40 -> 224.0.1.1 IP D=224.0.1.1 S=10.0.0.40 LEN=28, ID=57376, TOS=0x0, TTL=47 |
Définissez un système snoop à partir d'un hub connecté soit au serveur soit au client.
Le système tiers (système snoop) vérifie tous les types de trafic entre les deux ordinateurs. Le suivi obtenu grâce à la commande snoop reflète donc le transfert réel de données.
Sur le système snoop, connectez-vous en tant qu'administrateur réseau ou superutilisateur.
Les rôles contiennent des autorisations et des commandes privilégiées. Pour de plus amples informations sur les rôles, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Exécutez la commande snoop associée aux options appropriées, puis enregistrez la sortie dans un fichier.
Consultez et interprétez la sortie.
Reportez-vous au document RFC 1761, Snoop Version 2 Packet Capture File Format pour plus d'informations sur le fichier de capture snoop.
La commande snoop permet d'afficher les paquets IPv6 uniquement.
Sur le nœud local, connectez-vous en tant qu'administrateur réseau ou superutilisateur.
Les rôles contiennent des autorisations et des commandes privilégiées. Pour de plus amples informations sur les rôles, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Capturez les paquets IPv6.
# snoop ip6 |
Pour plus d'informations sur la commande snoop, reportez-vous à la page de manuel snoop(1M).
L'exemple suivant illustre la sortie standard susceptible d'être obtenue suite à l'exécution de la commande snoop ip6 sur un nœud.
# snoop ip6 fe80::a00:20ff:fecd:4374 -> ff02::1:ffe9:2d27 ICMPv6 Neighbor solicitation fe80::a00:20ff:fee9:2d27 -> fe80::a00:20ff:fecd:4375 ICMPv6 Neighbor solicitation fe80::a00:20ff:fee9:2d27 -> fe80::a00:20ff:fecd:4375 ICMPv6 Neighbor solicitation fe80::a00:20ff:febb:e09 -> ff02::9 RIPng R (11 destinations) fe80::a00:20ff:fee9:2d27 -> ff02::1:ffcd:4375 ICMPv6 Neighbor solicitation |
Oracle Solaris permet à une interface unique de disposer de plusieurs adresses IP. Par exemple, certaines fonctionnalités telles que la fonctionnalité IPMP (multiacheminement sur réseau IP) permettent la connexion de plusieurs cartes d'interface réseau (NIC, network interface card) sur la même couche de liaison IP. Cette liaison peut être associée à une ou plusieurs adresses IP. Les interfaces des systèmes IPv6 possèdent également une adresse IPv6 lien-local, au moins une adresse de routage IPv6 ainsi qu'une adresse IPv4 pour au moins une interface.
Lorsque le système génère une transaction, une application envoie un appel vers le socket getaddrinfo. getaddrinfo détecte les adresses susceptibles d'être utilisées sur le système de destination. Le noyau établit alors l'ordre de priorité de cette liste afin de déterminer la destination appropriée pour le paquet. Ce processus est appelé classement des adresses de destination. Le noyau Oracle Solaris sélectionne le format approprié pour l'adresse source en fonction de l'adresse de destination déterminée pour le paquet. Ce processus est appelé sélection des adresses. Pour plus d'informations sur le classement des adresses de destination, reportez-vous à la page de manuel getaddrinfo(3SOCKET).
Le processus de sélection des adresses par défaut doit s'effectuer sur les systèmes IPv4 uniquement ainsi que sur les systèmes double pile IPv4/IPv6. Dans la plupart des cas, il n'est pas nécessaire de modifier les mécanismes de sélection des adresses par défaut. Toutefois, vous devrez peut-être modifier l'ordre de priorité des formats d'adresse de manière à prendre en charge la fonctionnalité IPMP ou à préférer les formats d'adresse 6to4, par exemple.
La section ci-dessous décrit la procédure de modification de la table des règles de sélection d'adresses. Pour plus d'informations concernant la sélection des adresses IPv6 par défaut, reportez-vous à la section Commande ipaddrsel.
La table des règles de sélection d'adresses IPv6 doit uniquement être modifiée sur la base des motifs décrits dans la tâche suivante. Les erreurs de définition de la table des règles risquent d'entraîner des problèmes de fonctionnement du réseau. Veillez à enregistrer une copie de sauvegarde de la table des règles, comme indiqué à la procédure suivante.
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Consultez la table de stratégie de sélection d'adresse IPv6 actuelle.
# ipaddrsel # Prefix Precedence Label ::1/128 50 Loopback ::/0 40 Default 2002::/16 30 6to4 ::/96 20 IPv4_Compatible ::ffff:0.0.0.0/96 10 IPv4 |
Effectuez une copie de la table des règles de sélection d'adresses par défaut.
# cp /etc/inet/ipaddrsel.conf /etc/inet/ipaddrsel.conf.orig |
Apportez les modifications souhaitées au fichier /etc/inet/ipaddrsel.conf dans un éditeur de texte.
Utilisez la syntaxe suivante pour les entrées de fichier /etc/inet/ipaddrsel :
prefix/prefix-length precedence label [# comment ] |
Les exemples ci-dessous illustrent les modifications susceptibles d'être apportées le plus souvent à la table des règles :
Définition des adresses 6to4 sur la priorité la plus élevée :
2002::/16 50 6to4 ::1/128 45 Loopback |
Le format d'adresse 6to4 dispose dorénavant de la plus haute priorité (50). Loopback, qui disposait auparavant d'une priorité de 50, dispose dorénavant d'une priorité de 45. Les autres formats d'adresse restent inchangés.
Définition d'une adresse source spécifique pour les communications avec une adresse de destination donnée :
::1/128 50 Loopback 2001:1111:1111::1/128 40 ClientNet 2001:2222:2222::/48 40 ClientNet ::/0 40 Default |
Ce type de configuration s'utilise notamment pour les hôtes associés à une seule interface physique. Dans cet exemple, l'adresse source 2001:1111:1111::1/128 est définie en tant qu'adresse prioritaire pour les paquets adressés aux destinations du réseau 2001:2222:2222::/48. L'adresse source 2001:1111:1111::1/128 est associée à la priorité 40, priorité supérieure à celle des autres formats d'adresse configurés pour l'interface.
Préférence des adresses IPv4 par rapport aux adresses IPv6 :
::ffff:0.0.0.0/96 60 IPv4 ::1/128 50 Loopback . . |
La priorité par défaut du format IPv4 ::ffff:0.0.0.0/96 passe de 10 à 60, soit la priorité la plus élevée de la table.
Chargez la table de règles modifiée dans le noyau.
ipaddrsel -f /etc/inet/ipaddrsel.conf |
Si la table des règles modifiée génère des erreurs, restaurez la table des règles de sélection des adresses IPv6 par défaut.
# ipaddrsel -d |
Les modifications apportées au fichier /etc/inet/ipaddrsel.conf sont conservées lors des sessions suivantes. Si vous souhaitez modifier la table des règles uniquement pour la session en cours, effectuez la procédure suivante.
Connectez-vous en tant qu'administrateur principal ou superutilisateur.
Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.
Copiez le contenu du fichier /etc/inet/ipaddrsel dans le fichier nom-fichier, où nom-fichier désigne le nom de votre choix.
# cp /etc/inet/ipaddrsel filename |
Apportez les modifications souhaitées à la table des règles dans le fichier nom-fichier.
Chargez la table de règles modifiée dans le noyau.
# ipaddrsel -f filename |
Le noyau utilise la nouvelle table des règles jusqu'au prochain redémarrage du système.
Ce chapitre apporte des solutions aux problèmes se produisant couramment sur les réseaux. Il aborde les sujets suivants :
Dans Solaris 10 7/07, le fichier /etc/inet/ipnodes devient obsolète. Comme expliqué dans chaque procédure, utilisez le chemin /etc/inet/ipnodes uniquement pour les versions précédentes de Oracle Solaris 10.
La non-communication entre des hôtes d'un réseau constitue l'un des signes annonciateurs d'un problème de réseau. S'il est impossible de communiquer avec un hôte qui vient d'être ajouté au réseau, le problème provient probablement des fichiers de configuration. La carte d'interface réseau peut également être en cause. En effet, si un seul hôte pose problème, la carte d'interface réseau est peut-être défectueuse. Si plusieurs hôtes du réseau peuvent communiquer entre eux, mais pas avec d'autres réseaux, le routeur ou un autre réseau peut être à l'origine du problème.
La commande ifconfig vous permet d'obtenir des informations sur les interfaces réseau. Exécutez la commande netstat pour afficher les tables de routage et les statistiques de protocoles. Les programmes tiers de diagnostic de réseau fournissent divers outils de dépannage. Pour plus d'informations, reportez-vous à la documentation de ces produits.
D'autres causes moins évidentes peuvent réduire les performances du réseau. Par exemple, l'outil ping permet de quantifier des problèmes tels que la perte de paquets par un hôte.
Pour résoudre un problème de réseau, vous pouvez réaliser un certain nombre de vérifications logicielles et dépanner les problèmes élémentaires liés aux logiciels.
Sur le système local, connectez-vous en tant qu'administrateur réseau ou superutilisateur.
Les rôles contiennent des autorisations et des commandes privilégiées. Pour de plus amples informations sur les rôles, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.
Pour obtenir des informations sur le réseau, exécutez la commande netstat.
Pour obtenir de plus amples informations sur la commande netstat et sur sa syntaxe, reportez-vous à la section Contrôle du statut du réseau à l'aide de la commande netstat ainsi qu'à la page de manuel netstat(1M).
Vérifiez la base de données hosts (ainsi que la base de données ipnodes si vous exécutez Solaris 10 11/06 ou une version précédente avec IPv6) et assurez-vous que les entrées sont correctes et actuelles.
Pour plus d'informations sur la base de données /etc/inet/hosts, reportez-vous à la section Base de données hosts ainsi qu'à la page de manuel hosts(4) Pour plus d'informations sur la base de données /etc/inet/ipnodes, reportez-vous à la section Base de données ipnodes ainsi qu'à la page de manuel ipnodes(4).
Si vous exécutez le protocole RARP (Reverse Address Resolution Protocol), vérifiez les adresses Ethernet de la base de données ethers et assurez-vous que les entrées sont correctes et actuelles.
Essayez de vous connecter à l'hôte local au moyen de la commande telnet.
Pour obtenir de plus amples informations sur la commande telnet et sur sa syntaxe, reportez-vous à la page de manuel telnet(1).
Assurez-vous que le démon réseau inetd est en cours d'exécution.
# ps -ef | grep inetd
La sortie suivante permet de vérifier que le démon inetd est en cours d'exécution :
root 57 1 0 Apr 04 ? 3:19 /usr/sbin/inetd -s |
Si le protocole IPv6 est activé sur le réseau, assurez-vous que le démon in.ndpd est en cours d'exécution :
# ps -ef | grep in.ndpd |
La sortie suivante permet de vérifier que le démon in.ndpd est en cours d'exécution :
root 123 1 0 Oct 27 ? 0:03 /usr/lib/inet/in.ndpd |
Cette section décrit les problèmes que vous pouvez rencontrer lors du déploiement de IPv6 sur votre site. Pour toute question liée aux tâches de planification réelles, reportez-vous au Chapitre 4Planification d'un réseau IPv6 (tâches).
Si votre équipement ne peut pas être mis à niveau, vous devrez vous procurer un équipement compatible avec IPv6. Lisez attentivement la documentation du fabricant afin de connaître les procédures de prise en charge spécifiques à l'équipement.
Certains routeurs IPv4 ne peuvent pas être mis à niveau vers IPv6. Si votre topologie se trouve dans cette situation, raccordez un routeur IPv6 au routeur IPv4. Vous pourrez alors créer un tunnel sur le routeur IPv4 partant du routeur IPv6. Pour une description des tâches de configuration des tunnels, reportez-vous à la section Tâches de configuration de tunnels pour la prise en charge d'IPv6 (liste des tâches).
Vous pouvez rencontrer les problèmes suivants lors de la préparation des services au protocole IPv6 :
Certaines applications préparées pour IPv6 ne prennent pas en charge IPv6 par défaut. Vous devez activer IPv6 sur ces applications pour que la prise en charge soit effective.
Des problèmes peuvent survenir sur un serveur exécutant plusieurs types de services (certains ne prenant en charge qu'IPv4, d'autres prenant en charge IPv4 et IPv6). En effet, certains clients nécessitent l'utilisation de ces deux types de services, ce qui peut semer la confusion au niveau du serveur.
Si vous envisagez de déployer IPv6 sur votre réseau alors que votre FAI actuel ne prend pas en charge l'adressage IPv6, vous pouvez remplacer votre FAI actuel ou opter pour l'un des choix suivants :
Louer un FAI fournissant au site une seconde ligne dédiée aux communications IPv6. Cette solution est onéreuse.
Acquérir un FAI virtuel. Les FAI virtuels fournissent un accès IPv6 sans connexion physique. La connexion s'effectue de fait par le biais d'un tunnel reliant le FAI virtuel et le site à travers le FAI IPv4.
Créer un tunnel 6to4 vers d'autres sites IPv6 à travers le FAI actuel. Configurez l'adresse IPv4 enregistrée du routeur 6to4 en tant qu'entité topologique publique de l'adresse IPv6.
De par sa nature, un tunnel reliant un routeur 6to4 à un routeur relais 6to4 ne constitue pas une connexion sécurisée. Les problèmes de sécurité suivants sont inhérents à ce type de tunnel :
Les routeurs relais 6to4 encapsulent et décapsulent des paquets, mais ne vérifient pas leur contenu.
La mystification d'adresses est l'un des problèmes majeurs des tunnels sur routeurs relais 6to4. En effet, lorsque le routeur 6to4 reçoit des données du trafic entrant, il est incapable de faire correspondre l'adresse IPv4 du routeur relais et l'adresse IPv6 de la source. L'adresse de l'hôte IPv6 peut alors être facilement mystifiée. Il en va de même pour l'adresse du routeur relais 6to4.
Par défaut, il n'existe aucun mécanisme de validation entre le routeur 6to4 et le routeur relais 6to4. Un routeur 6to4 ne peut donc pas déterminer si le routeur relais 6to4 est digne de confiance ou s'il est légitime. Une relation de confiance doit exister entre la source 6to4 et la destination IPv6 pour que ces deux sites ne s'exposent pas à d'éventuelles attaques.
Tous les problèmes de sécurité inhérents aux routeurs relais 6to4, y compris ceux cités précédemment, sont expliqués dans le brouillon Internet intitulé Security Considerations for 6to4. D'une manière générale, n'activez la prise en charge des routeurs relais 6to4 que dans l'un des cas suivants :
Votre site 6to4 tente de communiquer avec un réseau IPv6 de confiance privé. Par exemple, activez la prise en charge du routeur relais 6to4 sur un réseau universitaire constitué de sites 6to4 isolés et de sites IPv6 natifs.
Il est essentiel que votre site 6to4 communique avec certains hôtes IPv6 natifs.
Vous avez implémenté les modèles de vérification et de validation suggérés dans le brouillon Internet intitulé Security Considerations for 6to4.
Les bogues suivants concernent la configuration 6to4 :
4709338 – Implémentation RIPng nécessaire à la reconnaissance des routes statiques
4152864 – Fonctionnement de la configuration de deux tunnels avec la même paire tsrc/tdst
Le problème suivant se produit sur les sites 6to4 équipés de routeurs internes au routeur de bordure 6to4. Lors de la configuration de la pseudointerface 6to4, la route statique 2002::/16 est automatiquement ajoutée à la table de routage du routeur 6to4. Ce bogue (ID 4709338) indique que le protocole de routage Oracle Solaris RIPng empêche la publication de la route statique sur le site 6to4.
Deux opérations permettent de résoudre ce problème.
L'une consiste à ajouter la route statique 2002::/16 aux tables de routage de tous les routeurs intrasites du site 6to4.
L'autre consiste à utiliser un autre protocole de routage que RIPng sur le routeur interne au site 6to4.
Ce bogue (ID 4152864) décrit les problèmes liés à la configuration de deux tunnels avec la même adresse source de tunnel qui peuvent gravement affecter la configuration des tunnels 6to4.
Vous ne devez pas configurer un tunnel 6to4 et un tunnel automatique (atun) avec la même adresse source de tunnel. Pour plus d'informations sur les tunnels automatiques et la commande atun, reportez-vous à la page de manuel tun(7M).
Ce chapitre fournit des informations de référence sur les fichiers de configuration réseau pour les réseaux TCP/IP, notamment les types de réseau, leur objectif et le format d'entrée des fichiers. Les bases de données réseau existantes sont également décrites en détails. En outre, ce chapitre explique comment la structure des adresses IPv4 est définie à partir de classifications réseau et de numéros de sous-réseaux.
Le présent chapitre contient les informations suivantes :
Dans Solaris 10 7/07, le fichier /etc/inet/ipnodes devient obsolète. Comme expliqué dans chaque procédure, utilisez le chemin /etc/inet/ipnodes uniquement pour les versions précédentes de Oracle Solaris 10.
Chaque système du réseau obtient ses informations de configuration TCP/IP des fichiers de configuration TCP/IP et bases de données réseau ci-dessous :
fichier /etc/hostname.interface ;
fichier /etc/nodename ;
fichier /etc/defaultdomain ;
fichier /etc/defaultrouter (facultatif) ;
base de données hosts ;
dans Solaris 10 11/06 et les versions antérieures, base de données ipnodes ;
base de données netmasks (facultatif).
Lors de l'installation, le programme d'installation de Oracle Solaris crée ces fichiers. Vous pouvez également les modifier manuellement, comme indiqué dans cette section. Les bases de données réseau hosts et netmasks sont lues par les services de noms disponibles sur les réseaux Oracle Solaris. Le concept de base de données réseau est décrit à la section Bases de données réseau et fichier nsswitch.conf Dans Solaris 10 11/06 et les versions antérieures, pour plus d'informations sur le fichier ipnodes, reportez-vous à la section Base de données ipnodes.
Ce fichier définit les interfaces réseau physiques sur l'hôte local. Au moins un fichier /etc/hostname.interface doit exister sur le système local. Le programme d'installation de Oracle Solaris crée un fichier /etc/hostname.interface pour la première interface détectée lors de l'installation. Cette interface possède généralement le plus petit numéro de périphérique, par exemple eri0. Elle constitue l'interface réseau principale. Si le programme d'installation détecte d'autres interfaces, vous pouvez également les configurer au cours du processus d'installation.
Si vous créez d'autres fichiers de nom d'hôte pour la même interface, ces fichiers doivent également suivre le format de nom hostname.[0-9]*, par exemple : hostname.qfe0.a123. Des noms tels que hostname.qfe0.bak ou hostname.qfe0.old ne sont pas valides et seront ignorés par les scripts pendant l'initialisation du système.
Une interface ne doit contenir qu'un seul fichier de nom d'hôte correspondant. Si vous créez un autre fichier de nom d'hôte pour une interface avec un nom de fichier valide, tels que /etc/hostname.qfe et /etc/hostname.qfe.a123 , les scripts d'initialisation tenteront de configurer les données en référençant le contenu des deux fichiers de nom d'hôte et cela peut générer des erreurs. Pour éviter ce genre d'erreurs, indiquez un nom de fichier non valide pour le fichier de nom d'hôte à ne pas utiliser dans la configuration.
Si vous ajoutez une interface réseau supplémentaire au système après l'installation, vous devez créer un fichier /etc/hostname.interface pour cette interface, comme indiqué à la section Configuration d'une interface physique après l'installation du système. En outre, pour que le logiciel Oracle Solaris reconnaisse et utilise la nouvelle interface réseau, le pilote de périphérique de l'interface doit être chargé dans le répertoire correspondant. Reportez-vous à la documentation accompagnant la nouvelle interface réseau pour obtenir le nom d'interface adéquat et les instructions du pilote de périphérique.
Le fichier /etc/hostname.interface de base contient une entrée : l'adresse IPv4 ou le nom d'hôte associé à l'interface réseau. L'adresse IPv4 peut s'exprimer au format décimal avec points classique ou en notation CIDR. Si l'entrée du fichier /etc/hostname.interface est un nom d'hôte, celui-ci doit également se trouver dans le fichier /etc/inet/hosts.
Par exemple, soit smc0 l'interface réseau principale d'un système appelé tenere. L'entrée du fichier /etc/hostname.smc0 peut être une adresse IPv4 selon la numérotation décimale avec points ou en notation CIDR, ou le nom d'hôte tenere.
IPv6 définit les interfaces réseau à l'aide du fichier /etc/hostname6.interface. Pour plus d'informations, reportez-vous à la section Fichier de configuration d'interface IPv6.
Ce fichier doit contenir une entrée : le nom d'hôte du système local. Par exemple, sur le système timbuktu, le fichier /etc/nodename contiendrait l'entrée timbuktu.
Ce fichier doit contenir une entrée : le nom complet du domaine administratif auquel appartient le réseau de l'hôte local. Vous pouvez fournir ce nom au programme d'installation Oracle Solaris ou modifier le fichier plus tard. Pour plus d'informations sur les domaines de réseau, reportez-vous au System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .
Ce fichier peut contenir une entrée pour chaque routeur directement connecté au réseau. L'entrée doit correspondre au nom de l'interface réseau servant de routeur entre les réseaux. La présence du fichier /etc/defaultrouter indique que le système prend en charge le routage statique.
La base de données hosts contient les adresses IPv4 et noms d'hôtes des systèmes résidant sur le réseau. Si vous utilisez le service de noms NIS ou DNS, ou le service d'annuaire LDAP, la base de données hosts est mise à jour dans une base de données conçue pour les informations d'hôte. Par exemple, sur un réseau exécutant NIS, la base de données hosts est mise à jour dans le fichier hostsbyname.
Si vous utilisez des fichiers locaux en tant que service de noms, la base de données hosts est mise à jour dans le fichier /etc/inet/hosts. Ce fichier contient les noms d'hôtes et les adresses IPv4 de l'interface réseau principale, des autres interfaces réseau connectées au système et toute autre adresse réseau que le système doit vérifier.
Pour assurer la compatibilité avec les systèmes d'exploitation BSD, le fichier /etc/hosts définit un lien symbolique vers /etc/inet/hosts.
Le fichier /etc/inet/hosts utilise la syntaxe de base ci-dessous. Pour obtenir les informations complètes relatives à cette syntaxe, reportez-vous à la page de manuel hosts(4).
adresse-IPv4 nom-hôte [pseudo] [#commentaire]
Contient l'adresse IPv4 de chaque interface que l'hôte local doit reconnaître.
Contient le nom d'hôte attribué au système lors de la configuration, ainsi que les noms d'hôtes attribués aux interfaces réseau supplémentaires que l'hôte local doit reconnaître.
Champ facultatif contenant un pseudo pour l'hôte.
Champ de commentaire facultatif.
Lors de l'exécution du programme d'installation Oracle Solaris sur un système, le programme configure le fichier /etc/inet/hosts initial. Ce fichier contient les entrées minimales requises par l'hôte local. Les entrées incluent l'adresse loopback, l'adresse IPv4 de l'hôte et le nom d'hôte.
Par exemple, le programme d'installation Oracle Solaris peut créer le fichier /etc/inet/hosts suivant pour le système tenere indiqué dans la Figure 5–1 :
127.0.0.1 localhost loghost #loopback address 192.168.200.3 tenere #host name |
Dans l'Exemple 10–1, l'adresse IPv4 127.0.0.1 constitue l'adresse loopback. L'adresse loopback est l'interface réseau réservée utilisée par le système local pour permettre les communications entre processus. L'hôte utilise cette adresse pour s'envoyer des paquets à lui-même. La commande ifconfig utilise l'adresse loopback pour la configuration et les tests, comme expliqué à la section Contrôle de la configuration de l'interface avec la commande ifconfig. Tout système du réseau TCP/IP doit utiliser l'adresse IP 127.0.0.1 pour le loopback IPv4 sur l'hôte local.
L'adresse IPv4 192.168.200.1 et le nom tenere constituent l'adresse et le nom d'hôte du système local. Ils sont attribués à l'interface réseau principale du système.
Certains systèmes possèdent plusieurs interfaces réseau, car ils constituent des routeurs ou des hôtes multiréseau. Chaque interface réseau connectée au système requiert sa propre adresse IP et le nom associé. À l'installation, vous devez configurer l'interface réseau principale. Si un système présente plusieurs interfaces lors de l'installation, le programme d'installation Oracle Solaris vous invite à configurer également ces interfaces supplémentaires. Vous pouvez configurer les interfaces supplémentaires ou une partie d'entre elles à l'installation, ou les configurer manuellement plus tard.
Une fois l'installation de Oracle Solaris terminée, vous pouvez configurer des interfaces supplémentaires pour un routeur ou un hôte multiréseau en ajoutant ces informations au fichier /etc/inet/hosts du système. Pour de plus amples informations sur la configuration de routeurs et d'hôtes multiréseau, reportez-vous aux sections Configuration d'un routeur IPv4 et Configuration des hôtes multiréseaux.
L'Exemple 10–2 présente le fichier /etc/inet/hosts du système timbuktu illustré sur la Figure 5–1.
127.0.0.1 localhost loghost 192.168.200.70 timbuktu #This is the local host name 192.168.201.10 timbuktu-201 #Interface to network 192.9.201 |
Avec ces deux interfaces, timbuktu connecte les réseaux 192.168.200 et 192.168.201 en tant que routeur.
Les services de noms NIS et DNS, et le service d'annuaire LDAP mettent à jour les adresses et les noms d'hôtes sur un ou plusieurs serveurs. Ces serveurs mettent à jour les bases de données hosts contenant les informations de tous les hôtes et routeurs (le cas échéant) du réseau du serveur. Pour de plus amples informations sur ces services, reportez-vous au System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Sur un réseau utilisant des fichiers locaux pour le service de noms, les systèmes s'exécutant en mode de fichiers locaux consultent leurs fichiers /etc/inet/hosts individuels pour connaître les adresses IPv4 et noms d'hôtes des autres systèmes du réseau. Par conséquent, les fichiers /etc/inet/hosts de ces systèmes doivent contenir les informations suivantes :
adresse loopback ;
adresse IPv4 et nom d'hôte du système local (interface réseau principale) ;
adresse IPv4 et nom d'hôte des interfaces réseau supplémentaires connectées à ce système, le cas échéant ;
adresses IPv4 et noms d'hôtes des hôtes résidant sur le réseau local ;
adresses IPv4 et noms d'hôtes de tout routeur que ce système doit connaître, le cas échéant ;
adresse IPv4 de tout système auquel le système doit faire référence via son nom d'hôte.
La Figure 10–1 présente le fichier /etc/inet/hosts du système tenere. Ce système s'exécute en mode fichiers locaux. Comme vous pouvez le constater, le fichier contient les adresses IPv4 et noms d'hôtes de tous les systèmes du réseau 192.9.200. Il contient également l'adresse IPv4 et le nom d'interface timbuktu-201. Cette interface connecte le réseau 192.9.200 au réseau 192.9.201.
Un système configuré en tant que client réseau consulte le fichier local /etc/inet/hosts pour connaître son adresse loopback et son adresse IPv4.
La base de données ipnodes n'est plus incluse dans les versions supérieures à Solaris 10 11/06. Dans ces versions, les fonctions IPv6 de ipnodes migrent vers la base de données hosts.
Le fichier /etc/inet/ipnodes conserve les adresses IPv4 et IPv6. En outre, vous pouvez enregistrer les adresses IPv4 en numérotation décimale avec points classique ou selon la notation CIDR. Ce fichier sert de base de données locale et associe les noms des hôtes à leurs adresses IPv4 et IPv6. N'enregistrez pas les noms d'hôtes ni leurs adresses dans des fichiers statiques, par exemple /etc/inet/ipnodes. Toutefois, à des fins de test, enregistrez les adresses IPv6 dans un fichier de la même façon que les adresses IPv4 sont enregistrées dans /etc/inet/hosts. Le fichier ipnodes applique les mêmes conventions de format que le fichier hosts. Pour de plus amples informations sur /etc/inet/hosts, reportez-vous à la section Base de données hosts. Le fichier ipnodes est décrit dans la page de manuel ipnodes(4).
Les applications compatibles IPv6 font appel à la base de données /etc/inet/ipnodes. La base de données /etc/hosts existante, contenant exclusivement des adresses IPv4, reste identique afin de servir les applications existantes. Si la base de données ipnodes n'existe pas, les applications IPv6 font appel à la base de données hosts existante.
Pour ajouter des adresses IPv4, insérez-les à la fois dans les fichiers hosts et ipnodes. Insérez les adresses IPv6 dans le fichier ipnodes uniquement.
Groupez les adresses de nom d'hôte selon le nom d'hôte, comme indiqué dans cet exemple.
# # Internet IPv6 host table # with both IPv4 and IPv6 addresses # ::1 localhost 2001:db8:3b4c:114:a00:20ff:fe78:f37c farsite.com farsite farsite-v6 fe80::a00:20ff:fe78:f37c farsite-11.com farsitell 192.168.85.87 farsite.com farsite farsite-v4 2001:db8:86c0:32:a00:20ff:fe87:9aba nearsite.com nearsite nearsite-v6 fe80::a00:20ff:fe87:9aba nearsite-11.com nearsitell 10.0.0.177 nearsite.com nearsite nearsite-v4 loghost |
La base de données netmasks ne doit être modifiée à la configuration du réseau que si vous avez configuré la création de sous-réseaux sur le réseau. La base de données netmasks est constituée d'une liste de réseaux et des masques de sous-réseau associés.
Lors de la création de sous-réseaux, chaque nouveau réseau doit constituer un réseau physiquement distinct. Vous ne pouvez pas appliquer la création de sous-réseaux à un réseau physique unique.
La création de sous-réseaux permet d'optimiser l'espace d'adressage IPv4 32 bits limité et de réduire la taille des tables de routage d'un interréseau étendu. Quelle que soit la classe d'adresse, la création de sous-réseaux permet d'allouer une partie de l'espace d'adressage hôte à des adresses réseau, afin d'utiliser des réseaux supplémentaires. La partie de l'espace d'adressage hôte allouée aux nouvelles adresses réseau est appelée numéro de sous-réseau.
Outre une utilisation plus efficace de l'espace d'adressage IPv4, la création de sous réseau offre de nombreux avantages administratifs. Le routage peut devenir très compliqué lorsque les réseaux deviennent nombreux. Dans une petite organisation, par exemple, un numéro de classe C peut être attribué à chaque réseau local. Lorsque l'organisation s'étend, l'administration de nombreux numéros de réseau peut devenir complexe. Il s'avère alors judicieux d'allouer quelques numéros de réseau de classe B à chaque grande division de l'organisation. Par exemple, allouez un réseau de classe B au service Ingénierie, un réseau de classe B au service Opérations, etc. Ensuite, vous pouvez diviser chaque réseau de classe B en réseaux supplémentaires, à l'aide des numéros de réseau supplémentaires, obtenus grâce à la création de sous-réseaux. Cette division permet également de réduire le volume d'informations de routage transférées entre les routeurs.
Lors de la création de sous-réseaux, vous devez sélectionner un masque de réseau englobant le réseau. Le masque de réseau détermine les bits de l'espace d'adressage hôte qui représentent le numéro de sous-réseau et les bits qui représentent le numéro d'hôte. Pour rappel, l'adresse IPv4 complète est constituée de 32 bits. Selon la classe d'adresse, de 8 à 24 bits sont disponibles pour représenter l'espace d'adressage hôte. Le masque de réseau est spécifié dans la base de données netmasks.
Si vous souhaitez utiliser des sous-réseaux, définissez le masque de réseau avant de configurer TCP/IP. Si vous souhaitez installer le système d'exploitation au sein d'une configuration réseau, vous devez indiquer le masque du réseau au programme d'installation Oracle Solaris.
Comme décrit à la section Conception d'un schéma d'adressage IPv4, les adresses IP 32 bits se décomposent en une partie réseau et une partie hôte. Les 32 bits sont divisés en 4 octets. Chaque octet est attribué au numéro de réseau ou au numéro d'hôte, selon la classe à laquelle appartient le réseau.
Par exemple, dans une adresse IPv4 de classe B, les 2 octets de gauche sont attribués au numéro de réseau, tandis que les 2 octets de droite sont attribués au numéro d'hôte. Dans l'adresse IPv4 de classe B 172.16.10, vous pouvez attribuer les 2 octets de droite aux hôtes.
Pour implémenter la création de sous-réseaux, vous devez appliquer aux adresses de sous-réseau une partie des bits correspondant aux octets attribués au numéro d'hôte. Par exemple, un espace d'adressage hôte de 16 bits assure l'adressage de 65 534 hôtes. Si vous appliquez le troisième octet aux adresses de sous-réseau et le quatrième octet aux adresses d'hôte, vous pouvez adresser jusqu'à 254 réseaux, contenant chacun 254 hôtes maximum.
Les bits des octets d'adresse hôte appliqués aux adresses de sous-réseau et ceux qui sont appliqués aux adresses d'hôte sont déterminés par un masque de sous-réseau. Les masques de sous-réseau permettent de sélectionner des bits à partir de tout octet pour les utiliser en tant qu'adresses de sous-réseau. Les bits de masque de réseau doivent être contigus, mais ils n'ont pas besoin de s'aligner sur les limites d'octet.
Le masque de réseau peut s'appliquer à une adresse IPv4 à l'aide de l'opérateur de bit logique AND. Cette opération permet de sélectionner les positions du numéro de réseau et du numéro de sous-réseau dans l'adresse.
Les masques de réseau peuvent s'exprimer à l'aide de leur représentation binaire. Vous pouvez effectuer la conversion de notation binaire à décimale à l'aide d'une calculatrice. L'exemple suivant présente les formes binaires et décimales du masque de réseau.
Si le masque de réseau 255.255.255.0 est appliqué à l'adresse IPv4 172.16.41.101, le résultat est l'adresse IPv4 de 172.16.41.0.
172.16.41.101 & 255.255.255.0 = 172.16.41.0
En notation binaire, l'opération est la suivante :
10000001.10010000.00101001.01100101 (adresse IPv4)
AND
11111111.11111111.11111111.00000000 (masque de réseau)
À présent, le système recherche le numéro de réseau 172.16.41 au lieu du numéro de réseau 172.16. Si le réseau possède le numéro 172.16.41, il correspond à ce que le système recherche. Comme vous pouvez attribuer jusqu'à 254 valeurs au troisième octet de l'espace d'adressage IPv4, la création de sous-réseaux permet de créer un espace d'adressage pour 254 réseaux alors que, auparavant, l'espace n'était disponible que pour un réseau.
Si vous fournissez l'espace d'adressage à deux réseaux supplémentaires seulement, vous pouvez utiliser le masque de sous-réseau suivant :
255.255.192.0
Le résultat de ce masque de réseau est le suivant :
11111111.11111111.1100000.00000000
Ce résultat laisse encore 14 bits disponibles pour les adresses hôte. Comme tous les 0 et les 1 sont réservés, au moins 2 bits doivent être réservés pour le numéro d'hôte.
Si le réseau exécute NIS ou LDAP, les serveurs de ces services de noms mettent à jour les bases de données netmasks. Pour les réseaux utilisant des fichiers locaux comme service de noms, cette information est enregistrée dans le fichier /etc/inet/netmasks.
Pour assurer la compatibilité avec les systèmes d'exploitation BSD, le fichier /etc/netmasks correspond à un lien symbolique vers /etc/inet/netmasks.
L'exemple suivant présente le fichier /etc/inet/netmasks d'un réseau de classe B.
# The netmasks file associates Internet Protocol (IPv4) address # masks with IPv4 network numbers. # # network-number netmask # # Both the network-number and the netmasks are specified in # “decimal dot” notation, e.g: # # 128.32.0.0 255.255.255.0 192.168.0.0 255.255.255.0 |
Si le fichier /etc/netmasks n'existe pas, créez-le à l'aide d'un éditeur de texte. Utilisez la syntaxe suivante :
network-number netmask-number
Pour des informations plus détaillées, reportez-vous à la page de manuel netmasks(4).
À la création de numéros de masque de réseau, saisissez le numéro de réseau attribué par le FAI ou l'IR (Internet Registry, registre Internet) (et non le numéro de sous-réseau) et le numéro de masque de réseau dans /etc/inet/netmasks. Chaque masque de sous-réseau doit être spécifié sur une ligne distincte.
Exemple :
128.78.0.0 255.255.248.0 |
Vous avez également la possibilité de saisir des noms symboliques correspondant aux numéros de réseau dans le fichier /etc/inet/hosts. Ensuite, vous pouvez utiliser ces noms de réseau au lieu des numéros de réseau en tant que paramètres de commandes.
Le démon inetd lance les services Internet standard à l'initialisation du système et peut redémarrer un service lorsque le système est en cours d'exécution. Le SMF (Service Management Facility, utilitaire de gestion de service) permet de modifier les services Internet standard et d'indiquer au démon inetd de démarrer d'autres services, le cas échéant.
Exécutez les commandes SMF suivantes pour gérer les services démarrés par inetd :
Permet d'effectuer des tâches administratives sur un service, telle que l'activation, la désactivation et le redémarrage. Pour de plus amples informations, reportez-vous à la page de manuel svcadm(1M).
Permet d'effectuer des requêtes relatives au statut d'un service. Pour de plus amples informations, reportez-vous à la page de manuel svcs(1).
Permet d'afficher et modifier les propriétés d'un service. Pour de plus amples informations, reportez-vous à la page de manuel inetadm(1M).
La valeur du champ proto dans le profil inetadm d'un service particulier indique le protocole de couche de transport sur lequel le service s'exécute. Si le service gère exclusivement des requêtes IPv4, le champ proto doit être défini sur tcp, udp ou sctp.
Les instructions d'utilisation des commandes SMF sont fournies à la section SMF Command-Line Administrative Utilities du System Administration Guide: Basic Administration .
Pour une tâche utilisant les commandes SMF afin d'ajouter un service s'exécutant sur SCTP, reportez-vous à la section Ajout de services utilisant le protocole SCTP.
Pour obtenir des informations sur l'ajout de services gérant à la fois des requêtes IPv4 et des requêtes IPv6, reportez-vous à la section Démon de services Internet inetd
Les bases de données réseau sont des fichiers fournissant des informations requises pour configurer le réseau. Les bases de données réseau sont les suivantes :
hosts ;
netmasks ;
base de données ethers ;
bootparams ;
protocols ;
services ;
networks.
À la configuration, vous modifiez les bases de données hosts et netmasks, si le réseau se décompose en sous-réseaux. Deux bases de données réseau, bootparams et ethers, permettent de configurer les systèmes en tant que clients réseau. Les autres bases de données sont employées par le système d'exploitation et requièrent rarement des modifications.
Le fichier nsswitch.conf ne constitue pas une base de données réseau, mais vous devez le configurer avec la base de données réseau adéquate. nsswitch.conf spécifie le service de noms à utiliser pour un système particulier : fichiers locaux, NIS, DNS ou LDAP.
Le format de la base de données réseau dépend du type de service de noms sélectionné pour le réseau. Par exemple, la base de données hosts contient au moins le nom d'hôte et l'adresse IPv4 du système local, ainsi que toute interface réseau directement connectée au système local. Cependant, la base de données hosts peut contenir d'autres adresses IPv4 et noms d'hôtes, selon le type de service de noms utilisé sur le réseau.
Les bases de données réseau s'utilisent comme suit :
Les réseaux employant des fichiers locaux comme service de noms se basent sur des fichiers des répertoires /etc/inet et /etc.
DNS utilise les enregistrements avec des informations d'hôte.
Les fichiers de données et d'initialisation DNS ne correspondent pas exactement aux bases de données réseau.
La figure ci-dessous présente les différentes formes de base de données hosts utilisées par ces services de noms.
Le tableau ci-dessous répertorie les bases de données réseau, ainsi que les fichiers locaux et cartes NIS correspondants.
La base de données ipnodes a été supprimée des versions Oracle Solaris suivant la version 10 11/06.
Base de données réseau |
Fichiers locaux |
Cartes NIS |
---|---|---|
/etc/inet/hosts |
hosts.byaddr hosts.byname |
|
ipnodes |
/etc/inet/ipnodes |
ipnodes.byaddr ipnodes.byname |
/etc/inet/netmasks |
netmasks.byaddr |
|
/etc/ethers |
ethers.byname ethers.byaddr |
|
/etc/bootparams |
bootparams ; |
|
/etc/inet/protocols |
protocols.byname protocols.bynumber |
|
/etc/inet/services |
services.byname |
|
/etc/inet/réseaux |
networks.byaddr networks.byname |
Ce manuel décrit les bases de données réseau telles qu'elles sont perçues par les réseaux utilisant des fichiers locaux pour les services de noms.
Vous trouverez des informations sur la base de données hosts à la section Base de données hosts.
Vous trouverez des informations sur la base de données netmasks à la section Base de données netmasks.
Pour Solaris 10 11/06 et les versions antérieures, vous trouverez des informations sur la base de données ipnodes à la section Base de données ipnodes.
Pour de plus amples informations sur les correspondances de bases de données réseau dans NIS, DNS et LDAP, reportez-vous au System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Le fichier /etc/nsswitch.conf définit l'ordre de recherche des bases de données réseau. Le programme d'installation Oracle Solaris crée un fichier /etc/nsswitch.conf par défaut pour le système local, selon le service de noms indiqué lors de l'installation. Si vous avez sélectionné l'option Aucun, en indiquant les fichiers locaux à utiliser pour le service de noms, le fichier nsswitch.conf obtenu est similaire à l'exemple ci-dessous.
# /etc/nsswitch.files: # # An example file that could be copied over to /etc/nsswitch.conf; # it does not use any naming service. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file contains "switch.so" as a # nametoaddr library for "inet" transports. passwd: files group: files hosts: files networks: files protocols: files rpc: files ethers: files netmasks: files bootparams: files publickey: files # At present there isn't a 'files' backend for netgroup; the # system will figure it out pretty quickly, # and won't use netgroups at all. netgroup: files automount: files aliases: files services: files sendmailvars: files |
La page de manuel nsswitch.conf(4) décrit le fichier en détail. La syntaxe de base est la suivante :
base-de-données service-de-noms-à-rechercher
Le champ base-de-données indique l'un des divers types de bases de données recherchés par le système d'exploitation. Par exemple, le champ peut spécifier une base de données affectant les utilisateurs, telle que passwd ou aliases, ou une base de données réseau. Le paramètre nom-de-service-à-rechercher peut prendre les valeurs files, nis ou nis+ pour les bases de données réseau. La base de données hosts peut également rechercher le service de noms dns. Vous avez également la possibilité de répertorier plusieurs services de noms, par exemple nis+ et files.
Dans l'Exemple 10–5, la seule option de recherche indiquée est files. Par conséquent, outre les informations de base de données réseau, les fichiers résidant dans les répertoires /etc et /etc/inet du système local lui fournissent les informations de sécurité et de montage automatique.
Le répertoire /etc contient le fichier nsswitch.conf créé par le programme d'installation Oracle Solaris. Ce répertoire contient également des fichiers de modèles pour les services de noms suivants :
nsswitch.files ;
nsswitch.nis ;
Pour passer d'un service de noms à un autre, copiez le modèle adéquat dans nsswitch.conf. Vous pouvez également modifier le fichier nsswitch.conf et changer le service de noms par défaut pour rechercher individuellement des bases de données.
Par exemple, sur un réseau exécutant NIS, il peut s'avérer nécessaire de modifier le fichier nsswitch.conf sur les clients du réseau. Le chemin de recherche pour les bases de données bootparams et ethers doit indiquer files comme première option, puis nis. L'exemple suivant présente les chemins de recherche corrects.
# /etc/nsswitch.conf:# . . passwd: files nis group: files nis # consult /etc "files" only if nis is down. hosts: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: files [NOTFOUND=return] nis netmasks: nis [NOTFOUND=return] files bootparams: files [NOTFOUND=return] nis publickey: nis netgroup: nis automount: files nis aliases: files nis # for efficient getservbyname() avoid nis services: files nis sendmailvars: files |
Pour de plus amples informations sur le basculement entre les services de noms, reportez-vous au System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
La base de données bootparams contient des informations utilisées par les systèmes configurés pour s'initialiser en mode client réseau. Vous devez modifier cette base de données si le réseau possède des clients réseau. Les procédures sont expliquées à la section Configuration des clients réseau La base de données est élaborée à partir des informations saisies dans le fichier /etc/bootparams.
La page de manuel bootparams(4) indique la syntaxe complète de cette base de données. La syntaxe de base est la suivante :
nom-système fichier-clés nom-serveur:chemin
Pour chaque système client du réseau, l'entrée peut contenir les informations suivantes : le nom du client, une liste de clés, les noms des serveurs et des chemins. Le premier élément de chaque entrée est le nom du système client. Tous les autres éléments sont facultatifs. Reportez-vous à l'exemple ci-dessous.
myclient root=myserver : /nfsroot/myclient \ swap=myserver : /nfsswap//myclient \ dump=myserver : /nfsdump/myclient |
Dans cet exemple, le terme dump= indique aux hôtes client de ne pas rechercher un fichier de vidage.
Dans la plupart des cas, utilisez l'entrée de caractère générique lors de la modification de la base de données bootparams pour prendre en charge les clients. Cette entrée se présente comme suit :
* root=server:/path dump=:
L'astérisque (*) indique que cette entrée s'applique à tous les clients non spécifiquement nommés dans la base de données bootparams.
La base de données ethers est élaborée à partir d'informations entrées dans le fichier /etc/ethers. Cette base de données associe les noms d'hôtes à leurs adresses MAC (Media Access Control, contrôle d'accès média). Ne créez une base de données ethers que si vous exécutez le démon RARP. En d'autres termes, vous devez créer cette base de données si vous configurez des clients réseau.
RARP utilise le fichier pour mapper les adresses MAC aux adresses IP. Si vous exécutez le démon RARP in.rarpd, vous devez configurer le fichier ethers et mettre à jour ce fichier sur tous les hôtes exécutant le démon afin de refléter les modifications réalisées sur le réseau.
La page de manuel ethers(4) indique la syntaxe complète de cette base de données. La syntaxe de base est la suivante :
MAC-address hostname #comment |
Adresse MAC de l'hôte
Nom officiel de l'hôte
Toute note que vous souhaitez joindre à une entrée du fichier
Le constructeur de l'équipement fournit l'adresse MAC. Si un système n'affiche pas l'adresse MAC lors de l'initialisation du système, reportez-vous aux manuels du matériel pour obtenir de l'aide.
Lors de l'ajout d'entrées à la base de données ethers, assurez-vous que les noms d'hôtes correspondent aux noms principaux dans la base de données hosts et, pour Solaris 10 11/06 et les versions antérieures, la base de données ipnodes, non les pseudos, comme indiqué ci-dessous.
8:0:20:1:40:16 fayoum 8:0:20:1:40:15 nubian 8:0:20:1:40:7 sahara # This is a comment 8:0:20:1:40:14 tenere |
Les autres bases de données réseau ont rarement besoin d'être modifiées.
La base de données networks associe les noms de réseau à des numéros de réseau, afin de permettre à certaines applications d'utiliser et d'afficher les noms au lieu des numéros. La base de données networks se base sur les informations du fichier /etc/inet/réseaux. Ce fichier contient les noms de tous les réseaux auxquels le réseau se connecte via les routeurs.
Le programme d'installation Oracle Solaris configure la base de données networks initiale. Toutefois, si vous ajoutez un réseau à la topologie réseau existante, vous devez mettre à jour cette base de données.
La page de manuel networks(4) contient la syntaxe complète de /etc/inet/networks. Le format de base est le suivant :
network-name network-number nickname(s) #comment |
Nom officiel du réseau
Numéro attribué par le FAI ou l'IR (Internet Registry, registre Internet)
Tout autre nom appliqué au réseau
Toute note que vous souhaitez joindre à une entrée du fichier
Il est impératif de mettre à jour le fichier networks. Le programme netstat utilise les informations de cette base de données pour générer les tables d'état.
Un exemple de fichier /etc/networks est fourni ci-dessous.
#ident "@(#)networks 1.4 92/07/14 SMI" /* SVr4.0 1.1 */ # # The networks file associates Internet Protocol (IP) network # numbers with network names. The format of this file is: # # network-name network-number nicnames . . . # The loopback network is used only for intra-machine communication loopback 127 # # Internet networks # arpanet 10 arpa # Historical # # local networks eng 192.168.9 #engineering acc 192.168.5 #accounting prog 192.168.2 #programming |
La base de données protocols répertorie les protocoles TCP/IP installés sur le système et leurs numéros de protocole. Le programme d'installation Oracle Solaris crée automatiquement la base de données. Ce fichier requiert rarement des tâches d'administration.
La page de manuel protocols(4) décrit la syntaxe de cette base de données. Un exemple de fichier /etc/inet/protocols est fourni ci-dessous.
# # Internet (IP) protocols # ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol tcp 6 TCP # transmission control protocol udp 17 UDP # user datagram protocol |
La base de données services répertorie les noms des services TCP et UDP, ainsi que leurs numéros de port connus. Cette base de données est employée par les programmes faisant appel aux services réseau. La base de données services est créée automatiquement lors de l'installation de Oracle Solaris. En général, cette base de données ne requiert aucune tâche d'administration.
Vous trouverez les informations complètes de syntaxe dans la page de manuel services(4) Un extrait de fichier /etc/inet/services classique est fournit ci-dessous.
# # Network services # echo 7/udp echo 7/tcp echo 7/sctp6 discard 9/udp sink null discard 11/tcp daytime 13/udp daytime 13/tcp netstat 15/tcp ftp-data 20/tcp ftp 21/tcp telnet 23/tcp time 37/tcp timeserver time 37/udp timeserver name 42/udp nameserver whois 43/tcp nickname |
Cette section décrit les protocoles de routage pris en charge par Oracle Solaris 10 : RIP (Routing Information Protocol, protocole d'informations de routage) et RDISC (ICMP Router Discovery, détection de routeur ICMP). RIP et RDISC constituent des protocoles TCP/IP standard. Pour obtenir la liste complète des protocoles de routage de Oracle Solaris 10, reportez-vous au Tableau 5–1 et au Tableau 5–2.
Le protocole RIP est implémenté par le démon de routage in.routed qui démarre à l'initialisation du système. Exécuté sur un routeur avec l'option s, le démon in.routed renseigne la table de routage du noyau en indiquant une route pour chaque réseau accessible et publie l'accessibilité via toutes les interfaces réseau.
Exécuté sur un hôte avec l'option q, le démon in.routed extrait les informations de routage mais ne publie pas l'accessibilité. Sur les hôtes, vous pouvez extraire les informations de routage de deux façons :
Ne spécifiez pas l'indicateur S (S majuscule : mode d'économie d'espace). in.routed construit une table de routage complète exactement de la même manière que sur un routeur.
Spécifiez l'indicateur S. in.routed crée une table de routage minimale pour le noyau, contenant une seule route par défaut pour chaque routeur disponible.
Les hôtes utilisent RDISC pour obtenir les informations de routage des autres routeurs. Par conséquent, lorsque les hôtes exécutent RDISC, les routeurs doivent également exécuter un autre protocole, par exemple RIP, afin d'échanger les informations de routeur.
RDISC est implémenté par le démon in.routed, qui doit s'exécuter à la fois sur les routeurs et sur les hôtes. Sur les hôtes, in.routed utilise RDISC pour détecter les routes par défaut des routeurs qui se publient eux-mêmes via RDISC. Sur les routeurs, in.routed utilise RDISC pour publier les routes par défaut des hôtes sur les réseaux directement connectés. Reportez-vous aux pages de manuel in.routed(1M) et gateways(4).
Les numéros de réseau basés sur les classes ne sont plus disponibles auprès de l'IANA, mais de nombreux réseaux existants restent basés sur les classes.
Cette section décrit en détail les classes de réseau IPv4. Chaque classe utilise l'espace d'adressage IPv4 32 bits de manière différente, en attribuant un nombre de bits spécifique à la partie réseau de l'adresse. Il existe trois classes : classe A, classe B et classe C.
Dans un numéro de réseau de classe A, les 8 premiers bits correspondent à la partie réseau de l'adresse IPv4.” Les 24 bits suivants contiennent la partie hôte de l'adresse IPv4, comme illustré sur la figure suivante.
Les valeurs attribuées au premier octet des numéros de réseau de classe A sont définies dans la plage 0–127. Prenons l'exemple de l'adresse IPv4 75.4.10.4. La valeur 75 du premier octet indique que l'hôte se trouve dans un réseau de classe A. Les octets suivants, 4.10.4, établissent l'adresse de l'hôte. Seul le premier octet d'un numéro de classe A est enregistré auprès de l'IANA. L'utilisation des trois octets suivants est laissée à la discrétion du propriétaire du numéro de réseau. Il existe seulement 127 réseaux de classe A. Chacun de ces numéros peut contenir 16 777 214 hôtes maximum.
Dans un numéro de réseau de classe B, les 16 premiers bits correspondent au numéro de réseau et les 16 bits suivants au numéro d'hôte. Le premier octet d'un numéro de réseau de classe B est défini dans la plage 128–191. Dans le numéro 172.16.50.56, les premiers octets, 172.16, sont enregistrés auprès de l'IANA et constituent l'adresse réseau. Les deux derniers octets, 50.56, correspondent à l'adresse hôte. Ils sont attribués à la discrétion du propriétaire du numéro de réseau. La figure suivante illustre une adresse de classe B.
Les adresses de classe B sont souvent attribuées à des organisations dont les réseaux contiennent de nombreux hôtes.
Dans un numéro de réseau de classe C, les 24 premiers bits correspondent au numéro de réseau et les 8 bits suivants au numéro d'hôte. Les numéros de réseau de classe C conviennent aux réseaux composés d'un petit nombre d'hôtes n'excédant pas 254. Un numéro de réseau de classe C occupe les trois premiers octets d'une adresse IPv4. Seul le quatrième octet est attribué à la discrétion du propriétaire du réseau. La figure ci-dessous illustre les octets d'une adresse de classe C.
Le premier octet d'un numéro de réseau de classe C est défini dans la plage 192–223. Les deuxième et troisième octets sont tous les deux compris entre 1 et 255. 192.168.2.5 est un exemple type d'adresse de classe C. Les trois premiers octets, 192.168.2, constituent le numéro de réseau. Le dernier octet, soit 5 dans cet exemple, correspond au numéro d'hôte.
Ce chapitre contient des informations de référence concernant l'implémentation du protocole IPv6 sous Oracle Solaris 10.
Pour une présentation d'IPv6, reportez-vous au Chapitre 3Présentation d'IPv6. Les tâches de configuration d'un réseau compatible IPv6 sont décrites au Chapitre 7Configuration d'un réseau IPv6 (tâches).
Dans Solaris 10 7/07, le fichier /etc/inet/ipnodes devient obsolète. Comme expliqué dans chaque procédure, utilisez le chemin /etc/inet/ipnodes uniquement pour les versions précédentes de Oracle Solaris 10.
Le Chapitre 3Présentation d'IPv6 présente les formats d'adressage IPv6 les plus fréquents : adresse de site unicast et adresse locale de lien. Cette section apporte des informations complémentaires au Chapitre 3Présentation d'IPv6 et décrit en détail les formats d'adressage suivants :
Si vous envisagez de configurer un tunnel 6to4 à partir du point d'extrémité d'un routeur ou d'un hôte, vous devez publier le préfixe du site 6to4 dans le fichier /etc/inet/ndpd.conf stocké sur le système du point d'extrémité. Les tâches de configuration des tunnels 6to4 sont présentées à la section Procédure de configuration d'un tunnel 6to4.
L'illustration suivante présente les éléments d'un préfixe de site 6to4.
L'illustration suivante présente les éléments d'un préfixe de sous-réseau pour un site 6to4 tel qu'il serait inclus dans le fichier ndpd.conf.
Le tableau suivant explique les éléments constituant un préfixe de sous-réseau 6to4, les longueurs à respecter et leurs définitions.
Élément |
Longueur |
Définition |
---|---|---|
Préfixe |
16 bits |
Étiquette de préfixe 6to4 2002 (0x2002). |
Adresse IPv4 |
32 bits |
Adresse IPv4 unique déjà configurée sur l'interface 6to4. Pour la publication, vous devez spécifier la représentation hexadécimale de l'adresse IPv4 au lieu de celle au format décimal avec points. |
ID de sous-réseau |
16 bits |
ID de sous-réseau unique pour le lien du site 6to4. |
Lorsqu'un hôte IPv6 reçoit le préfixe 6to4 dérivé par le biais d'une publication de routeur, il reconfigure automatiquement une adresse 6to4 dérivée sur une interface. L'adresse possède le format suivant :
prefix:IPv4-address:subnet-ID:interface-ID/64 |
La commande ifconfig -a sur un hôte avec une interface 6to4 produit la sortie suivante :
qfe1:3: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 7 inet6 2002:8192:56bb:9258:a00:20ff:fea9:4521/64 |
Dans cette sortie, l'adresse 6to4 dérivée vient à la suite de inet6.
Ce tableau décrit les éléments d'une adresse dérivée d'un préfixe 6to4, les longueurs à respecter et les informations qu'ils contiennent.
Élément de l'adresse |
Longueur |
Définition |
---|---|---|
prefix |
16 bits |
2002 (préfixe 6to4) |
adresse IPv4 |
32 bits |
8192:56bb (adresse IPv4 au format hexadécimal pour la pseudointerface 6to4 configurée sur le routeur 6to4) |
ID sous-réseau |
16 bits |
9258 (adresse du sous-réseau auquel l'hôte appartient) |
ID interface |
64 bits |
a00:20ff:fea9:4521 (ID de l'interface hôte configurée pour le site 6to4) |
L'adresse IPv6 multicast permet de distribuer des informations ou des services identiques à un groupe défini d'interfaces, appelé groupe multicast. En règle générale, les interfaces des groupes multicast appartiennent à des nœuds différents. Une interface peut faire partie d'un nombre indéfini de groupes multicast. Les paquets envoyés à l'adresse multicast sont distribués à tous les membres du groupe multicast. Par exemple, l'un des rôles des adresses multicast est de diffuser des informations de façon similaire à l'adresse de diffusion IPv4.
Le tableau suivant décrit le format d'une adresse multicast.
Tableau 11–1 Format d'adresse IPv6 multicast
8 bits |
4 bits |
4 bits |
8 bits |
8 bits |
64 bits |
32 bits |
11111111 |
FLGS |
SCOP |
Réservé |
Plen |
Préfixe réseau |
ID de groupe |
La liste suivante récapitule le contenu de chaque champ.
11111111 – Identifie l'adresse en tant qu'adresse multicast.
FLGS – Jeu des quatre indicateurs 0,0,P,T. Les deux premiers doivent être zéro. Le champ P possède l'une des valeurs suivantes :
0 = adresse multicast qui n'est pas assignée en fonction du préfixe réseau
1 = adresse multicast assignée en fonction du préfixe réseau
Si P est défini sur 1, T doit être défini sur 1.
Réservé - Valeur nulle réservée.
Plen - Nombre de bits au niveau du préfixe du site qui identifient le sous-réseau, pour une adresse multicast assignée en fonction du préfixe réseau.
ID de groupe - Identificateur du groupe multicast (permanent ou dynamique).
Pour des informations complètes sur le format multicast, reportez-vous au document RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses.
Certaines adresses IPv6 multicast sont assignées de façon permanente par l'IANA (Internet Assigned Numbers Authority). Par exemple, les adresses multicast de tous les nœuds et de tous les routeurs requises par tous les hôtes et routeurs IPv6. Les adresses IPv6 multicast peuvent également être assignées de façon dynamique. Pour plus d'informations sur l'utilisation appropriée des adresses et des groupes multicast, reportez-vous au document RFC 3307, Allocation Guidelines for IPv6 Multicast Addresses.
Le protocole IPv6 définit un jeu d'en-têtes comprenant l'en-tête IPv6 de base ainsi que les en-têtes d'extension IPv6. La figure suivante illustre les champs qui s'affichent dans l'en-tête IPv6 et l'ordre dans lequel ils apparaissent.
La liste suivante décrit la fonction de chaque champ d'en-tête.
Version – Numéro de version 4 bits du protocole Internet = 6.
Traffic class – Champ de classe de trafic 8 bits.
Flow label – Champ 20 bits.
Payload length – Entier sans signe 16 bits constituant le reste du paquet qui suit l'en-tête IPv6 (en octets).
Next header – Sélecteur 8 bits. Identifie le type d'en-tête qui suit immédiatement l'en-tête IPv6. Utilise la même valeur que le champ du protocole IPv4.
Hop limit – Entier sans signe 8 bits. Décrémentation de 1 par nœud transférant le paquet. Si la valeur du champ est définie sur zéro, le paquet est abandonné.
Source address – 128 bits. L'adresse du premier expéditeur du paquet.
Destination address – 128 bits. L'adresse du destinataire prévu du paquet. Le destinataire prévu n'est pas nécessairement le destinataire s'il existe un en-tête de routage facultatif.
Les options IPv6 sont placées dans des en-têtes d'extension distincts situés, dans un paquet, entre l'en-tête IPv6 et l'en-tête de la couche transport. La plupart des en-têtes d'extension IPv6 ne sont vérifiés ou traités par les routeurs qu'au moment où le paquet arrive à sa destination prévue. Cette fonction améliore de façon remarquable les performances du routeur pour les paquets qui contiennent des options. En effet, sous IPv4, toutes les options présentes dans un paquet doivent être vérifiées par le routeur.
À la différence des options IPv4, les en-têtes d'extension IPv6 possèdent une longueur indéfinie. De plus, le nombre d'options pouvant être incluses dans un paquet n'est pas limité à 40 octets. Grâce à cela et à la manière dont les options IPv6 sont généralement traitées, les options IPv6 peuvent servir à des fonctions difficiles d'utilisation dans IPv4.
Pour une meilleure gestion des en-têtes d'option suivants et du protocole de transport qui suit, les options IPv6 sont toujours des entiers avec une longueur multiple de 8 octets. Ce type d'entier permet de conserver l'alignement des en-têtes suivants.
Les en-têtes d'extension IPv6 ci-dessous sont actuellement définis :
Routing – Routage étendu tel que le routage IPv4 à la source lâche
Fragmentation – Fragmentation et réassemblage
Authentication – Intégrité, authentification et sécurité
Encapsulating Security Payload – Confidentialité
Hop-by-Hop options – Options spéciales requérant un traitement saut par saut
Destination options – Informations facultatives devant être vérifiées par le nœud de destination
Le terme double pile désigne la duplication complète de tous les niveaux de la pile de protocole des applications à la couche réseau. Par exemple, un système qui exécute à la fois les protocoles OSI et TCP/IP représente une duplication complète.
Oracle Solaris est de type double pile. En d'autres termes, Oracle Solaris implémente les protocoles IPv4 et IPv6. Lorsque vous installez ce système d'exploitation, vous pouvez choisir d'activer les protocoles IPv6 dans la couche IP ou d'utiliser les protocoles IPv4 définis par défaut. Le reste de la pile TCP/IP est identique. Par conséquent, les mêmes protocoles de transport, TCP UDP et SCTP, peuvent s'exécuter sur les réseaux IPv4 et IPv6. Les mêmes applications peuvent également s'exécuter sur ces réseaux. La Figure 11–4 illustre le fonctionnement des protocoles IPv4 et IPv6 sous forme de protocoles doubles piles à travers les différentes suites de protocoles Internet.
Dans un environnement à double pile, les sous-jeux des hôtes et des routeurs sont mis à niveau vers IPv4 et IPv6. Cette approche assure l'interopérabilité constante des nœuds mis à niveau avec des nœuds exclusivement IPv4.
Cette section décrit les fichiers, commandes et démons nécessaires au protocole IPv6 sous Oracle Solaris.
Cette section décrit les fichiers de configuration faisant partie de l'implémentation IPv6 :
Le fichier de configuration /etc/inet/ndpd.conf sert à configurer les options utilisées par le démon Neighbor Discovery in.ndpd. Pour un routeur, ndpd.conf sert principalement à configurer le préfixe du site à publier vers le lien. Pour un hôte, ndpd.conf sert à désactiver la configuration automatique des adresses ou à configurer des adresses temporaires.
Le tableau suivant présente les mots-clés utilisés dans le fichier ndpd.conf.
Tableau 11–2 Mots-clés de /etc/inet/ndpd.conf
Variable |
Description |
---|---|
ifdefault |
Spécifie le comportement du routeur pour toutes les interfaces. Utilisez la syntaxe suivante pour définir les paramètres du routeur et les valeurs correspondantes : ifdefault [valeur variable] |
prefixdefault |
Spécifie le comportement par défaut pour la publication du préfixe. Utilisez la syntaxe suivante pour définir les paramètres du routeur et les valeurs correspondantes : prefixdefault [valeur variable] |
if |
Définit les paramètres de l'interface. Utilisez la syntaxe suivante : if interface [valeur variable] |
prefix |
Publie les informations du préfixe par interface. Utilisez la syntaxe suivante : prefix préfixe/longueur interface [valeur variable] |
Dans le fichier ndpd.conf, vous utilisez des mots-clés du tableau avec jeu de variables de configuration du routeur. Ces variables sont définies en détail dans le document RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).
Le tableau suivant répertorie les variables de configuration d'une interface et fournit une brève définition de chacune.
Tableau 11–3 Variables de configuration d'interface du fichier /etc/inet/ndpd.conf
Variable |
Par défaut |
Définition |
---|---|---|
AdvRetransTimer |
0 |
Spécifie la valeur du champ Retrans Timer pour la publication de messages envoyés par le routeur. |
AdvCurHopLimit |
Diamètre actuel du réseau Internet |
Spécifie la valeur à entrer dans le champ Hop Limit pour la publication de messages envoyés par le routeur. |
AdvDefaultLifetime |
3 + MaxRtrAdvInterval |
Spécifie la durée de vie par défaut des publications du routeur. |
AdvLinkMTU |
0 |
Spécifie une valeur d'unité de transmission maximale (MTU) que le routeur doit envoyer. Une valeur nulle indique que ne routeur ne spécifie pas d'options MTU. |
AdvManaged Flag |
False |
Spécifie la valeur à entrer dans l'indicateur de configuration de la gestion des adresses pour la publication du routeur. |
AdvOtherConfigFlag |
False |
Spécifie la valeur à entrer dans l'indicateur de configuration des autres paquets avec état pour la publication du routeur. |
AdvReachableTime |
0 |
Spécifie la valeur du champ Reachable Time pour la publication de messages envoyés par le routeur. |
AdvSendAdvertisements |
False |
Indique si le nœud doit envoyer des publications et répondre aux requêtes du routeur. Vous devez définir explicitement la variable sur TRUE dans le fichier ndpd.conf afin d'activer les fonctions de publication du routeur. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'un routeur compatible IPv6. |
DupAddrDetect Transmits |
1 |
Définit le nombre de messages de requête voisine consécutifs que le protocole Neighbor Discovery doit envoyer lors de la détection d'adresses du nœud local dupliquées. |
MaxRtrAdvInterval |
600 secondes |
Spécifie le temps d'attente maximal lors de l'envoi de publications de multidiffusion non requises. |
MinRtrAdvInterval |
200 secondes |
Spécifie le temps d'attente minimal lors de l'envoi de publications de multidiffusion non requises. |
StatelessAddrConf |
True |
Détermine si le nœud configure son adresse IPv6 par le biais de la configuration automatique des adresses sans état. Si la valeur False est déclarée dans le fichier ndpd.conf, l'adresse doit être configurée manuellement. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'un jeton IPv6 spécifié par l'utilisateur. |
TmpAddrsEnabled |
False |
Indique si une adresse temporaire doit être créée pour toutes les interfaces ou pour une interface particulière d'un nœud. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'une adresse temporaire. |
TmpMaxDesyncFactor |
600 secondes |
Spécifie une valeur aléatoire à soustraire de la variable de durée de vie préférée TmpPreferredLifetime au démarrage de la commande in.ndpd. L'objectif de la variable TmpMaxDesyncFactor est d'éviter que tous les systèmes de votre réseau ne régénèrent leurs adresses temporaires en même temps. TmpMaxDesyncFactor permet de remplacer la limite supérieure par cette valeur. |
TmpPreferredLifetime |
False |
Définit la durée de vie préférée d'une adresse temporaire. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'une adresse temporaire. |
TmpRegenAdvance |
False |
Spécifie à l'avance la durée d'obtention d'une désapprobation pour une adresse temporaire. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'une adresse temporaire. |
TmpValidLifetime |
False |
Définit la durée de vie correcte d'une adresse temporaire. Pour plus d'informations, reportez-vous à la section Procédure de configuration d'une adresse temporaire. |
Le tableau suivant répertorie les variables utilisées pour configurer les préfixes IPv6.
Tableau 11–4 Variables de configuration de préfixe du fichier /etc/inet/ndpd.conf
Variable |
Par défaut |
Définition |
---|---|---|
AdvAutonomousFlag |
True |
Spécifie la valeur à entrer dans le champ Autonomous Flag figurant dans les informations sur le préfixe. |
AdvOnLinkFlag |
True
|
Spécifie la valeur à entrer dans l'indicateur on-link "L-bit" figurant dans les informations sur le préfixe. |
AdvPreferredExpiration |
Non définie |
Spécifie la date d'expiration préférée du préfixe. |
AdvPreferredLifetime |
604 800 secondes |
Spécifie la valeur à entrer pour la durée de vie préférée dans les informations sur le préfixe. |
AdvValidExpiration |
Non définie |
Spécifie la date d'expiration correcte du préfixe. |
AdvValidLifetime |
2 592 000 secondes |
Spécifie la durée de vie correcte du préfixe qui est configurée. |
L'exemple suivant répertorie les mots-clés et les variables de configuration utilisés dans le fichier ndpd.conf. Supprimez le commentaire (#) pour activer la variable.
# ifdefault [variable-value ]* # prefixdefault [variable-value ]* # if ifname [variable-value ]* # prefix prefix/length ifname # # Per interface configuration variables # #DupAddrDetectTransmits #AdvSendAdvertisements #MaxRtrAdvInterval #MinRtrAdvInterval #AdvManagedFlag #AdvOtherConfigFlag #AdvLinkMTU #AdvReachableTime #AdvRetransTimer #AdvCurHopLimit #AdvDefaultLifetime # # Per Prefix: AdvPrefixList configuration variables # # #AdvValidLifetime #AdvOnLinkFlag #AdvPreferredLifetime #AdvAutonomousFlag #AdvValidExpiration #AdvPreferredExpiration ifdefault AdvReachableTime 30000 AdvRetransTimer 2000 prefixdefault AdvValidLifetime 240m AdvPreferredLifetime 120m if qe0 AdvSendAdvertisements 1 prefix 2:0:0:56::/64 qe0 prefix fec0:0:0:56::/64 qe0 if qe1 AdvSendAdvertisements 1 prefix 2:0:0:55::/64 qe1 prefix fec0:0:0:56::/64 qe1 if hme1 AdvSendAdvertisements 1 prefix 2002:8192:56bb:1::/64 qfe0 if hme1 AdvSendAdvertisements 1 prefix 2002:8192:56bb:2::/64 hme1 |
IPv6 utilise le fichier /etc/hostname6.interface au démarrage afin de définir automatiquement les interfaces logiques IPv6. Si vous activez le protocole IPv6 lors de l'installation de Oracle Solaris, le programme d'installation crée un fichier /etc/hostname6.interface pour l'interface réseau principale en plus du fichier /etc/hostname. interface.
Si plus d'une interface physique est détectée lors de l'installation, vous êtes invité à configurer ces interfaces. Le programme d'installation crée des fichiers de configuration d'interface IPv4 physique et des fichiers de configuration d'interface IPv6 logique pour toute interface supplémentaire indiquée.
Tout comme les interfaces IPv4, les interfaces IPv6 peuvent être configurées manuellement après l'installation de Oracle Solaris. Vous pouvez créer un fichier /etc/hostname6. interface pour toute nouvelle interface. Pour connaître la procédure de configuration manuelle d'une interface, reportez-vous à la section Gestion des interfaces dans Solaris 10 3/05 ou au Chapitre 6Administration d'interfaces réseau (tâches).
Le nom des nouveaux fichiers de configuration d'interface peut avoir la syntaxe suivante :
hostname.interface hostname6.interface |
La variable interface possède la syntaxe suivante :
dev[.module[.module ...]]PPA |
Indique un périphérique d'interface réseau. Le périphérique peut être une interface réseau physique, telle que eri ou qfe ou une interface logique de type tunnel. Pour de plus amples informations, reportez-vous à la section Fichier de configuration d'interface IPv6.
Répertorie un ou plusieurs modules STREAMS à empiler sur le périphérique lorsque celui-ci est monté.
Indique le point d'attache physique.
La syntaxe [.[.]] est également acceptée.
Exemples de noms de fichier de configuration IPv6 valides :
hostname6.qfe0 hostname.ip.tun0 hostname.ip6.tun0 hostname6.ip6to4tun0 hostname6.ip.tun0 hostname6.ip6.tun0 |
Le fichier /etc/inet/ipaddrsel.conf contient la table des règles de sélection d'adresse IPv6 par défaut. Si vous avez activé le protocole IPv6 lors de l'installation de Oracle Solaris, ce fichier contient les éléments présentés dans le Tableau 11–5.
Vous pouvez modifier le contenu de /etc/inet/ipaddrsel.conf. Toutefois, cette opération n'est pas recommandée. Si cela s'avère nécessaire, reportez-vous à la procédure décrite à la section Administration de la table des règles de sélection d'adresses IPv6. Pour plus d'informations sur le fichier ippaddrsel.conf, reportez-vous à la section Raisons pour lesquelles le tableau des règles de sélection d'adresses IPv6 doit être modifié ainsi qu'à la page de manuel ipaddrsel.conf(4).
Cette section décrit les commandes ajoutées lors de l'implémentation du protocole IPv6 sous Oracle Solaris. Les commandes existantes qui ont été modifiées pour prendre en charge IPv6 y sont également détaillées.
La commande ipaddrsel permet de modifier le tableau des règles de sélection des adresses IPv6 par défaut.
Le noyau Oracle Solaris utilise la table des règles de sélection des adresses IPv6 par défaut pour le classement des adresses de destination et la sélection des adresses sources pour les en-têtes de paquet IPv6. Le fichier /etc/inet/ipaddrsel.conf contient ce tableau de règles.
Le tableau suivant répertorie les formats d'adresse par défaut ainsi que les priorités de chacune telles qu'elles doivent figurer dans le tableau de règles. Vous pouvez rechercher des informations techniques sur la sélection d'adresses IPv6 dans la page de manuel inet6(7P).
Tableau 11–5 Tableau des règles de sélection des adresses IPv6 par défaut
Préfixe |
Priorité |
Définition |
---|---|---|
::1/128 |
50 |
Loopback |
::/0 |
40 |
Par défaut |
2002::/16 |
30 |
6to4 |
::/96 |
20 |
IPv4 Compatible |
::ffff:0:0/96 |
10 |
IPv4 |
Dans ce tableau, les préfixes IPv6 (::1/128 et ::/0) ont la priorité sur les adresses 6to4 (2002::/16) et les adresses IPv4 (::/96 et ::ffff:0:0/96). Par conséquent, le noyau choisit par défaut l'adresse IPv6 globale de l'interface pour les paquets envoyés vers une autre destination IPv6. L'adresse IPv4 de l'interface est moins prioritaire, notamment pour les paquets envoyés vers une destination IPv6. Étant donné l'adresse IPv6 source sélectionnée, le noyau utilise également le format IPv6 pour l'adresse de destination.
En règle générale, le tableau des règles de sélection d'adresses IPv6 par défaut n'a pas besoin d'être modifié. En cas de modification nécessaire, exécutez la commande ipaddrsel.
Les situations suivantes nécessitent une modification du tableau :
Si le système possède une interface qui est utilisée pour un tunnel 6to4, vous pouvez définir une priorité plus élevée pour les adresses 6to4.
Si vous souhaitez qu'une adresse source particulière communique avec une adresse de destination particulière, vous pouvez ajouter ces adresses au tableau de règles. Ensuite, vous pouvez les marquer comme des adresses préférées à l'aide de la commande ifconfig.
Si vous voulez que les adresses IPv4 aient la priorité sur les adresses IPv6, vous pouvez remplacer la priorité de ::ffff:0:0/96 par un chiffre plus élevé.
Si vous devez assigner une priorité plus élevée à des adresses désapprouvées, vous pouvez ajouter ces adresses au tableau de règles. Prenons l'exemple des adresses de site locales, actuellement désapprouvées sur le réseau IPv6. Ces adresses possèdent le préfixe fec0::/10 . Vous pouvez modifier le tableau de règles afin de définir une priorité plus élevée pour ces adresses.
Pour de plus amples informations sur la commande ipaddrsel, reportez-vous à la page de manuel ipaddrsel(1M).
La création de tunnel 6to4 permet à des sites 6to4 isolés de communiquer. Cependant, pour transférer des paquets vers un site IPv6 natif et non-6to4, le routeur 6to4 doit être relié au routeur relais 6to4 par un tunnel. Le routeur relais 6to4 transfère ensuite les paquets 6to4 au réseau IPv6 et, finalement, au site IPv6 natif. Si un site 6to4 doit échanger des données avec un site IPv6, vous pouvez créer le tunnel approprié à l'aide de la commande 6to4relay.
Sous Oracle Solaris, la liaison de tunnels à des routeurs relais est désactivée car l'utilisation des routeurs relais n'est pas sécurisée. Avant de relier un tunnel à un routeur relais 6to4, vous devez être conscient des problèmes qui peuvent survenir avec ce type de scénario. Pour de plus amples informations sur les routeurs relais 6to4, reportez-vous à la section Informations importantes pour la création de tunnels vers un routeur relais 6to4. Pour activer la prise en charge d'un routeur relais 6to4, vous pouvez suivre la procédure indiquée à la section Procédure de configuration d'un tunnel 6to4.
La commande 6to4relay possède la syntaxe suivante :
6to4relay -e [-a IPv4-address] -d -h |
Assure la prise en charge de tunnels entre le routeur 6to4 et un routeur relais 6to4 anycast. Ainsi, l'adresse du point d'extrémité du tunnel est définie sur 192.88.99.1 , soit l'adresse du groupe anycast de routeurs relais 6to4.
Assure la prise en charge de tunnels entre le routeur 6to4 et un routeur relais 6to4 possédant l'adresse IPv4 spécifiée.
Désactive la prise en charge de tunnels vers un routeur relais 6to4 (paramètre par défaut de Oracle Solaris).
Affiche l'aide concernant la commande 6to4relay.
Pour plus d'informations, reportez-vous à la page de manuel 6to4relay(1M).
La commande 6to4relay, sans argument, affiche le statut actuel de la prise en charge des routeurs relais 6to4. Cet exemple indique la sortie par défaut de l'implémentation du protocole IPv6 sous Oracle Solaris.
# /usr/sbin/6to4relay 6to4relay:6to4 Relay Router communication support is disabled |
Lorsque la prise ne charge des routeurs relais est activée, la commande 6to4relay affiche la sortie suivante :
# /usr/sbin/6to4relay 6to4relay:6to4 Relay Router communication support is enabled IPv4 destination address of Relay Router=192.88.99.1 |
Si vous spécifiez l'option -a et une adresse IPv4 dans la commande 6to4relay, l'adresse IPv4 fournie avec l'option - a remplace l'adresse 192.88.99.1.
La commande 6to4relay ne signale pas l'exécution des options -d, -e et -a adresse IPv4. Cependant, elle n'affiche aucun message d'erreur lié à l'exécution de ces options.
La commande ifconfig permet de monter les interfaces IPv6 et le module de mise sous tunnel. ifconfig utilise un jeu étendu de ioctls pour configurer à la fois les interfaces réseau IPv4 et IPv6. Les options ifconfig qui prennent en charge les opérations IPv6 sont répertoriées ci-dessous. Pour connaître les différentes tâches IPv4 et IPv6 qui impliquent l'exécution de la commande ifconfig, reportez-vous à la section Contrôle de la configuration de l'interface avec la commande ifconfig.
Définit l'index de l'interface.
Définit la source ou la destination du tunnel.
Crée l'interface logique suivante.
Supprime une interface logique possédant une adresse IP spécifique.
Définit l'adresse de destination point à point pour une interface.
Définit une adresse et/ou un masque de réseau pour une interface.
Définit l'adresse de sous-réseau d'une interface.
Active ou désactive la transmission de paquets sur une interface.
Le Chapitre 7Configuration d'un réseau IPv6 (tâches) fournit les procédures de configuration des réseaux IPv6.
La commande ifconfig suivante crée une interface logique hme0:3 :
# ifconfig hme0 inet6 addif up Created new logical interface hme0:3 |
Cette forme de ifconfig vérifie la création de l'interface :
# ifconfig hme0:3 inet6 hme0:3: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 inet6 inet6 fe80::203:baff:fe11:b321/10 |
La commande ifconfig suivante supprime une interface logique hme0:3 :
# ifconfig hme0:3 inet6 down # ifconfig hme0 inet6 removeif 1234::5678 |
# ifconfig ip.tun0 inet6 plumb index 13 |
Ouvre le tunnel à associer au nom de l'interface physique.
# ifconfig ip.tun0 inet6 ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD, #IPv6> mtu 1480 index 13 inet tunnel src 0.0.0.0 inet6 fe80::/10 --> :: |
Configure les flux nécessaires au protocole TCP/IP pour utiliser le périphérique du tunnel et signaler son statut.
# ifconfig ip.tun0 inet6 tsrc 120.46.86.158 tdst 120.46.86.122 |
Configure l'adresse source et l'adresse cible du tunnel.
# ifconfig ip.tun0 inet6 ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD, IPv6> mtu 1480 index 13 inet tunnel src 120.46.86.158 tunnel dst 120.46.86.122 inet6 fe80::8192:569e/10 --> fe80::8192:567a |
Indique le nouveau statut du périphérique après la configuration.
Dans l'exemple suivant, une configuration de pseudointerface 6to4 utilise l'ID de sous-réseau 1 et spécifie l'ID hôte sous forme hexadécimale.
# ifconfig ip.6to4tun0 inet6 plumb # ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 \ 2002:8192:56bb:1::8192:56bb/64 up |
# ifconfig ip.6to4tun0 inet6 ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11 inet tunnel src 129.146.86.187 tunnel hop limit 60 inet6 2002:8192:56bb:1::8192:56bb/64 |
Voici une forme courte de la commande permettant de configurer un tunnel 6to4.
# ifconfig ip.6to4tun0 inet6 plumb # ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 up |
# ifconfig ip.6to4tun0 inet6 ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11 inet tunnel src 129.146.86.187 tunnel hop limit 60 inet6 2002:8192:56bb::1/64 |
La commande netstat affiche le statut des réseaux IPv4 et IPv6. Vous pouvez choisir les informations de protocole à afficher en définissant la valeur de DEFAULT_IP dans le fichier /etc/default/inet_type ou en utilisant l'option -f dans la ligne de commande. Avec une valeur de DEFAULT_IP permanente, vous vous assurez que la commande netstat affiche uniquement les informations IPv4. Vous pouvez ignorer ce paramètre et utiliser l'option -f. Pour plus d'informations sur le fichier inet_type , reportez-vous à la page de manuel inet_type(4).
L'option -p de la commande netstat affiche la table des connexions réseau-média, c'est-à-dire la table des protocoles de résolution d'adresse pour l'IPv4 et le cache voisin pour l'IPv6. Pour de plus amples informations, reportez-vous à la page de manuel netstat(1M) La section Affichage du statut des sockets décrit les procédures impliquant l'exécution de cette commande.
La commande snoop permet de capturer des paquets IPv4 et IPv6. Cette commande peut s'afficher avec des en-têtes IPv6, des en-têtes d'extension IPv6, des en-têtes ICMPv6 et des données de protocole Neighbor Discovery. Par défaut, la commande snoop affiche les deux types de paquet (IPv4 et IPv6). Pour afficher soit l'un, soit l'autre, spécifiez le mot-clé de protocole ip ou ip6 avec la commande snoop. L'option de filtrage IPv6 vous permet de filtrer tous les paquets IPv4 et IPv6 et d'afficher uniquement les paquets IPv6. Pour plus d'informations, reportez-vous à la page de manuel snoop(1M) La section Contrôle du trafic réseau IPv6 décrit les procédures implicant l'exécution de la commande snoop.
La commande route fonctionne sur les routes IPv4 (par défaut) et IPv6. Pour réaliser des opérations sur les routes IPv6, tapez l'option -inet6 immédiatement à la suite de la commande route dans la ligne de commande. Pour plus d'informations, reportez-vous à la page de manuel route(1M).
La commande ping se sert des protocoles IPv4 et IPv6 pour sonder les hôtes cibles. Le choix du protocole dépend des adresses renvoyées par le serveur de noms pour l'hôte cible spécifique. Par défaut, si ce serveur renvoie une adresse IPv6 pour l'hôte cible, la commande ping utilise le protocole IPv6. S'il renvoie une adresse IPv4, la commande ping utilise le protocole IPv4. Pour ignorer cette action, vous pouvez taper l'option -A dans la ligne de commande et spécifier le protocole à utiliser.
Pour de plus amples informations, reportez-vous à la page de manuel ping(1M) La section Test des hôtes distants à l'aide de la commande ping décrit les procédures implicant l'exécution de la commande ping .
Vous pouvez exécuter la commande traceroute pour tracer les routes IPv4 et IPv6 vers un hôte spécifique. Du point de vue du protocole, traceroute utilise le même algorithme que la commande ping. Pour ignorer ce choix, tapez l'option -A dans la ligne de commande. Vous pouvez tracer chaque route vers chaque adresse d'un hôte multiréseau en tapant l'option -a dans la ligne de commande.
Pour de plus amples informations, reportez-vous à la page de manuel traceroute(1M) La section Affichage des informations de routage à l'aide de la commande traceroute décrit les procédures qui impliquent l'exécution de la commande traceroute.
Cette section présente les démons liés à IPv6.
Le démon in.ndpd implémente le protocole IPv6 Neighbor Discovery ainsi que celui de découverte de routeur. Il implémente également la configuration automatique d'adresse IPv6. Les options suivantes sont prises en charge par in.ndpd.
Active le débogage.
Active le débogage dans le cadre d'événements spécifiques.
Spécifie un fichier de données de configuration spécifique au lieu du fichier /etc/inet/ndpd.conf.
Imprime les informations associées à chaque interface.
Ne met pas en boucle les publications du routeur.
Ignore la réception de paquets.
Spécifie le mode détaillé en faisant état de plusieurs types de message de diagnostic.
Active le suivi des paquets.
Le démon in.ndpd est contrôlé par les paramètres définis dans le fichier de configuration /etc/inet/ndpd.conf et par ceux du fichier de démarrage /var/inet/ndpd_state. interface qui s'appliquent.
Lorsque le fichier /etc/inet/ndpd.conf existe, il est analysé et utilisé pour configurer un nœud en tant que routeur. Le Tableau 11–2 répertorie les mots-clés corrects susceptibles de figurer dans ce fichier. Lors de l'initialisation d'un hôte, les routeurs risquent de ne pas être disponibles immédiatement. Les paquets publiés par le routeur risquent d'être abandonnés. En outre, les paquets risquent de ne pas atteindre l'hôte.
Le fichier /var/inet/ndpd_state.interface est un fichier d'état. Ce fichier est régulièrement mis à jour par chaque nœud. En cas de défaillance et de redémarrage du nœud, ce dernier peut configurer ses interfaces en l'absence de routeurs. Ce fichier contient l'adresse de l'interface, l'heure de la dernière mise à jour du fichier et la durée de validité du fichier. Il contient également d'autres paramètres “hérités” de précédentes publications de routeur.
Il est inutile de modifier le contenu des fichiers d'état. Le démon in.ndpd assure la maintenance automatique des fichiers d'état.
Consultez les pages de manuel in.ndpd(1M) et ndpd.conf(4) pour obtenir des listes des variables de configuration et des valeurs acceptables.
Le démon in.ripngd implémente les informations de RIPng (Routing Information Protocol next-generation, protocole d'informations de routage nouvelle génération) pour les routeurs IPv6. Le RIPng définit l'équivalent IPv6 de RIP (Routing Information Protocol, protocole d'informations de routage). Lorsque vous configurez un routeur IPv6 avec la commande routeadm et activez le routage IPv6, le démon in.ripngd implémente RIPng sur le routeur.
Vous trouverez ci-dessous les options RIPng prises en charge.
n spécifie le numéro de port alternatif utilisé pour l'envoi ou la réception de paquets RIPnG.
Supprime les informations de routage.
Force le routage d'informations même si le démon fait office de routeur.
Supprime l'utilisation du poison reverse.
Si in.ripngd n'agit pas en tant que routeur, le démon saisit uniquement une route par défaut pour chaque routeur.
Une application de serveur compatible IPv6 peut gérer les requêtes IPv4 et IPv6, ou les requêtes IPv6 uniquement. Le serveur gère toujours les requêtes par le biais d'un socket IPv6. En outre, le serveur utilise le même protocole qu'utilise le client correspondant. Pour ajouter ou modifier un service pour IPv6, utilisez les commandes disponibles à partir du service SMF (Service Management Facility, utilitaire de gestion des services).
Pour obtenir des informations sur les commandes SMF, reportez-vous à la section SMF Command-Line Administrative Utilities du System Administration Guide: Basic Administration .
Pour obtenir une tâche d'exemple utilisant le service SMF pour configurer un manifeste de service IPv4 s'exécutant sur SCTP, reportez-vous à la section Ajout de services utilisant le protocole SCTP.
Pour configurer un service IPv6, vous devez vous assurer que la valeur du champ proto dans le profil inetadm pour ce service répertorie la valeur adéquate :
Pour un service assurant la gestion de requêtes IPv4 et IPv6, sélectionnez tcp6, udp6 ou sctp. Une valeur proto de tcp6, udp6 ou sctp6 a pour conséquence de faire passer inetd sur un socket IPv6 vers le serveur. Le serveur contient une adresse mappée IPv4 au cas où un client IPv4 recevrait une requête.
Pour un service qui gère uniquement les requêtes IPv6, sélectionnez tcp6only ou udp6only. Si proto a l'une de ces valeurs, inetd passe le serveur à un socket IPv6.
Si vous remplacez une commande Oracle Solaris par une autre implémentation, vous devez vous assurer que l'implémentation de ce service prend en charge le protocole IPv6. Si l'implémentation ne prend pas IPv6 en charge, vous devez spécifier la valeur proto en tant que tcp, udp ou sctp.
Voici un profil qui résulte de l'exécution de inetadm pour un manifeste de service echo prenant IPv4 et IPv6 en charge, et s'exécute sur SCTP :
# inetadm -l svc:/network/echo:sctp_stream SCOPE NAME=VALUE name="echo" endpoint_type="stream" proto="sctp6" isrpc=FALSE wait=FALSE exec="/usr/lib/inet/in.echod -s" user="root" default bind_addr="" default bind_fail_max=-1 default bind_fail_interval=-1 default max_con_rate=-1 default max_copies=-1 default con_rate_offline=-1 default failrate_cnt=40 default failrate_interval=60 default inherit_env=TRUE default tcp_trace=FALSE default tcp_wrappers=FALSE |
La syntaxe suivante permet de modifier la valeur du champ proto :
# inetadm -m FMRI proto="transport-protocols" |
Tous les serveurs fournis avec le logiciel Oracle Solaris ne nécessitent qu'une entrée de profil spécifiant proto en tant que tcp6, udp6 ou sctp6. Cependant, le serveur shell distant (shell) et le serveur d'exécution distant (exec) sont à présent composés d'une instance de service unique, nécessitant une valeur proto contenant les valeurs tcp et tcp6only. Par exemple, pour définir la valeur proto pour shell, émettez la commande suivante :
# inetadm -m network/shell:default proto="tcp,tcp6only" |
Consultez les extensions IPv6 de l'API Socket dans la section Programming Interfaces Guide pour obtenir des informations supplémentaires sur l'écriture de serveurs compatibles IPv6 qui utilisent des sockets.
Gardez les éléments suivants à l'esprit lorsque vous ajoutez ou modifiez un service pour IPv6 :
Vous devez spécifier la valeur proto en tant que tcp6, sctp6 ou udp6 afin d'activer les connexions IPv4 ou IPv6. Si vous spécifiez la valeur pour proto en tant que tcp, sctp ou udp, le service n'utilise qu'IPv4.
Bien qu'il soit possible d'ajouter une instance de service utilisant des sockets SCTP de style un à plusieurs à inetd, il est déconseillé de le faire. inetd ne fonctionne pas avec les sockets SCTP de style un à plusieurs.
Si un service nécessite deux entrées en raison de propriétés wait-status ou exec différentes, vous devez créer deux instances/services à partir du service d'origine.
IPv6 présente le protocole Neighbor Discovery, comme décrit dans le document RFC 2461, Neighbor Discovery for IP Version 6 (IPv6). Pour obtenir une présentation des principales fonctionnalités de la détection des voisins, reportez-vous à la section Présentation du protocole de détection de voisins IPv6.
Cette section décrit les fonctionnalités suivantes du protocole ND :
La détection de voisins définit cinq nouveaux messages ICMP (Internet Control Message Protocol, protocole de messages de contrôle Internet). Les messages remplissent les fonctions suivantes :
Sollicitation de routeur – Lorsqu'une interface est activée, les hôtes peuvent demander des messages de sollicitation de routeur. Les sollicitations demandent aux routeurs de générer immédiatement des publications de routeurs, plutôt qu'à la prochaine heure prévue.
Publication de routeur – Les routeurs publient leur présence, divers liens de paramètres et divers liens de paramètres Internet. Les routeurs effectuent des publications régulières ou en réponse à un message de sollicitation de routeur. Les publications de routeur contiennent des préfixes utilisés pour la détermination sur lien ou la configuration d'adresse, une valeur de limite de saut recommandée, et ainsi de suite.
Sollicitation de voisin – Les nœuds envoient des messages de sollicitation de voisins afin de déterminer l'adresse de couche liaison du voisin. Les messages de sollicitation de voisin sont également envoyés afin de vérifier qu'un voisin est toujours accessible par une adresse de couche liaison mise en cache. Les sollicitations s'utilisent également pour la détection d'adresses dupliquées.
Publication de voisins – Un nœud envoie des messages de publication de voisinage en réponse à un message de sollicitation de voisinage Le nœud peut également envoyer des publications de voisinage non sollicitées pour signaler une modification de l'adresse de couche liaison.
Redirection – Les routeurs utilisent les messages de redirection afin d'informer les hôtes de l'existence d'un meilleur saut pour une destination ou que la destination se trouve sur la même liaison.
Cette section comprend une présentation des étapes typiques effectuées par une interface lors d'une configuration automatique. La configuration automatique s'effectue uniquement sur des liaisons compatibles multicast.
Une interface compatible multicast est activée, par exemple, lors du démarrage système d'un nœud.
Le nœud démarre le processus de configuration automatique en générant une adresse lien-local pour l'interface.
L'adresse lien-local est formée à partir de l'adresse MAC (Media Access Control) de l'interface.
Le nœud envoie un message de sollicitation de voisin contenant l'adresse lien-local provisoire en guise de cible.
Le message a pour objectif de vérifier que l'adresse possible n'est pas déjà utilisée par un autre nœud sur la liaison. Une fois la vérification effectuée, l'adresse lien-local peut être assignée à l'interface.
Si un autre nœud utilise déjà l'adresse proposée, celui-ci renvoie une publication de voisin indiquant que l'adresse est déjà en cours d'utilisation.
Si un autre nœud tente également d'utiliser la même adresse, le nœud envoie également une sollicitation de voisinage pour la cible.
Le nombre de transmissions ou de retransmissions de sollicitation de voisins, ainsi que le temps d'attente entre sollicitations, sont spécifiques aux liaisons. Au besoin, vous pouvez définir ces paramètres.
Si un nœud détermine que son adresse lien-local possible n'est pas unique, la configuration automatique est interrompue. Dans ce cas, vous devrez configurer manuellement l'adresse lien-local de l'interface.
Pour simplifier la récupération, vous pouvez fournir un autre ID d'interface qui remplace l'identifiant par défaut. Ensuite, le mécanisme de configuration automatique peut reprendre, en utilisant le nouvel ID d'interface, qui est à priori unique.
Lorsqu'un nœud détermine l'unicité de sa future adresse lien-local, il assigne celle-ci à l'interface.
Le nœud dispose alors d'une connectivité de niveau IP avec les nœuds voisins. Les étapes restantes de la configuration automatique sont effectuées exclusivement par les hôtes.
La phase suivante de la configuration automatique consiste à obtenir une publication de routeur ou à déterminer une absence totale de routeurs. Si les routeurs sont présents, ils envoient des publications de routeur qui spécifient le type de configuration automatique que doit effectuer un hôte.
Les routers envoient des publications de routeur à intervalles réguliers. Cependant, le temps d'attente entre publications successives est en règle générale plus long que le temps d'attente possible d'un hôte effectuant la configuration automatique. Afin d'obtenir une publication dans les plus brefs délais, un hôte envoie une ou plusieurs sollicitations de routeur au groupe multicast tous routeurs.
La publication de routeur contient également des variables de préfixe avec des informations utilisées par la configuration automatique d'adresse sans état pour la génération de préfixes. Le champ de configuration automatique d'adresse sans état dans les publications de routeur sont traitées indépendamment. Un champ d'option contenant les informations de préfixe, l'indicateur de configuration automatique d'adresse, indique si l'option s'applique également à la configuration automatique sans état. Si le champ d'option s'y applique, des champs d'option supplémentaires contiennent un préfixe de sous-réseau avec des valeurs de durée de vie. Ces valeurs indiquent la durée de validité et de préférence des adresses créées à partir du préfixe.
Dans la mesure où les routeurs génèrent régulièrement des publications de routeur, les hôtes reçoivent de nouvelles publications en continu. Les hôtes compatibles IPv6 traitent les informations contenues dans chaque publication. Les hôtes ajoutent des informations. Ils actualisent également les informations reçues dans les publications précédentes.
Pour des raisons de sécurité, l'unicité de toutes les adresses doit être vérifiée, préalablement à leur assignation à une interface. La situation est différente pour les adresses créées par configuration automatique sans état. L'unicité d'une adresse est déterminée principalement par la partie de l'adresse formée à partir d'un ID d'interface. Par conséquent, si un nœud a déjà vérifié l'unicité d'une adresse lien-local, il est inutile de tester les adresses supplémentaires individuellement. Les adresses doivent être créées à partir du même ID d'interface. Toutes les adresses obtenues manuellement doivent par contre être testées individuellement pour leur unicité. Les administrateurs système de certains sites pensent que les bénéfices de la détection d'adresses dupliquées ne vaut pas le temps système qu'elle utilise. Pour ces sites, l'utilisation de la détection des adresses dupliquées peut être désactivée en définissant un indicateur de configuration par interface.
Pour accélérer le processus de configuration automatique, un hôte peut générer son adresse lien-local et vérifier son unicité, pendant que l'hôte attend une publication de routeur. Un routeur peut retarder une réponse à une sollicitation de routeur de quelques secondes. Par conséquent, le temps total nécessaire à la configuration automatique peut être bien plus long si les deux étapes sont effectuées en série.
La détection de voisins utilise les messages de sollicitation de voisin pour déterminer si plusieurs nœuds sont assignés à la même adresse unicast. La détection d'inaccessibilité de voisin détecte la défaillance d'un voisin ou du chemin de transfert du voisin. Cette détection nécessite une confirmation de la réception des paquets par le voisin. La détection d'inaccessibilité de voisins détermine également que les paquets sont traités correctement par la couche IP du nœud.
La détection d'inaccessibilité de voisin utilise les confirmations en provenance de deux sources : les protocoles de couche supérieure et les messages de sollicitation de voisin. Lorsque c'est possible, les protocoles de couche supérieure fournissent une confirmation positive de la progression d'une connexion. Par exemple, à la réception d'accusés de réception TCP, il est confirmé que les données précédemment envoyées ont été livrées correctement.
Lorsqu'un nœud n'obtient pas de confirmation en provenance des protocoles de couche supérieure, le nœud envoie des messages de sollicitation de voisins. Ces messages sollicitent des publications de voisinage en tant que confirmation d'accessibilité à partir du prochain saut. Pour réduire le trafic réseau inutile, les messages de sonde sont envoyés uniquement au nœud envoyant des paquets activement.
Pour garantir que toutes les adresses configurées sont susceptibles d'être uniques sur un lien donné, les nœuds exécutent un algorithme de détection d'adresse dupliquée sur les adresses. Les nœuds doivent exécuter l'algorithme avant d'assigner les adresses à une interface. L'algorithme de détection d'adresses dupliquées est exécuté sur toutes les adresses.
Le processus de configuration automatique décrit dans cette section s'applique uniquement aux hôtes et non aux routeurs. Dans la mesure où la configuration automatique utilise des informations publiées par les routeurs, ces derniers doivent être configurés différemment. Cependant, les routeurs génèrent des adresses lien-local à l'aide du mécanisme décrit dans ce chapitre. En outre, les routeurs doivent réussir l'algorithme de détection d'adresses dupliquées sur toutes les adresses préalablement à l'assignation d'une adresse à une interface.
Un routeur qui accepte les paquets à la place d'une adresse cible peut émettre des publications de voisin impossibles à ignorer. Le routeur peut accepter des paquets pour une adresse cible incapable de répondre aux sollicitations de voisins. L'utilisation de proxy n'est actuellement pas spécifiée. Cependant, la publication de proxy pourrait être utilisée pour la gestion de cas comme ceux de nœuds mobiles qui ont été déplacés hors liaison. Notez que l'utilisation de proxy n'est pas destinée à l'être en tant que mécanisme général de gestion des nœuds qui n'implémentent pas ce protocole.
Les nœuds avec interfaces répliquées peuvent avoir besoin d'équilibrer la charge de la réception de paquets entrants sur plusieurs interfaces réseau situées sur la même liaison. Ces nœuds possèdent plusieurs adresses lien-local assignées à la même interface. Par exemple, un pilote de réseau unique peut représenter plusieurs cartes d'interface réseau en tant qu'interface logique unique possédant plusieurs adresses lien-local.
La gestion de l'équilibrage de charge s'effectue en autorisant les routeurs à omettre l'adresse lien-local source des paquets de publication de routeur. Par conséquent, les voisins doivent utiliser les messages de sollicitation de voisin afin de connaître les adresses lien-local des routeurs. Les messages renvoyés de publication des voisins peuvent contenir des adresses lien-local différentes, selon l'adresse qui a envoyé la demande.
Un nœud qui sait que son adresse lien-local a été modifiée peut envoyer des paquets de publication de voisins multicast non sollicités. Le nœud peut envoyer des paquets multicast à tous les nœuds pour une mise à jour des adresses lien-local mises en cache qui ne sont plus valides. L'envoi de publications non sollicitées constitue uniquement une amélioration des performances. L'algorithme de détection d'inaccessibilité des voisins assure la fiabilité de la détection de la nouvelle adresse par le nœud, bien que le temps d'attente risque d'être légèrement plus long.
La fonctionnalité du protocole ND (Neighbor Discovery, détection des voisins) IPv6 correspond à une combinaison des protocoles IPv4 : ARP (Address Resolution Protocol, protocole de résolution d'adresse), détection de routeur ICMP (Internet Control Message Protocol, protocole de messages de contrôle Internet) et redirection ICMP. IPv4 ne possède pas de protocole ou de mécanisme accepté par tous pour la détection d'inaccessibilité. Cependant, les exigences de l'hôte spécifient les algorithmes possibles pour la détection de passerelles bloquées. La détection de passerelles bloquées est un sous-ensemble des problèmes résolus par la détection d'inaccessibilité de voisins.
La liste suivante compare le protocole de détection de voisins à la suite de protocoles IPv4 associés.
La détection de routeur fait partie du jeu de protocoles IPv6 de base. Les hôtes IPv6 n'ont pas besoin d'émettre la commande snoop aux protocoles de routage pour rechercher un routeur. IPv4 utilise le protocole ARP, la détection de routeur ICMP et la redirection ICMP pour la détection de routeur.
Les publications de routeur IPv6 gèrent les adresses lien-local. Aucun échange de paquet supplémentaire n'est nécessaire pour la résolution de l'adresse lien-local du routeur.
Les publications de routeur gèrent les préfixes de site pour une liaison. Aucun mécanisme séparé n'est nécessaire pour la configuration du masque de réseau, contrairement à IPv4.
Les publications de routeur sont compatibles avec la configuration automatique d'adresse. La configuration automatique n'est pas implémentée dans IPv4.
La détection de voisins permet aux routeurs IPv6 de publier la MTU utilisable pour les hôtes sur la liaison. Par conséquent, tous les nœuds utilisent la même valeur de MTU sur des liaisons ne disposant pas d'une MTU correctement définie. Les hôtes IPv4 sur un même réseau peuvent avoir des MTU différentes.
Contrairement aux adresses de diffusion IPv4, la multidiffusion de résolution d'adresse IPv6 est répartie sur 4 milliards (2^32) d'adresses multicast, ce qui réduit de façon significative les interruptions relatives à la résolution d'adresses sur des nœuds autres que la cible. En outre, les ordinateurs non IPv6 ne doivent pas être éteints.
Les redirections IPv6 contiennent l'adresse lien-local du premier nouveau saut. La résolution d'adresse séparée n'est pas nécessaire lors de la réception d'une redirection.
Il est possible d'associer plusieurs préfixes de site au même réseau IPv6. Par défaut, les hôtes sont informés de tous les préfixes de site locaux par les publications de routeur. Cependant, les routeurs peuvent être configurés afin d'omettre certains ou tous les préfixes des publications de routeur. Dans de tels cas, les hôtes partent du principe que les destinations se trouvent sur des réseaux distants. Par conséquent, les hôtes envoient le trafic aux routeurs. Un routeur peut alors émettre des redirections le cas échéant.
Contrairement à IPv4, le destinataire d'un message IPv6 redirigé part du principe que le nouveau saut suivant se trouve sur le réseau local. Dans IPv4, un hôte ignore les messages de redirection qui spécifient un saut suivant qui ne se trouve pas sur le réseau local, selon le masque de réseau. Le mécanisme de redirection IPv6 est similiaire à l'utilitaire XRedirect d'IPv4. Le mécanisme de redirection est utile sur des liens de non diffusion ou de médias partagés. Sur ces réseaux, les nœuds ne doivent pas effectuer de vérification sur tous les préfixes pour les destinations de liaison locale.
La détection d'inaccessibilité de voisin IPv6 améliore la livraison de paquets en la présence de routeurs défaillants. Cette capacité améliore la livraison de paquets sur des liaisons partiellement défaillantes ou partitionnées. Cette capacité améliore également la livraison de paquet sur des nœuds qui modifient leurs adresses lien-local. Par exemple, les nœuds mobiles peuvent se déplacer hors du réseau local sans aucune perte de connectivité en raison d'anciens caches ARP. IPv4 ne possède pas de méthode correspondante de détection d'inaccessibilité de voisins.
Contrairement au protocole ARP, la détection de voisins détecte les défaillances de demi liaison à l'aide de la détection d'inaccessibilité de voisins. La détection de voisins évite d'envoyer du trafic aux voisins en l'absence de connectivité bidirectionnelle.
En utilisant les adresses lien-local pour identifier les routeurs de façon unique, les hôtes IPv6 peuvent conserver les associations de routeur. La capacité d'identification de routeurs est requise pour les publications de routeur et pour les messages de redirection. Les hôtes doivent conserver les associations de routeur si le site utilise de nouveaux préfixes globaux. IPv4 ne possède pas de méthode comparable d'identification des routeurs.
Dans la mesure où les messages de détection de voisins ont une limite de saut de 255 après réception, le protocole n'est pas affecté par les attaques de mystification en provenance de nœuds hors liaison. Les nœuds IPv4 hors liaison sont eux capables d'envoyer des messages de redirection ICMP. Les nœuds IPv4 hors liaison peuvent également envoyer des messages de publication de routeur.
En plaçant la résolution d'adresse à la couche ICMP, la détection de voisins est moins dépendante de médias que le protocole ARP. Par conséquent, les mécanismes standard d'authentification IP et de sécurité peuvent être utilisés.
Le routage IPv6 est quasiment identique au routage IPv4 sous CIDR (Classless Inter-Domain Routing, routage inter-domaine sans classe). La seule différence est la taille des adresses qui sont de 128 bits dans IPv6 au lieu de 32 bits dans IPv4. Avec des extensions simples, il est possible d'utiliser la totalité des algorithmes de routage d'IPv4 comme OSPF, RIP, IDRP et IS-IS.
IPv6 comprend également des extensions de routage simples qui prennent en charge de nouvelles capacités de routage puissantes. La liste suivante décrit les nouvelles capacités de routage :
sélection de fournisseur en fonction de la stratégie, des performances, des coûts, etc ;
hébergement de mobilité, routage vers emplacement actuel ;
réadressage automatique, routage vers nouvelle adresse.
Les nouvelles capacités de routage s'obtiennent par la création de séquences d'adresses IPv6 utilisant l'option de routage IPv6. Une source IPv6 utilise l'option de routage afin de répertorier un ou plusieurs nœuds intermédiaires, ou groupes topologiques, à visiter en cours d'acheminement vers la destination du paquet. Cette fonction possède énormément de similitudes avec l'option IPv4 de source lâche et de route d'enregistrement.
Pour que les séquences d'adresses soient une fonction générale, les hôtes IPv6 doivent, dans la plupart des cas, inverser les routes d'un paquet reçu par un hôte. Le paquet doit être authentifié à l'aide de l'utilisation de l'en-tête d'authentification IPv6. Le paquet doit contenir des séquences d'adresse afin d'être renvoyé à son point d'origine. Cette technique force les implémentations d'hôtes IPv6 pour la prise en charge de la gestion et de l'inversion des routes source. La gestion et l'inversion des routes source est la clé permettant aux fournisseurs de travailler avec les hôtes qui implémentent les nouvelles capacités IPv6 comme la sélection de fournisseur et les adresses étendues.
Sur des liens compatibles multicast et des liens point à point, chaque routeur envoie régulièrement un paquet de publication de routeur au groupe multicast pour lui annoncer sa disponibilité. Un hôte reçoit des publications de routeur de la totalité des routeurs, constituant une liste des routeurs par défaut. Les routeurs génèrent des publications de routeur de façon suffisamment fréquente pour permettre aux hôtes d'être avertis de leur présence en quelques minutes. Cependant, les routeurs n'effectuent pas de publications à une fréquence suffisante pour se fier à une absence de publication permettant de détecter une défaillance de routeur. Un algorithme de détection séparé qui détermine l'inaccessibilité de voisin fournit la détection de défaillance.
Les publications de routeur contiennent une liste de préfixes de sous-réseau utilisés pour déterminer si un hôte se trouve sur le même lien que le routeur. La liste de préfixes est également utilisée pour la configuration d'adresses autonomes. Les indicateurs associés aux préfixes spécifient les utilisations spécifiques d'un préfixe particulier. Les hôtes utilisent les préfixes sur liaison publiés afin de constituer et de maintenir une liste utilisée pour décider lorsque la destination d'un paquet se trouve sur la liaison ou au-delà d'un routeur. Une destination peut se trouver sur une liaison même si celle-ci n'est couverte par aucun préfixe sur liaison publié. Dans de tels cas, un routeur peut envoyer une redirection. La redirection informe l'expéditeur que la destination est un voisin.
Les publications de routeur et les indicateurs par préfixe permettent aux routeurs d'informer des hôtes de la méthode qu'ils doivent utiliser pour effectuer une configuration automatique d'adresse sans état.
Les messages de publication de routeur contiennent également des paramètres Internet, comme la limite de saut, que les hôtes devraient utiliser dans des paquets entrants. Les messages de publication de routeur peuvent également (facultativement) contenir des paramètres de liens, comme le lien MTU. Cette fonctionnalité permet l'administration centralisée des paramètres critiques. Les paramètres peuvent être définis sur des routeurs et propagés automatiquement à tous les hôtes qui y sont connectés.
Les nœuds effectuent la résolution d'adresses par l'envoi de sollicitation de voisin à un groupe multicast, demandant au nœud cible de retourner son adresse de couche liaison. Les messages de sollicitation de voisin multicast sont envoyés à l'adresse de nœud multicast demandée de l'adresse cible. La cible retourne son adresse de couche liaison dans un message de publication d'un voisin unicast. Une paire de paquets de requête-réponse unique est suffisante pour permettre à l'initiateur et à la cible de résoudre les adresses de couche liaison de l'un et de l'autre. L'initiateur inclut son adresse de couche liaison dans la sollicitation de voisin.
Pour réduire toute dépendance possible d'un site IPv4/IPv6 double pile, il n'est pas nécessaire que tous les routeurs situés dans le chemin entre deux nœuds IPv6 soient compatibles avec IPv6. Le mécanisme prenant une telle configuration de réseau en charge s'appelle mise en tunnel. Les paquets IPv6 sont placés dans des paquets IPv4, qui sont ensuite acheminés via les routeurs IPv4. L'illustration suivante représente le mécanisme de mise en tunnel via des routeurs IPv4. Ces routeurs sont signalés sur l'illustration par un R.
L'implémentation du protocole IPv6 sous Oracle Solaris comprend deux types de mécanismes de mise en tunnel :
tunnels configurés entre deux routeurs, comme sur la Figure 11–5 ;
tunnels automatiques se terminant aux hôtes de points d'extrémité.
Un tunnel configuré est actuellement utilisé sur Internet à d'autres fins, par exemple, sur le MBONE, la dorsale multidiffusion IPv4. Fonctionnellement, le tunnel se compose de deux routeurs configurés de sorte à disposer d'une liaison virtuelle point à point entre les deux routeurs sur le réseau IPv4. Ce type de tunnel est susceptible d'être utilisé à l'avenir sur certaines parties d'Internet.
Les tunnels automatiques doivent disposer d'adresses compatibles avec IPv4. Les tunnels automatiques permettent de connecter des nœuds IPv6 en cas d'indisponibilité des routeurs IPv6. Ces tunnels peuvent provenir d'un hôte double pile ou d'un routeur double pile, grâce à la configuration d'une interface réseau de mise en tunnel automatique. Ces tunnels se terminent toujours sur l'hôte double pile. Ils déterminent de façon dynamique l'adresse IPv4 de destination, qui correspond au point d'extrémité du tunnel, en extrayant l'adresse à partir de l'adresse de destination compatible IPv4.
Le format des interfaces de création de tunnel est le suivant :
ip.tun ppa |
ppa correspond au point de connexion physique.
Lors du démarrage du système, le module de création de tunnel (tun) se place, via la commande ifconfig, sur l'IP afin de créer une interface virtuelle. Pour effectuer ce déplacement, vous devez créer le fichier hostname6.* adéquat.
Par exemple, pour créer un tunnel afin d'encapsuler les paquets IPv6 sur un réseau IPv4, IPv6 sur IPv4, créez le fichier suivant :
/etc/hostname6.ip.tun0 |
Le contenu de ce fichier est transféré à ifconfig une fois le montage des interfaces terminé. Le contenu correspond aux paramètres nécessaires pour configurer un tunnel point à point.
Vous trouverez ci-dessous un exemple d'entrées dans le fichier hostname6.ip.tun0 :
tsrc 10.10.10.23 tdst 172.16.7.19 up addif 2001:db8:3b4c:1:5678:5678::2 up |
Dans cet exemple, la source IPv4 et les adresses de destination sont utilisées comme des jetons afin de configurer automatiquement des adresses IPv6 lien-local. Ces adresses correspondent à la source et à la destination de l'interface ip.tun0. Deux interfaces sont configurées. L'interface ip.tun0 est configurée. Une interface logique, ip.tun0:1, est également configurée. Les adresses source et de destination IPv6 de l'interface logique sont spécifiées à l'aide de la commande addif.
Le contenu de ces fichiers de configuration est passé à ifconfig sans aucune modification lors du démarrage système en mode multiutilisateur. Les entrées de l'Exemple 11–11 sont équivalentes à ce qui suit :
# ifconfig ip.tun0 inet6 plumb # ifconfig ip.tun0 inet6 tsrc 10.0.0.23 tdst 172.16.7.19 up # ifconfig ip.tun0 inet6 addif 2001:db8:3b4c:1:5678:5678::2 up |
Vous trouverez ci-dessous la sortie de ifconfig -a pour ce tunnel.
ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST, NONUD,IPv6> mtu 1480 index 6 inet tunnel src 10.0.0.23 tunnel dst 172.16.7.19 inet6 fe80::c0a8:6417/10 --> fe80::c0a8:713 ip.tun0:1: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 index 5 inet6 2001:db8:3b4c:1:5678:5678::2 |
Vous pouvez configurer d'autres interfaces logiques en ajoutant des lignes au fichier de configuration à l'aide de la syntaxe suivante :
addif IPv6-source IPv6-destination up |
Lorsque l'une des extrémités du tunnel correspond à un routeur IPv6 qui publie un ou plusieurs préfixes sur le tunnel, il n'est pas nécessaire de disposer des commandes addif dans les fichiers de configuration de tunnel. Seul tsrc et tdst pourraient être nécessaires, car toutes les autres adresses sont configurées automatiquement.
Dans certains cas, les adresses lien-local source et de destination doivent être configurées manuellement pour un tunnel particulier. Modifiez la première ligne du fichier de configuration afin d'inclure ces adresses lien-local. La ligne suivante est un exemple :
tsrc 10.0.0.23 tdst 172.16.7.19 fe80::1/10 fe80::2 up |
Notez que l'adresse lien-local source dispose d'une longueur de préfixe de 10. Dans cet exemple, l'interface ip.tun0 ressemble à ce qui suit :
ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 index 6 inet tunnel src 10.0.0.23 tunnel dst 172.16.7.19 inet6 fe80::1/10 --> fe80::2 |
Pour créer un tunnel afin d'encapsuler les paquets IPv6 sur un réseau IPv6, IPv6 sur IPv6, créez le fichier suivant :
/etc/hostname6.ip6.tun0 |
L'exemple suivant correspond à des entrées du fichier hostname6.ip6.tun0 pour une encapsulation IPv6 sur un réseau IPv6 :
tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3 fe80::4 fe80::61 up |
Pour créer un tunnel afin d'encapsuler les paquets IPv4 sur un réseau IPv6, IPv4 sur IPv6, créez le fichier suivant :
/etc/hostname.ip6.tun0 |
L'exemple suivant correspond à des entrées du fichier hostname.ip6.tun0 pour une encapsulation IPv4 sur un réseau IPv6 :
tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3 10.0.0.4 10.0.0.61 up |
Pour créer un tunnel afin d'encapsuler les paquets IPv4 sur un réseau IPv4, IPv4 sur IPv4, créez le nom de fichier suivant :
/etc/hostname.ip.tun0 |
L'exemple suivant correspond à des entrées du fichier hostname.ip.tun0 pour une encapsulation IPv4 sur un réseau IPv4 :
tsrc 172.16.86.158 tdst 192.168.86.122 10.0.0.4 10.0.0.61 up |
Pour obtenir des informations spécifiques sur tun, reportez-vous à la page de manuel tun(7M). Pour obtenir une description générale des concepts de création de tunnel lors de la transition vers le protocole IPv6, reportez-vous à la section Présentation des tunnels IPv6. Pour obtenir une description des procédures de configuration de tunnels, reportez-vous à la section Tâches de configuration de tunnels pour la prise en charge d'IPv6 (liste des tâches).
Dans Oracle Solaris, la création de tunnels 6to4 constitue la méthode temporaire recommandée pour effectuer la transition entre les adressages IPv4 et IPv6. Les tunnels 6to4 permettent aux sites IPv6 isolés de communiquer, par le biais d'un tunnel automatique, avec un réseau IPv4 ne prenant pas en charge le protocole IPv6. Pour utiliser des tunnels 6to4, vous devez configurer un routeur de bordure sur le réseau IPv6 en tant que point d'extrémité du tunnel 6to4 automatique. Par la suite, le routeur 6to4 peut participer à un tunnel vers un autre site 6to4 ou vers un site IPv6 natif et non-6to4, le cas échéant.
Cette section fournit des références sur les rubriques concernant les tunnels 6to4 :
Topologie d'un tunnel 6to4
Adressage 6to4 (et format de publication)
Description du flux de paquets dans un tunnel 6to4
Topologie d'un tunnel reliant un routeur 6to4 et un routeur relais 6to4
Informations importantes pour la configuration de la prise en charge d'un routeur relais 6to4
Le tableau suivant décrit les autres tâches permettant de configurer des tunnels 6to4 et les ressources permettant obtenir d'autres informations utiles.
Tâche ou détail |
Référence |
---|---|
Configuration d'un tunnel 6to4 | |
RFC lié aux 6to4 | |
Informations détaillées sur la commande 6to4relay (prise en charge des tunnels vers un routeur relais 6to4) | |
Problèmes de sécurité avec 6to4 |
Un tunnel 6to4 offre la connexion IPv6 à tous les sites 6to4, quel que soit leur emplacement. De même, le tunnel offre un lien à l'ensemble des sites IPv6, notamment l'Internet IPv6 natif, à condition d'être configuré pour la transmission vers un routeur relais. La figure suivante illustre un tunnel 6to4 connectant des sites 6to4.
La figure illustre deux réseaux 6to4 isolés (Site A et Site B). Chaque site possède un routeur configuré avec une connexion externe à un réseau IPv4. Un tunnel 6to4 à l'échelle du réseau IPv4 offre une connexion entre sites 6to4.
Pour convertir un site IPv6 en site 6to4, vous devez configurer au moins une interface de routeur prenant en charge 6to4. Cette interface doit assurer la connexion externe au réseau IPv4. L'adresse que vous configurez sur qfe0 doit être globale et unique. Sur cette figure, l'interface du routeur A (qfe0) connecte le site A au réseau IPv4. L'interface qfe0 doit déjà être configurée avec une adresse IPv4 pour que vous puissiez définir qfe0 en tant que pseudointerface 6to4.
Dans cet exemple, le site A 6to4 se compose de deux sous-réseaux connectés aux interfaces hme0 et hme1 du routeur A. Dès que les hôtes IPv6 des sous-réseaux du site A reçoivent la publication du routeur A, ils sont automatiquement reconfigurés sur les adresses 6to4 dérivées.
Le site B est un autre site 6to4 isolé. Pour recevoir correctement le trafic du site A, un routeur de bordure sur le site B doit être configuré pour prendre en charge 6to4. Dans le cas contraire, le routeur ne reconnaît pas les paquets reçus du site A et les abandonne.
Cette section décrit le flux de paquets allant d'un hôte sur un site 6to4 à un autre hôte sur un site 6to4 distant. Ce scénario nécessite la topologie illustrée sur la Figure 11–6. Cela suppose également de configurer au préalable les routeurs et les hôtes 6to4.
Un hôte du sous-réseau 1 appartenant au site 6to4 A envoie une transmission à un hôte du site 6to4 B. Chaque en-tête de paquet possède des adresses 6to4 dérivées source et cible.
Le routeur du site A encapsule chaque paquet 6to4 dans un en-tête IPv4. Dans ce processus, le routeur définit l'adresse cible IPv4 de l'en-tête d'encapsulation sur l'adresse du routeur du site B. L'adresse cible IPv6 de chaque paquet IPv6 transmis via l'interface du tunnel contient également l'adresse cible IPv4. Ainsi, le routeur est en mesure de déterminer l'adresse cible IPv4 définie sur l'en-tête d'encapsulation. Ensuite, il utilise la procédure de routage IPv4 standard pour transmettre le paquet sur le réseau IPv4.
Tout routeur IPv4 rencontré par les paquets utilise l'adresse IPv4 cible de ces derniers pour la transmission. Cette adresse constitue l'adresse IPv4 globale et unique de l'interface du routeur B, qui sert également de pseudointerface 6to4.
Les paquets du site A arrivent sur le routeur B qui les décapsule en paquets IPv6 à partir de l'en-tête IPv4.
Le routeur B se sert alors de l'adresse cible des paquets IPv6 pour transmettre ces derniers à l'hôte destinataire sur le site B.
Les routeurs relais 6to4 fonctionnent en tant que points d'extrémité des tunnels reliant des routeurs 6to4 à des réseaux IPv6 natifs, non 6to4. Les routeurs relais constituent essentiellement des ponts entre le site 6to4 et les sites IPv6 natifs. Ce type de routeur risque de ne pas garantir la sécurité du réseau ; c'est pourquoi il n'est pas pris en charge par Oracle Solaris. Cependant, si votre site nécessite un tel tunnel, vous pouvez exécuter la commande 6to4relay pour créer le type de tunnel suivant.
Sur la Figure 11–7, le site A (6to4) doit communiquer avec un nœud du site B (IPv6 natif). L'illustration indique la trajectoire du trafic entre le site A et le site B à travers un tunnel 6to4 créé sur le réseau IPv4. Le tunnel dispose d'un routeur A 6to4 et d'un routeur relais 6to4 à chaque extrémité. Au-delà du routeur 6to4 se trouve le réseau IPv6 auquel le site B IPv6 est connecté.
Cette section décrit le flux de paquets se déplaçant d'un site 6to4 vers un site IPv6 natif. Ce scénario nécessite la topologie illustrée sur la Figure 11–7.
Un hôte résidant sur le site A (6to4) envoie une transmission à un hôte de destination appartenant au site B (IPv6 natif). Chaque en-tête de paquet possède une adresse 6to4 dérivée en tant qu'adresse source. L'adresse de destination correspond à une adresse IPv6 standard.
Le routeur 6to4 du site A encapsule chaque paquet dans un en-tête IPv4, dont la destination correspond à l'adresse IPv4 du routeur relais 6to4. Ensuite, il utilise la procédure de routage IPv4 standard pour transmettre le paquet sur le réseau IPv4. Tout routeur IPv4 rencontré par les paquets envoie ceux-ci vers le routeur relais 6to4.
Le routeur relais 6to4 anycast le plus proche (physiquement) du site A récupère les paquets destinés au groupe anycast 192.88.99.1.
Les routeurs relais 6to4 faisant partie du groupe anycast de routeurs relais 6to4 possèdent l'adresse IP 192.88.99.1. Cette adresse anycast constitue l'adresse par défaut des routeurs relais 6to4. Si vous avez besoin d'un routeur relais 6to4 spécifique, vous pouvez supprimer celui par défaut et spécifier l'adresse IPv4 du routeur en question.
Ce routeur relais décapsule ensuite l'en-tête IPv4 des paquets 6to4, dévoilant l'adresse de destination sur le réseau IPv6.
Finalement, il envoie ces paquets IPv6 sur le réseau IPv6, où un routeur du site B les récupère et les envoie au noeud IPv6 de destination.
Cette section décrit les modifications en matière d'attribution de noms introduites par l'implémentation d'IPv6. Vous pouvez stocker les adresses IPv6 dans les fichiers de services d'assignation de noms, NIS, LDAP, DNS ou ou tout autre fichier Oracle Solaris de votre choix. Vous pouvez également utiliser le protocole NIS à travers les transports RPC IPv6 pour la récupération de données NIS.
Un enregistrement de ressources spécifique IPv6, l'enregistrement de ressource AAAA, a été spécifié dans le document RFC 1886 DNS Extensions to Support IP Version 6. Cet enregistrement AAAA mappe un nom d'hôte en une adresse IPv6 de 128 bits. L'enregistrement PTR est toujours utilisé avec IPv6 pour mapper les adresses IP en noms d'hôtes. Les 32 quartets de d'adresse 128 bits sont inversés pour une adresse IPv6. Chaque quartet est converti dans sa valeur hexadécimale ASCII correspondante. Ensuite, ip6.int est joint.
Pour Solaris 10 11/06 et versions antérieures, en plus de la capacité de recherche d'adresses IPv6 via /etc/inet/ipnodes , la prise en charge IPv6 a été ajoutée aux services d'attribution de noms NIS, LDAP et DNS. Par conséquent, le fichier nsswitch.conf a été modifié afin de prendre les recherches IPv6 en charge.
hosts: files dns nisplus [NOTFOUND=return] ipnodes: files dns nisplus [NOTFOUND=return] |
Avant de modifier le fichier /etc/nsswitch.conf pour rechercher ipnodes dans plusieurs services d'attribution de noms, renseignez ces bases de données ipnodes avec des adresses IPv4 et IPv6. Autrement, des retards inutiles peuvent entraîner une résolution des adresses hôtes, notamment des retards de durée d'initialisation.
Le diagramme suivant illustre la nouvelle relation entre le fichier nsswitch.conf et les nouvelles bases de données de services d'attribution de noms utilisant les commandes gethostbyname et getipnodebyname. Les nouveaux éléments sont en italique. La commande gethostbyname vérifie uniquement les adresses IPv4 stockées dans /etc/inet/hosts. Dans Solaris 10 11/06 et versions antérieures, la commande getipnodebyname consulte la base de données spécifiée dans l'entrée ipnodes du fichier nsswitch.conf. En cas d'échec de la recherche, la commande vérifie la base de données spécifiée dans l'entrée hosts du fichier nsswitch.conf.
Pour plus d'informations sur les services de noms, reportez-vous au document System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .
Pour la prise en charge d'IPv6, vous pouvez rechercher les adresses IPv6 avec les commandes existantes des services d'attribution de noms. Par exemple, la commande ypmatch fonctionne avec les nouveaux mappages NIS. La commande nslookup peut rechercher les nouveaux enregistrements AAAA dans DNS.
Les logiciels NFS et RPC (Remote Procedure Call, appel de procédure distant) prennent IPv6 en charge de façon totalement fluide. Les commandes existantes relatives aux services NFS restent inchangées. Il est également possible d'exécuter la plupart des applications RPC sur IPv6 sans aucune modification. Certaines applications RPC avancées de reconnaissance d'acheminement peuvent nécessiter une mise à jour.
Oracle Solaris prend en charge le protocole IPv6 sur des ATM, des PVC (Permanent Virtual Circuits, circuits virtuels permanents) et des SVC (Switched Virtual Circuits, circuits virtuels à commutation) statiques.