Notation CIDR et masques de sous-réseau : comment lire de /8 à /32
Le nombre placé après la barre oblique dans 192.168.1.0/24 compte des bits, pas des adresses. Il indique combien des 32 bits d’une adresse IPv4 appartiennent au réseau ; tout ce qui reste appartient aux hôtes.
Le reste en découle. Un /24 laisse 8 bits d’hôte, donc le bloc contient 2⁸ = 256 adresses. Un /26 n’en laisse que 6, donc il en contient 64. Chaque bit rendu au côté hôte double le bloc ; chaque bit repris double le nombre de blocs. Le nombre que vous pouvez réellement attribuer à des équipements est normalement inférieur de deux au total, parce que la première adresse désigne le réseau et la dernière est le broadcast. Un /26 vous donne 62 hôtes utilisables, pas 64.
Deux préfixes enfreignent volontairement cette règle du moins deux, et un masque générique (wildcard mask) n’est pas un masque de sous-réseau, même si on ne cesse de coller l’un dans le champ de l’autre. Ces deux points reviennent plus bas, après le calcul du masque à la main. Si vous voulez seulement la réponse pour un bloc précis, le calculateur de sous-réseau l’affiche ; cet article explique comment y arriver sans lui.
Ce que dit vraiment la notation CIDR
Un masque de sous-réseau est lui-même un nombre de 32 bits, écrit comme on écrit une adresse. Ses bits forment une suite de 1 suivie d’une suite de 0. Les 1 marquent les bits de réseau, les 0 marquent les bits d’hôte. Écrivez un /26 en entier et vous obtenez :
11111111.11111111.11111111.11000000
255 . 255 . 255 . 192Reconvertissez chaque octet en décimal et cela donne 255.255.255.192. La notation CIDR compte les 1 de tête au lieu d’écrire les trente-deux bits un par un. 192.168.1.0/26 et 192.168.1.0 255.255.255.192 énoncent la même chose dans deux syntaxes, et le choix dépend entièrement de la commande que vous êtes en train de taper.
Le compte fait tout le travail. /8, /16 et /24 tombent sur des frontières d’octet, ce qui explique leur allure bien rangée en décimal : 255.0.0.0, 255.255.0.0, 255.255.255.0. Rien dans la notation ne l’exige. /22 et /27 sont tout aussi valides. Ils coupent au milieu d’un octet et produisent des masques comme 255.255.252.0, qui semblent arbitraires jusqu’au moment où vous les écrivez en binaire.
Avant 1993, les bits de tête d’une adresse décidaient de sa taille : la classe A prenait un /8, la classe B un /16, la classe C un /24, et il n’y avait rien entre les deux. Une organisation de 300 hôtes devait réclamer une classe B et gaspiller plus de 65000 adresses, ou prendre deux blocs de classe C et porter deux routes. CIDR (RFC 1519, révisée plus tard par la RFC 4632) a rompu ce couplage. Le préfixe voyage avec l’adresse, donc un bloc peut valoir n’importe quelle puissance de deux. Les classes reviennent encore dans les examens de certification et dans les vieilles documentations, mais le routage par classes est obsolète depuis l’arrivée de CIDR en 1993 : c’est le masque qui décide où s’arrête un réseau, pas le premier octet.
L’aide-mémoire des masques de sous-réseau, de /8 à /32
La dernière colonne du tableau n’est pas une erreur : elle montre ce que produit la formule générique 2ⁿ − 2, qui donne le nombre réellement utilisable partout, sauf sur les deux dernières lignes.
| Préfixe | Masque de sous-réseau | Masque générique | Total d’adresses | Hôtes utilisables | La formule naïve 2ⁿ − 2 donne |
|---|---|---|---|---|---|
| /8 | 255.0.0.0 | 0.255.255.255 | 16777216 | 16777214 | 16777214 |
| /9 | 255.128.0.0 | 0.127.255.255 | 8388608 | 8388606 | 8388606 |
| /10 | 255.192.0.0 | 0.63.255.255 | 4194304 | 4194302 | 4194302 |
| /11 | 255.224.0.0 | 0.31.255.255 | 2097152 | 2097150 | 2097150 |
| /12 | 255.240.0.0 | 0.15.255.255 | 1048576 | 1048574 | 1048574 |
| /13 | 255.248.0.0 | 0.7.255.255 | 524288 | 524286 | 524286 |
| /14 | 255.252.0.0 | 0.3.255.255 | 262144 | 262142 | 262142 |
| /15 | 255.254.0.0 | 0.1.255.255 | 131072 | 131070 | 131070 |
| /16 | 255.255.0.0 | 0.0.255.255 | 65536 | 65534 | 65534 |
| /17 | 255.255.128.0 | 0.0.127.255 | 32768 | 32766 | 32766 |
| /18 | 255.255.192.0 | 0.0.63.255 | 16384 | 16382 | 16382 |
| /19 | 255.255.224.0 | 0.0.31.255 | 8192 | 8190 | 8190 |
| /20 | 255.255.240.0 | 0.0.15.255 | 4096 | 4094 | 4094 |
| /21 | 255.255.248.0 | 0.0.7.255 | 2048 | 2046 | 2046 |
| /22 | 255.255.252.0 | 0.0.3.255 | 1024 | 1022 | 1022 |
| /23 | 255.255.254.0 | 0.0.1.255 | 512 | 510 | 510 |
| /24 | 255.255.255.0 | 0.0.0.255 | 256 | 254 | 254 |
| /25 | 255.255.255.128 | 0.0.0.127 | 128 | 126 | 126 |
| /26 | 255.255.255.192 | 0.0.0.63 | 64 | 62 | 62 |
| /27 | 255.255.255.224 | 0.0.0.31 | 32 | 30 | 30 |
| /28 | 255.255.255.240 | 0.0.0.15 | 16 | 14 | 14 |
| /29 | 255.255.255.248 | 0.0.0.7 | 8 | 6 | 6 |
| /30 | 255.255.255.252 | 0.0.0.3 | 4 | 2 | 2 |
| /31 | 255.255.255.254 | 0.0.0.1 | 2 | 2 | 0 |
| /32 | 255.255.255.255 | 0.0.0.0 | 1 | 1 | −1 |
Lisez ce tableau comme un jeu de relations plutôt que comme une liste de réponses. Chaque ligne vers le bas divise le bloc par deux : un /24 contient 256 adresses, un /25 en contient 128, un /26 en contient 64. La colonne du masque générique est le masque de sous-réseau avec tous ses bits inversés, ce qui explique que 255.255.255.192 et 0.0.0.63 apparaissent toujours sur la même ligne. Les deux lignes en gras, elles, marquent l’endroit où la formule standard cesse de décrire la réalité ; la section sur la règle du moins deux dit pourquoi.
Seules les valeurs du dernier octet de la colonne des masques méritent d’être apprises par cœur, parce qu’elles reviennent toujours : 128, 192, 224, 240, 248, 252, 254, 255. Ce sont les huit seules valeurs d’octet non triviales sur lesquelles un masque valide peut se terminer. Pour voir pourquoi, convertissez-les vous-même : le convertisseur de base affiche n’importe laquelle d’entre elles en binaire.
Lire le tableau à l’envers : du masque de sous-réseau au CIDR
À partir d’un masque en décimal pointé, comptez les bits à 1. Chaque 255 en apporte 8, et le seul octet intéressant apporte le reste :
| Dernier octet du masque | 128 | 192 | 224 | 240 | 248 | 252 | 254 | 255 |
|---|---|---|---|---|---|---|---|---|
| Bits ajoutés | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
Donc 255.255.255.192 vaut 8 + 8 + 8 + 2 = /26. Et 255.255.252.0 vaut 8 + 8 + 6 + 0 = /22, parce que 252 s’écrit 11111100 en binaire.
Tout octet qui n’est ni 255 ni 0 est l’octet frontière, et un masque valide ne peut jamais en avoir qu’un seul. La valeur de cet octet donne aussi directement la taille de bloc, qui est le point de départ du calcul à la main.
Calculer un masque de sous-réseau et un réseau à la main
La méthode mécanique tient en trois étapes et fonctionne pour n’importe quel préfixe. L’exemple traité ci-dessous utilise 192.168.1.130/26, mais ce qui compte est la procédure, pas cette adresse.
Étape 1 : trouver la taille de bloc
La taille de bloc vaut 256 − l'octet frontière du masque.
Pour un /26, le masque est 255.255.255.192, donc la taille de bloc vaut 256 − 192 = 64. Les sous-réseaux de cette taille se placent sur les multiples de 64 dans le quatrième octet : 0, 64, 128, 192. Il n’existe aucun autre point de départ possible.
La taille de bloc et le nombre d’adresses sont le même nombre, obtenu depuis le masque au lieu du compte de bits.
Étape 2 : trouver dans quel bloc tombe l’adresse
Divisez l’octet frontière de l’adresse par la taille de bloc et arrondissez à l’entier inférieur.
L’adresse est 192.168.1.130, la taille de bloc est 64, donc 130 ÷ 64 = 2.03…, ce qui s’arrondit à 2. Multipliez en retour : 2 × 64 = 128. L’adresse se trouve dans le bloc qui commence à 128.
C’est ici que se produisent la plupart des erreurs, toujours dans le même sens : on suppose que l’adresse qu’on vous a donnée est le début de son bloc, et ce n’est généralement pas le cas. 192.168.1.130 est une adresse d’hôte qui vit dans le troisième /26 de ce /24.
Étape 3 : réseau, broadcast, premier et dernier hôte
Le début du bloc est l’adresse de réseau. Le broadcast est le début du bloc plus la taille de bloc moins un. Tout ce qui se trouve strictement entre les deux est attribuable :
Network 192.168.1.128
Broadcast 192.168.1.191
Usable 192.168.1.129 - 192.168.1.190
Usable 62 (of 64 total)
Netmask 255.255.255.192
Wildcard 0.0.0.63Le broadcast vaut 128 + 64 − 1 = 191. Le premier hôte est le réseau + 1, le dernier hôte est le broadcast − 1, et le nombre utilisable est 64 − 2 = 62, ce qui correspond à la ligne /26 de l’aide-mémoire.
En une phrase : la taille de bloc vaut 256 moins l’octet du masque ; arrondissez l’adresse au multiple inférieur de cette taille ; c’est votre réseau, et le début du bloc suivant moins un est votre broadcast.
La méthode n’est pas propre au quatrième octet. Pour un /22, le masque est 255.255.252.0, donc l’octet frontière est le troisième et la taille de bloc y vaut 256 − 252 = 4. Les blocs commencent donc à 10.0.0.0, 10.0.4.0, 10.0.8.0, et le bloc 10.0.0.0/22 va jusqu’au broadcast 10.0.3.255 avec les adresses utilisables 10.0.0.1 à 10.0.3.254, soit quatre /24 consécutifs à l’intérieur d’un seul domaine de broadcast. Mêmes trois étapes, autre octet.
Si c’est le passage du binaire au décimal qui vous ralentit, le guide de la conversion de bases traite la conversion elle-même plus en profondeur qu’un article sur le découpage en sous-réseaux ne devrait le faire.
Pour vérifier votre travail dans un script plutôt que dans votre tête, la bibliothèque standard de Python sait déjà tout cela :
import ipaddress
net = ipaddress.ip_network("192.168.1.130/26", strict=False)
print(net) # 192.168.1.128/26
print(net.network_address) # 192.168.1.128
print(net.broadcast_address) # 192.168.1.191
print(net.netmask) # 255.255.255.192
print(net.hostmask) # 0.0.0.63
print(net.num_addresses) # 64
print(len(list(net.hosts()))) # 62strict=False vous laisse passer une adresse d’hôte au lieu d’une adresse de réseau ; avec la valeur par défaut strict=True, le même appel lève ValueError.
Là où la règle du moins deux cesse d’être vraie
La soustraction a une raison d’être. Dans un sous-réseau ordinaire, le motif d’hôte tout à zéro désigne le réseau lui-même et le motif tout à un est l’adresse de broadcast dirigé. Aucun des deux ne peut être configuré sur une interface, donc un bloc de 2ⁿ adresses en offre 2ⁿ − 2 aux hôtes. C’est pourquoi un /24 en donne 254 et un /26 en donne 62.
La raison est aussi la limite : quand un bloc est trop petit pour contenir ces deux adresses réservées, les soustraire n’a plus de sens.
Un /31 a deux adresses et deux hôtes utilisables. La RFC 3021 définit le /31 pour les liaisons point à point. Une telle liaison a exactement deux extrémités et aucun segment partagé : une adresse de broadcast n’y sert à rien et une adresse de réseau n’y a rien à identifier. Les deux adresses vont aux deux extrémités. Appliquer 2ⁿ − 2 ici renvoie 0, parce que la formule répond à une question qui ne se pose pas sur ce type de liaison. La condition qui l’accompagne est réelle : le /31 n’est valide que sur des interfaces véritablement point à point. Un segment LAN multi-accès a toujours besoin d’un /30 ou plus court, et Windows refuse un /31 sur une carte réseau.
Un /32 a une adresse et un hôte utilisable. C’est une route d’hôte unique : interfaces de loopback, routes statiques, adresses anycast, règles de pare-feu sur une adresse unique. Il n’y a pas d’adresse de broadcast, donc le − 2 de la formule renverrait −1.
Python confirme les deux :
import ipaddress
p2p = ipaddress.ip_network("203.0.113.4/31")
print([str(h) for h in p2p.hosts()]) # ['203.0.113.4', '203.0.113.5']
host = ipaddress.ip_network("10.0.0.1/32")
print([str(h) for h in host.hosts()]) # ['10.0.0.1']Plutôt que de mémoriser deux exceptions, retenez ce que fait la soustraction : elle retire deux adresses précises, et il faut vérifier qu’elles existent avant de les retirer. Un /31 et un /32 n’ont aucune adresse de broadcast, donc il n’y a rien à retirer.
Total, utilisables et nombre de sous-réseaux sont trois nombres différents
On confond les trois en permanence, et la confusion se comprend : ce sont toutes des puissances de deux dérivées du même préfixe.
- Le total d’adresses d’un /p vaut
2^(32 − p). Pour un /26 : 64. - Les hôtes utilisables, c’est ce total moins 2, sauf pour /31 et /32. Pour un /26 : 62.
- Le nombre de sous-réseaux obtenu en découpant un /p parent en enfants /q vaut
2^(q − p). Découper un /24 en /26 emprunte deux bits, donc2² = 4sous-réseaux.
Les trois répondent à des questions différentes, si bien qu’une phrase comme « un /26 vous en donne 4 » n’est vraie que si la question portait sur le découpage d’un /24. Le découpage vous coûte aussi des adresses, parce que chaque sous-réseau enfant réserve son propre couple réseau/broadcast. Quatre /26 taillés dans un /24 contiennent 4 × 62 = 248 adresses utilisables face aux 254 du parent : six adresses parties dans le découpage lui-même.
Masque générique et masque de sous-réseau : quelle commande veut lequel
Un masque générique est l’inverse bit à bit du masque de sous-réseau. Là où le masque de sous-réseau a des 1, le masque générique a des 0. Prenez la ligne /26 de l’aide-mémoire : masque 255.255.255.192, masque générique 0.0.0.63. Inversez chaque bit de l’un et vous obtenez l’autre, si bien qu’ils vont toujours par paire.
Les deux s’emploient pourtant dans des sens opposés. Un masque de sous-réseau s’applique avec un ET bit à bit, donc un bit à 1 signifie « ce bit fait partie du réseau ». Un masque générique est un filtre de correspondance, donc un bit à 0 signifie « ce bit doit correspondre » et un bit à 1 signifie « peu importe ». Même opération sous-jacente, polarité inverse. Si la mécanique au niveau des bits reste floue, le guide des opérations bit à bit traite le ET, le OU et le NON de façon plus générale.
Le choix entre les deux n’est pas affaire de préférence. Pour le bloc 192.168.1.128/26 :
! wants the subnet mask
ip address 192.168.1.129 255.255.255.192
! wants the wildcard mask
access-list 10 permit 192.168.1.128 0.0.0.63
network 192.168.1.128 0.0.0.63 area 0! Cisco ASA — wants the subnet mask, unlike IOS ACLs
access-list OUT permit ip 192.168.1.128 255.255.255.192 any# Linux iproute2 — takes the prefix directly
ip addr add 192.168.1.129/26 dev eth0Les ACL Cisco IOS et les instructions network d’OSPF prennent le masque générique ; l’ASA prend le masque de sous-réseau à la place. Un seul constructeur, deux conventions dans la même famille de produits : de là vient l’erreur de copier-coller la plus fréquente du domaine. D’autres plateformes ont leurs propres conventions : avant de coller une valeur dans un champ que vous ne connaissez pas, vérifiez lequel des deux ce champ attend.
Le mode de défaillance est ce qui rend la chose dangereuse. Collez 255.255.255.192 dans une ACL IOS et le routeur le lit comme un masque générique : trois octets entièrement à 1 signifient « peu importe », donc les trois premiers octets cessent complètement d’être comparés et la règle porte bien au-delà du bloc que vous aviez en tête. Aucune erreur de syntaxe, aucune ligne de journal, juste une instruction permit avec la mauvaise portée. L’erreur inverse a au moins une chance d’être repérée, parce que 0.0.0.63 n’est pas un masque de sous-réseau valide, puisqu’il n’a pas de suite de 1 en tête. Savoir si une plateforme donnée le rejette ou l’accepte en silence n’est pas une chose à découvrir en production.
Pourquoi les masques génériques d’ACL peuvent avoir des trous, mais pas les masques de sous-réseau
Un masque de sous-réseau doit être une suite contiguë de 1 suivie de 0. Ce n’est pas une convention, c’est ce qui permet à l’opération ET de découper une adresse en exactement deux parties. Une valeur comme 255.0.255.0 comporte un trou, ne décrit aucune frontière cohérente, et les équipements la rejettent. Python aussi :
import ipaddress
ipaddress.ip_network("10.0.0.0/255.0.255.0")
# ValueError: '10.0.0.0/255.0.255.0' does not appear to be an IPv4 or IPv6 networkSeuls 33 masques sont valides, de /0 à /32. Tout le reste est une faute de frappe.
Les masques génériques d’ACL ne sont soumis à aucune contrainte de ce genre, parce qu’ils ne découpent pas une adresse en une partie réseau et une partie hôte. Ce sont des filtres de correspondance bit par bit, où les trous sont légaux et parfois utiles ; un seul masque générique à trou peut par exemple faire correspondre toutes les adresses impaires d’une plage. Cette différence d’expressivité explique pourquoi les deux valeurs ne sont pas interchangeables : ce ne sont pas des objets de même nature, elles se ressemblent simplement en décimal pointé.
Plages privées, CGNAT et autres plages réservées
Un préfixe vous dit quelle est la taille d’un bloc. C’est l’identité du bloc qui vous dit s’il est à vous.
| Bloc | Plage | Réservé par |
|---|---|---|
| 10.0.0.0/8 | 10.0.0.0 – 10.255.255.255 | RFC 1918, privée |
| 172.16.0.0/12 | 172.16.0.0 – 172.31.255.255 | RFC 1918, privée |
| 192.168.0.0/16 | 192.168.0.0 – 192.168.255.255 | RFC 1918, privée |
| 100.64.0.0/10 | 100.64.0.0 – 100.127.255.255 | RFC 6598, NAT de fournisseur (CGNAT) |
| 169.254.0.0/16 | 169.254.0.0 – 169.254.255.255 | RFC 3927, lien-local |
| 255.255.255.255/32 | adresse unique | broadcast limité |
Les plages RFC 1918 ne sont jamais routées sur l’internet public, ce qui permet d’y puiser des allocations sans craindre de collision. Les trois autres lignes du tableau sont là pour d’autres raisons.
100.64.0.0/10 est l’espace du NAT de fournisseur. Si votre FAI vous attribue une adresse dedans, vous êtes derrière son NAT et aucune connexion entrante ne vous atteindra sans tunnel. Ce n’est pas de l’espace privé au sens de la RFC 1918, et il n’est pas à vous dans un plan d’adressage interne, parce que votre opérateur l’utilise peut-être déjà de l’autre côté de votre routeur.
169.254.0.0/16 est du lien-local. Un hôte s’en attribue une lui-même quand DHCP échoue, si bien qu’une adresse en 169.254 sur une interface est un diagnostic plutôt qu’une configuration : rien n’a répondu à la requête DHCP. Le trafic vers ces adresses ne traverse jamais un routeur.
Pour les exemples dans la documentation et les procédures d’exploitation, la RFC 5737 réserve 192.0.2.0/24, 198.51.100.0/24 et 203.0.113.0/24 précisément pour qu’un exemple copié-collé ne puisse pas pointer vers un hôte réel.
172.16.0.0/12, ce sont seize /16, pas un seul
C’est la plage réservée sur laquelle on se trompe le plus, et le préfixe en est la cause. Un /12 emprunte quatre bits au deuxième octet, donc le bloc s’étend de 172.16.0.0 à 172.31.255.255, soit seize /16 consécutifs et pas seulement 172.16.x.x.
Les conséquences vont dans les deux sens. Une adresse comme 172.20.5.1 est privée, confortablement installée dans la plage, même si elle ne commence pas par 172.16. Et 172.15.x.x et 172.32.x.x sont des adresses publiques appartenant à quelqu’un d’autre : une règle de pare-feu ou une vérification du genre « faire confiance à la plage interne » écrite contre 172.0.0.0/8 accorde donc discrètement sa confiance à une large tranche d’internet.
Si vous devez confirmer une frontière de ce genre, l’aide-mémoire vous donne l’arithmétique : un /12 a 2^(32−12) adresses, le deuxième octet avance par pas de 256 − 240 = 16, et 16 + 16 = 32, donc le bloc s’arrête juste avant 172.32.0.0.
VLSM : découper un bloc en sous-réseaux inégaux
Les sous-réseaux de taille égale sont faciles et généralement inadaptés. Une agence à qui l’on donne un seul 192.168.1.0/24 peut avoir besoin de quatre segments de tailles très différentes : une centaine de postes de travail, cinquante téléphones, une douzaine de serveurs et une poignée d’interfaces d’administration. Découpez le /24 en quatre /26 égaux et le segment des postes déborde à 62 hôtes, pendant que le segment d’administration occupe 62 adresses pour desservir dix équipements.
Le VLSM (Variable Length Subnet Masking, masquage de sous-réseau à longueur variable) consiste à donner à chaque segment le préfixe dont il a réellement besoin. Voici le même /24 taillé en un /25, un /26 et deux /28.
Allouez du plus grand au plus petit. Chaque bloc doit commencer sur un multiple de sa propre taille, donc le plus gros bloc choisit en premier :
| Segment | Hôtes nécessaires | Préfixe | Réseau | Plage utilisable | Broadcast | Masque de sous-réseau |
|---|---|---|---|---|---|---|
| Postes de travail | 100 | /25 | 192.168.1.0 | 192.168.1.1 – 192.168.1.126 | 192.168.1.127 | 255.255.255.128 |
| Téléphonie | 50 | /26 | 192.168.1.128 | 192.168.1.129 – 192.168.1.190 | 192.168.1.191 | 255.255.255.192 |
| Serveurs | 12 | /28 | 192.168.1.192 | 192.168.1.193 – 192.168.1.206 | 192.168.1.207 | 255.255.255.240 |
| Administration | 10 | /28 | 192.168.1.208 | 192.168.1.209 – 192.168.1.222 | 192.168.1.223 | 255.255.255.240 |
| non alloué | — | /27 | 192.168.1.224 | 192.168.1.225 – 192.168.1.254 | 192.168.1.255 | 255.255.255.224 |
En le déroulant avec la méthode en trois étapes :
- Le /25 a une taille de bloc de
256 − 128 = 128, donc il commence à 0 et son broadcast vaut0 + 128 − 1 = 127. Utilisables de 1 à 126, soit 126 adresses, assez pour 100 postes de travail avec de la marge. La ligne /25 de l’aide-mémoire le confirme : 128 au total, 126 utilisables. - L’adresse libre suivante est 128. Le /26 a une taille de bloc de 64, et 128 est un multiple de 64, donc il tient : réseau 192.168.1.128, broadcast
128 + 64 − 1 = 191, utilisables de 129 à 190. Cela fait 62 utilisables pour 50 téléphones. Ligne /26 de l’aide-mémoire : 64 au total, 62 utilisables. - La suivante libre est 192. Le /28 a une taille de bloc de 16, et
192 = 16 × 12, donc il tient : réseau 192.168.1.192, broadcast 207, utilisables de 193 à 206, soit 14 adresses pour 12 serveurs. L’aide-mémoire donne bien 16 adresses et 14 utilisables pour un /28. - La suivante libre est 208, et
208 = 16 × 13, donc le second /28 se pose sur 192.168.1.208 avec le broadcast 223 et les utilisables de 209 à 222.
Cela consomme 128 + 64 + 16 + 16 = 224 des 256 adresses et laisse 192.168.1.224 jusqu’à 192.168.1.255. Ces 32 adresses forment exactement un /27 aligné, d’où sortiraient plus tard les liaisons point à point : seize /31 y tiennent, un par liaison de routeur.
Supposons maintenant que vous placiez les deux /28 en bas : 192.168.1.0/28 et 192.168.1.16/28. L’adresse libre suivante est 192.168.1.32, et un /25 doit commencer sur un multiple de 128 : il ne peut donc pas démarrer là. Il doit sauter jusqu’à 192.168.1.128. Les adresses de 32 à 127 ne sont pas perdues, mais elles ne sont utilisables qu’en morceaux alignés plus petits (un /27 en 192.168.1.32 et un /26 en 192.168.1.64), si bien que l’espace restant se retrouve éparpillé au lieu de former un bloc contigu en haut de la plage. Ajoutez un segment de plus à la demande et la même manœuvre ne tient plus du tout.
Trier par taille évite cela. Après avoir placé un bloc, l’adresse libre suivante est un multiple de la taille de ce bloc, et un multiple d’une puissance de deux plus grande est automatiquement un multiple de toutes les plus petites, donc chaque bloc suivant, plus petit, est aligné là où le précédent s’est terminé. Vous n’avez jamais à sauter. Avant de valider un tel plan sur un commutateur, le passer dans la table de découpage du calculateur de sous-réseau va plus vite que de vérifier l’alignement de chaque segment à la main.
Cinq erreurs qui survivent jusqu’en production
1. Prendre l’adresse saisie pour l’adresse de réseau
Symptôme : une règle de pare-feu ne correspond à rien, ou une route couvre la mauvaise moitié d’un segment.
Cause : 192.168.1.130/26 a été lu comme réseau 192.168.1.0, broadcast 192.168.1.255, c’est-à-dire la frontière du /24, parce que c’est celle que l’on voit en décimal.
Correctif : appliquez l’étape 2. Taille de bloc 64, 130 ÷ 64 s’arrondit à 2, donc le réseau vaut 2 × 64 = 128. Le bloc va de 192.168.1.128 à 192.168.1.191, et 192.168.1.0 est un tout autre sous-réseau. Dès qu’un préfixe est plus long que /24, considérez que l’adresse qu’on vous a donnée est une adresse d’hôte tant que vous ne l’avez pas masquée.
2. Appliquer 2ⁿ − 2 à un /31
Symptôme : un outil d’IPAM ou un tableur annonce 0 hôte utilisable pour une liaison point à point qui est active et achemine du trafic. Cause : la règle du moins deux suppose qu’il existe une adresse de réseau et une adresse de broadcast à soustraire. Sur un /31, elles n’existent pas. Correctif : traitez /31 et /32 comme les conditions aux limites de la formule plutôt que comme des anomalies. La RFC 3021 rend les deux adresses d’un /31 attribuables, et un /32 est une route d’hôte unique à une seule adresse. Tout ce qui annonce 0 ou −1 a appliqué la formule hors de son domaine. Vérifiez d’abord la prise en charge du /31 sur l’interface concernée, puisque l’exception ne vaut que sur des liaisons véritablement point à point.
3. Prendre 172.16.0.0/12 pour 172.16.x.x seulement
Symptôme : un service interne est injoignable depuis une agence, ou une règle « bloquer toutes les plages privées » laisse passer du trafic. Cause : le /12 a été lu comme s’il s’agissait d’un /16. Correctif : la plage va de 172.16.0.0 à 172.31.255.255. Écrivez les ACL et les listes d’autorisation contre le préfixe 172.16.0.0/12 plutôt que contre un motif d’octet, et rappelez-vous que 172.15.x.x et 172.32.x.x se situent en dehors, sur l’internet public. Si vous comparez à la main, le deuxième octet est l’octet frontière et il avance par pas de 16.
4. Coller un masque générique dans un champ qui attend un masque de sous-réseau
Symptôme : une ACL autorise beaucoup plus, ou beaucoup moins, que prévu, et rien dans la configuration ne semble anormal. Cause : les ACL IOS et les instructions network d’OSPF prennent le masque générique tandis que l’ASA prend le masque de sous-réseau, et 0.0.0.63 et 255.255.255.192 sont visuellement interchangeables au premier coup d’œil. Correctif : vérifiez le champ avant de coller, pas après. Un indice utile : pour tout préfixe de /8 ou plus long, un masque de sous-réseau commence par 255 et un masque générique commence par 0. Si une valeur placée dans une ACL ou une instruction network d’OSPF commence par 255, c’est un masque de sous-réseau dans un champ de masque générique.
5. Écrire un masque non contigu, ou en générer un par accident
Symptôme : un équipement rejette une ligne de configuration, ou un script maison produit des masques d’apparence plausible qui sont faux. Cause : une valeur comme 255.0.255.0 n’est pas un masque de sous-réseau valide, parce qu’elle a un trou. La version scriptée est plus subtile : en JavaScript, les opérateurs de décalage prennent leur opérande droit modulo 32, donc un préfixe hors plage produit silencieusement un masque faux d’apparence plausible (33 devient /1, −1 devient /31) au lieu de lever une erreur. Correctif : validez la plage du préfixe avant de décaler, et rejetez tout masque qui n’est pas une suite pleine de 1 suivie de 0. Une bibliothèque qui lève une exception sur une entrée invalide vaut mieux ici qu’une bibliothèque qui devine, parce que les deux modes de défaillance sont silencieux.
FAQ
Quelle est la différence entre un sous-réseau et un VLAN ?
Un VLAN est un domaine de broadcast de couche 2 configuré sur les commutateurs ; un sous-réseau est une plage d’adresses de couche 3. On les fait généralement correspondre un pour un, mais rien ne l’impose : vous pouvez placer deux sous-réseaux sur un VLAN, ou faire passer un VLAN en trunk entre plusieurs sites. Renumérotez le sous-réseau et l’identifiant du VLAN, lui, ne change pas.
Combien de sous-réseaux j’obtiens en découpant un /24 en /26 ?
Quatre. Le compte vaut 2 élevé au nombre de bits empruntés, et /26 est plus long de deux bits que /24, donc 2² = 4 sous-réseaux de 64 adresses chacun. Chaque enfant réserve sa propre adresse de réseau et sa propre adresse de broadcast, donc les quatre /26 contiennent 248 adresses utilisables face aux 254 du /24 parent.
La notation CIDR fonctionne-t-elle de la même façon en IPv6 ?
La barre oblique compte toujours les bits de réseau de tête, donc /64 signifie 64 bits de réseau sur 128. Ce qui ne se transpose pas, c’est la règle du moins deux : IPv6 n’a pas d’adresse de broadcast, donc on ne soustrait rien du total. L’aide-mémoire ci-dessus et le calculateur qui l’accompagne sont exclusivement IPv4.
Que signifie 0.0.0.0/0 ?
Zéro bit de réseau, donc il correspond à toutes les adresses IPv4. Dans une table de routage, c’est la route par défaut, utilisée quand aucun préfixe plus spécifique ne correspond. Comme adresse d’écoute, cela signifie « toutes les interfaces » : un service à l’écoute sur 0.0.0.0 est joignable depuis tous les réseaux auxquels la machine est raccordée.
Que se passe-t-il si deux sous-réseaux du même réseau se chevauchent ?
Les routeurs retiennent la route la plus spécifique, puisque l’acheminement préfère toujours le préfixe correspondant le plus long, tandis que les hôtes situés dans le chevauchement ne s’accordent pas sur les destinations qui sont locales. Le symptôme est partiel : certaines destinations fonctionnent et d’autres non, et la liste change selon l’endroit d’où vous testez.
Pourquoi les adresses de classe A, B et C ont-elles été remplacées par CIDR ?
Parce que les classes n’offraient que trois tailles : /8, /16 et /24. Une organisation qui avait besoin de 300 adresses devait prendre une classe B et en gaspiller la majeure partie, ou faire tourner deux routes de classe C. CIDR a permis au préfixe d’avoir n’importe quelle longueur, ce qui a ralenti l’épuisement des adresses et permis aux opérateurs de résumer de nombreux blocs clients en une seule route.
Puis-je découper une plage privée comme 192.168.0.0/16 comme je veux ?
Oui. L’espace RFC 1918 est à vous, à diviser à la longueur de préfixe que vous voulez, et personne à l’extérieur de votre réseau ne le voit. La contrainte est interne : chevaucher un réseau partenaire ou un VPC cloud que vous appairerez plus tard coûte cher à démêler, si bien que les plans d’adressage évitent en général les blocs que tous les routeurs domestiques utilisent déjà.
Ce qu’il faut retenir. Le préfixe compte les bits de réseau, et la taille de bloc vaut 256 − l'octet frontière du masque. Arrondissez l’adresse au multiple inférieur de la taille de bloc pour obtenir le réseau, et ajoutez la taille de bloc moins un pour obtenir le broadcast. Soustrayez deux pour le couple réservé, mais seulement lorsqu’un /31 ou un /32 n’a pas déjà supprimé la raison de soustraire. Distinguez le masque générique du masque de sous-réseau à leur allure. Allouez les grands blocs avant les petits.
Rien de tout cela ne réclame un outil une fois que c’est dans les doigts. Pour vérifier un plan avant qu’il n’atteigne un routeur, ou pour lire d’un coup d’œil la frontière binaire d’un bloc, le calculateur de sous-réseau fait l’arithmétique localement dans votre navigateur.