Peu de choses sont aussi fondamentales dans la gestion d’infrastructure que les masques de sous-réseau — et peu sont comprises de manière aussi superficielle. Quiconque a déjà configuré une interface réseau a saisi 255.255.255.0 presque par automatisme. Mais lorsqu’il s’agit de concevoir l’architecture réseau d’un environnement de production, de segmenter le trafic entre VLANs, de dimensionner les sous-réseaux d’un déploiement en cloud privé ou de comprendre pourquoi un pare-feu ne laisse pas passer ce qu’il devrait, une compréhension réelle du fonctionnement des masques de sous-réseau fait la différence entre une infrastructure bien conçue et une source permanente d’incidents.
Ce guide parcourt le concept depuis les fondamentaux jusqu’aux scénarios pratiques rencontrés au quotidien dans les environnements de datacenter et de cloud, avec des tables de référence, des exemples de calcul et les erreurs les plus courantes.
Qu’est-ce qu’un masque de sous-réseau et pourquoi est-il important en infrastructure
Un masque de sous-réseau est une valeur de 32 bits qui, appliquée à une adresse IP, sépare deux éléments : la partie qui identifie le réseau et la partie qui identifie l’hôte (le dispositif spécifique au sein de ce réseau). C’est, en substance, l’outil qui indique à un système d’exploitation, un commutateur ou un routeur si un paquet doit rester sur le réseau local ou être transféré via la passerelle par défaut.
En binaire, un masque de sous-réseau est toujours une séquence de uns contigus suivis de zéros contigus. Les uns marquent les bits réseau ; les zéros, les bits hôte. Sans exception — bien que, comme nous le verrons plus loin, il fut un temps où il y en avait.
Deux façons d’exprimer la même chose :
- Notation décimale pointée :
255.255.255.0 - Notation CIDR :
/24
Les deux représentent exactement la même chose : les 24 premiers bits sont le réseau, les 8 restants sont l’hôte.
Comment ça fonctionne en interne : l’opération AND
Lorsqu’un dispositif doit déterminer si une adresse IP de destination se trouve sur son propre réseau, il ne compare pas les adresses à vue d’œil. Il effectue une opération AND logique entre sa propre adresse IP et le masque, puis fait de même avec l’IP de destination. Si les résultats correspondent, le paquet est envoyé directement. Sinon, il est transmis à la passerelle.
Exemple pratique avec l’IP 192.168.1.45 et le masque 255.255.255.0 :
IP : 11000000.10101000.00000001.00101101 (192.168.1.45)
Masque : 11111111.11111111.11111111.00000000 (255.255.255.0)
────────────────────────────────────
AND : 11000000.10101000.00000001.00000000 → 192.168.1.0
Le résultat — 192.168.1.0 — est l’adresse réseau. Si un autre dispositif produit le même résultat en appliquant son masque, les deux se trouvent sur le même sous-réseau.
Ce mécanisme, en apparence simple, est ce qui fait fonctionner toute la communication IP : du réseau domestique le plus basique à l’architecture réseau d’un datacenter avec des centaines de VLANs.
Table complète des masques de sous-réseau : de /32 à /0
La table suivante est une référence à garder toujours sous la main. Elle inclut la notation CIDR, le masque en décimal, le nombre total d’adresses IP, les hôtes utilisables (en soustrayant l’adresse réseau et le broadcast) ainsi que l’usage le plus courant en environnement d’infrastructure réel.
| CIDR | Masque décimal | Total IPs | Hôtes utilisables | Usage courant |
|---|---|---|---|---|
| /32 | 255.255.255.255 | 1 | 1 | Route hôte, loopback, règles de pare-feu |
| /31 | 255.255.255.254 | 2 | 2* | Liaisons point à point (RFC 3021) |
| /30 | 255.255.255.252 | 4 | 2 | Interconnexion entre routeurs |
| /29 | 255.255.255.248 | 8 | 6 | Segment DMZ, petit bloc d’IPs publiques |
| /28 | 255.255.255.240 | 16 | 14 | Petit pool d’IPs publiques, gestion |
| /27 | 255.255.255.224 | 32 | 30 | Réseau de gestion, petit bureau |
| /26 | 255.255.255.192 | 64 | 62 | VLAN départemental, segment serveurs |
| /25 | 255.255.255.128 | 128 | 126 | Sous-réseau serveurs moyen |
| /24 | 255.255.255.0 | 256 | 254 | LAN standard, VLAN type |
| /23 | 255.255.254.0 | 512 | 510 | Grand LAN, campus |
| /22 | 255.255.252.0 | 1 024 | 1 022 | Campus, WiFi d’entreprise |
| /21 | 255.255.248.0 | 2 048 | 2 046 | Grand campus |
| /20 | 255.255.240.0 | 4 096 | 4 094 | FAI, fournisseur cloud |
| /19 | 255.255.224.0 | 8 192 | 8 190 | Bloc FAI |
| /18 | 255.255.192.0 | 16 384 | 16 382 | Bloc FAI |
| /17 | 255.255.128.0 | 32 768 | 32 766 | Bloc FAI |
| /16 | 255.255.0.0 | 65 536 | 65 534 | Grand réseau d’entreprise |
| /12 | 255.240.0.0 | 1 048 576 | 1 048 574 | Plage privée Classe B (172.16.0.0/12) |
| /8 | 255.0.0.0 | 16 777 216 | 16 777 214 | Plage privée Classe A (10.0.0.0/8) |
| /0 | 0.0.0.0 | 4 294 967 296 | — | Route par défaut |
* Le masque /31, défini dans la RFC 3021, ne réserve ni adresse réseau ni adresse de broadcast. Son usage est largement supporté sur les routeurs modernes et permet d’économiser une adresse par rapport au /30 sur chaque liaison point à point — ce qui compte lorsqu’on gère des centaines d’interconnexions dans un datacenter.
Conversion décimal vers binaire : les valeurs présentes dans chaque octet
| Décimal | Binaire | Bits réseau |
|---|---|---|
| 0 | 00000000 | 0 |
| 128 | 10000000 | 1 |
| 192 | 11000000 | 2 |
| 224 | 11100000 | 3 |
| 240 | 11110000 | 4 |
| 248 | 11111000 | 5 |
| 252 | 11111100 | 6 |
| 254 | 11111110 | 7 |
| 255 | 11111111 | 8 |
Ce sont les seules valeurs valides pouvant apparaître dans un octet de masque de sous-réseau. Si quelqu’un configure une valeur différente (par exemple 255.255.255.200), la configuration est incorrecte.
Les masques les plus utilisés en environnement professionnel
Tous les masques ne sont pas utilisés avec la même fréquence. Dans la pratique du datacenter et de l’infrastructure cloud, voici ceux qui reviennent sans cesse :
/24 — Le masque standard
Le plus courant dans les réseaux locaux et les VLANs. Il offre 254 hôtes, ce qui le rend adapté à la plupart des segments d’un réseau d’entreprise : postes de travail, serveurs d’un rack, réseaux de gestion ou VLANs de stockage.
Exemple : 10.10.5.0/24 couvre de 10.10.5.1 à 10.10.5.254, avec broadcast à 10.10.5.255.
/25 — Diviser un /24 en deux
Lorsqu’un /24 est trop grand et qu’il faut séparer deux environnements (par exemple production et pré-production), un /25 divise le bloc en deux sous-réseaux de 126 hôtes chacun.
| Sous-réseau | Plage | Hôtes |
|---|---|---|
| 10.10.5.0/25 | .1 – .126 | 126 |
| 10.10.5.128/25 | .129 – .254 | 126 |
/26 — Quatre segments par /24
Idéal pour séparer les VLANs au sein d’un même bloc quand des segments plus petits sont nécessaires : réseau serveurs, réseau de gestion, réseau de supervision et réseau utilisateurs, chacun avec jusqu’à 62 hôtes.
| Sous-réseau | Adresse réseau | Premier hôte | Dernier hôte | Broadcast |
|---|---|---|---|---|
| 1 | 10.10.5.0/26 | 10.10.5.1 | 10.10.5.62 | 10.10.5.63 |
| 2 | 10.10.5.64/26 | 10.10.5.65 | 10.10.5.126 | 10.10.5.127 |
| 3 | 10.10.5.128/26 | 10.10.5.129 | 10.10.5.190 | 10.10.5.191 |
| 4 | 10.10.5.192/26 | 10.10.5.193 | 10.10.5.254 | 10.10.5.255 |
/27 — Segments de 30 hôtes
Très utilisé pour les réseaux de gestion (iDRAC/IPMI, commutateurs, PDU intelligents) où il n’y a que quelques dizaines de dispositifs et où un domaine de broadcast réduit est souhaitable.
/28 — Petits blocs d’IPs publiques
Lorsqu’un fournisseur attribue un bloc d’IPs publiques à un client, /28 (14 hôtes) est l’une des unités les plus fréquentes. Également utilisé pour les DMZ avec peu de services exposés.
/30 et /31 — Liaisons point à point
Dans tout réseau de datacenter comportant plusieurs routeurs ou pare-feu interconnectés, les liaisons entre eux utilisent /30 (2 hôtes) ou /31 (2 hôtes sans gaspillage). Dans une infrastructure avec 50 interconnexions, la différence entre /30 et /31 représente 50 adresses IP économisées — un chiffre qui compte à grande échelle.
/32 — L’hôte individuel
Ce n’est pas un « sous-réseau » au sens strict : il identifie une seule adresse IP. Utilisé dans les routes hôte (routes statiques vers un hôte précis), les règles de pare-feu spécifiques, les interfaces loopback de routeurs et l’attribution d’IPs dans les réseaux point à multipoint.
Conception réseau avec VLSM : un exemple concret
Dans une infrastructure de production, les sous-réseaux ont rarement tous besoin de la même taille. La technique VLSM (Variable Length Subnet Mask — masque de sous-réseau à longueur variable) permet d’attribuer à chaque segment exactement le masque dont il a besoin, en optimisant l’utilisation des adresses.
Scénario : Une entreprise dispose du bloc 172.16.10.0/24 et a besoin de :
- Serveurs de production : 100 hôtes
- Réseau utilisateurs : 50 hôtes
- Réseau de gestion/IPMI : 20 hôtes
- DMZ : 10 hôtes
- Deux liaisons WAN : 2 hôtes chacune
L’attribution — en commençant toujours par le plus grand sous-réseau — serait :
| Segment | Hôtes nécessaires | CIDR | Masque | Hôtes disponibles | Réseau attribué |
|---|---|---|---|---|---|
| Production | 100 | /25 | 255.255.255.128 | 126 | 172.16.10.0/25 |
| Utilisateurs | 50 | /26 | 255.255.255.192 | 62 | 172.16.10.128/26 |
| Gestion | 20 | /27 | 255.255.255.224 | 30 | 172.16.10.192/27 |
| DMZ | 10 | /28 | 255.255.255.240 | 14 | 172.16.10.224/28 |
| WAN 1 | 2 | /30 | 255.255.255.252 | 2 | 172.16.10.240/30 |
| WAN 2 | 2 | /30 | 255.255.255.252 | 2 | 172.16.10.244/30 |
Sur les 256 adresses du bloc d’origine, 238 sont utilisées avec un gaspillage minimal. Sans VLSM, il faudrait attribuer un /24 à chaque segment, soit six blocs /24 au lieu d’un seul.
Masque inversé (wildcard) : l’autre face du masque de sous-réseau
Dans les configurations d’ACL (listes de contrôle d’accès) sur les routeurs et commutateurs, et dans des protocoles comme OSPF, le masque de sous-réseau n’est pas utilisé directement. On utilise à la place son inverse : le masque inversé ou wildcard mask.
Le calcul est simple : 255.255.255.255 - masque de sous-réseau = wildcard.
| Masque de sous-réseau | Wildcard |
|---|---|
| 255.255.255.255 (/32) | 0.0.0.0 |
| 255.255.255.252 (/30) | 0.0.0.3 |
| 255.255.255.240 (/28) | 0.0.0.15 |
| 255.255.255.0 (/24) | 0.0.0.255 |
| 255.255.0.0 (/16) | 0.0.255.255 |
Exemple d’ACL Cisco : Autoriser le trafic du réseau serveurs 172.16.10.0/25 :
access-list 100 permit ip 172.16.10.0 0.0.0.127 any
Exemple OSPF : Annoncer le réseau de gestion 172.16.10.192/27 :
router ospf 1
network 172.16.10.192 0.0.0.31 area 0
Formules de calcul rapide
Deux formules à connaître par cœur :
Hôtes utilisables par sous-réseau :
2^(32 - préfixe_CIDR) - 2
Nombre de sous-réseaux lors de la division d’un bloc :
2^(nouveau_préfixe - préfixe_original)
Exemples rapides :
- Combien d’hôtes dans un /27 ? → 2^(32-27) – 2 = 30
- En combien de /28 puis-je diviser un /24 ? → 2^(28-24) = 16 sous-réseaux
- J’ai besoin d’au moins 500 hôtes : 2^n ≥ 502 → n = 9 → /23
Agrégation de routes (supernetting)
Le CIDR ne permet pas seulement de diviser les réseaux en sous-réseaux plus petits — il permet aussi d’agréger plusieurs réseaux en une annonce plus large. C’est essentiel pour maintenir les tables de routage à une taille gérable, en particulier en BGP.
Exemple : Au lieu d’annoncer quatre routes distinctes :
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
On peut annoncer une seule route résumée : 192.168.0.0/22, réduisant la charge sur les routeurs voisins. Cela ne fonctionne que si les réseaux sont contigus et alignés sur une frontière en puissance de 2.
Adresses privées (RFC 1918) et CGNAT
Trois blocs d’adresses sont réservés à un usage interne et ne sont pas routés sur Internet :
| Bloc | CIDR | Total d’hôtes | Usage courant |
|---|---|---|---|
| 10.0.0.0 – 10.255.255.255 | 10.0.0.0/8 | 16 777 214 | Grands réseaux d’entreprise, cloud privé, datacenters |
| 172.16.0.0 – 172.31.255.255 | 172.16.0.0/12 | 1 048 574 | Réseaux de taille moyenne, segments d’infrastructure |
| 192.168.0.0 – 192.168.255.255 | 192.168.0.0/16 | 65 534 | Réseaux domestiques, petits bureaux |
Par ailleurs, le bloc 100.64.0.0/10 est réservé au CGNAT (Carrier-Grade NAT, RFC 6598), une technique utilisée par les FAI pour partager des IPs publiques entre plusieurs clients. Il est important de ne pas utiliser cette plage dans ses propres réseaux internes afin d’éviter les conflits.
Bref historique : des réseaux plats au CIDR
L’adressage IP n’a pas toujours fonctionné de cette manière :
Années 1970 : Les réseaux IP étaient plats. On supposait systématiquement 8 bits pour le réseau et 24 pour l’hôte. Seuls 256 réseaux étaient possibles sur l’ensemble d’Internet.
1981 (RFC 791) : Jon Postel introduit les classes A, B et C. Le masque était implicitement déduit de la classe. Le problème : une organisation de taille moyenne avait besoin d’une Classe B (65 534 hôtes) car la Classe C (254 hôtes) était insuffisante, gaspillant des milliers d’adresses.
1985 (RFC 950) : Les masques de sous-réseau sont formalisés, permettant de diviser les réseaux en sous-réseaux plus petits.
1993 (RFC 1519) : Naissance du CIDR (Classless Inter-Domain Routing), qui élimine le concept de classes et adopte le VLSM. C’est le système en vigueur aujourd’hui et celui qui a permis à IPv4 de survivre bien plus longtemps que prévu.
Un détail historique intéressant : dans les premières années, les masques n’exigeaient pas des bits contigus. Un masque comme 255.255.192.128 était parfaitement valide. Cette pratique a été abandonnée au début des années 1990 car elle rendait le routage par longest prefix match techniquement impraticable.
Masques de sous-réseau en IPv6
En IPv6, la notation décimale du masque n’existe pas. Seule la notation de préfixe, équivalente au CIDR, est utilisée :
2001:0db8:85a3::1/64
Le préfixe le plus courant est /64 pour les réseaux locaux (2^64 = 18,4 trillions d’adresses par sous-réseau — largement suffisant pour tout scénario). Les FAI reçoivent des blocs /32 ou /48 de la part des registres régionaux (RIPE, ARIN, LACNIC, etc.).
En pratique, la planification des sous-réseaux en IPv6 est plus simple qu’en IPv4 : l’abondance d’adresses supprime le besoin du découpage fin qui rend la maîtrise du VLSM indispensable en IPv4.
Vérifier son masque de sous-réseau : commandes rapides
Linux (le masque apparaît en notation CIDR) :
ip addr show
# Exemple de sortie : inet 10.10.5.45/24 brd 10.10.5.255 scope global eth0
Windows :
ipconfig
# Chercher : Masque de sous-réseau . . . . : 255.255.255.0
macOS :
ifconfig en0
# Chercher : netmask 0xffffff00 (hexadécimal de 255.255.255.0)
Sur un commutateur ou routeur Cisco :
show ip interface brief
show running-config interface Vlan10
Erreurs fréquentes de configuration
Voici les problèmes les plus courants constatés lors d’audits réseau — à connaître pour les éviter :
Masques incohérents sur un même VLAN. Si un serveur a un /24 et un autre un /25 sur le même réseau physique, une partie de la plage sera injoignable pour l’un d’entre eux. C’est une source classique de problèmes « ça marche parfois » notoirement difficiles à diagnostiquer.
Sous-réseaux chevauchants. Lorsqu’on attribue manuellement des blocs avec VLSM sans plan précis, il est facile que deux sous-réseaux se superposent. La conséquence : des paquets qui arrivent à la mauvaise destination ou des routes ambiguës.
Utiliser /24 par défaut quand ce n’est pas nécessaire. Une liaison WAN entre deux routeurs n’a pas besoin de 254 adresses. Un /30 ou /31 est le bon choix ; utiliser /24 gaspille 252 IPs par liaison.
Oublier de soustraire 2 pour le calcul des hôtes. L’adresse réseau (tous les bits hôte à 0) et l’adresse de broadcast (tous à 1) ne sont pas attribuables. Un /24 offre 254 hôtes, pas 256. Un /30 en offre 2, pas 4.
Oublier de mettre à jour la passerelle et le DNS. Lorsqu’on modifie un masque, la passerelle par défaut et les règles de pare-feu doivent refléter le nouveau schéma. Changer un masque sans vérifier la passerelle est une panne assurée.
Masques de sous-réseau dans le contexte du cloud privé
Dans les environnements de cloud privé et de bare metal, la conception des sous-réseaux est l’une des premières décisions architecturales. Le choix des masques affecte directement l’évolutivité, l’isolation du trafic et la complexité opérationnelle.
Une conception type en infrastructure de datacenter utilise des VLANs séparés avec des masques adaptés à chaque fonction :
| VLAN | Fonction | Masque type | Pourquoi |
|---|---|---|---|
| VLAN 10 | Production | /24 ou /23 | Espace suffisant pour les serveurs et la croissance |
| VLAN 20 | Gestion/IPMI | /27 ou /28 | Peu de dispositifs, isolation critique |
| VLAN 30 | Stockage (iSCSI/NFS) | /24 | Trafic dédié, MTU jumbo, sans passerelle |
| VLAN 40 | Sauvegarde | /24 | Séparé du trafic de production |
| VLAN 50 | DMZ | /28 ou /27 | Uniquement les services exposés, pare-feu strict |
| VLAN 100 | Interconnexion routeurs | /31 par liaison | Utilisation maximale des IPs |
Ce type de conception, associé à des règles de pare-feu inter-VLANs et une documentation rigoureuse du plan d’adressage, est ce qui distingue une infrastructure professionnelle d’un déploiement improvisé.
Chez Stackscale, la gestion réseau est conçue pour que chaque client dispose de segments correctement dimensionnés et isolés, avec une redondance au niveau réseau et une connectivité vers de multiples opérateurs. Si vous planifiez un déploiement nécessitant une conception réseau sur mesure, notre équipe peut vous aider à dimensionner les sous-réseaux, VLANs et règles de segmentation les mieux adaptés à votre cas d’usage.