Skip to content
Terug naar blog
Tutorials

Subnetmasker berekenen: CIDR-tabel van /8 tot /32

Een /26 geeft 62 bruikbare adressen, geen 64, en bij een /31 klopt de min-tweeregel niet. Lees elk CIDR-prefix, reken het masker uit en controleer het online.

15 min leestijd

CIDR-notatie en subnetmaskers: zo lees je /8 tot en met /32

Het getal achter de schuine streep in 192.168.1.0/24 telt bits, geen adressen. Het zegt hoeveel van de 32 bits in een IPv4-adres bij het netwerk horen; wat overblijft hoort bij de hosts. Die ene zin is zo ongeveer alles wat CIDR-notatie is.

Al het andere volgt daaruit. Een /24 laat 8 hostbits over, dus het blok bevat 2⁸ = 256 adressen. Een /26 laat er 6 over, dus 64. Elke bit die je aan de hostkant teruggeeft verdubbelt het blok; elke bit die je afneemt verdubbelt het aantal blokken. Het aantal dat je daadwerkelijk aan apparaten kunt toewijzen ligt normaal gesproken twee lager dan het totaal, omdat het eerste adres het netwerk aanduidt en het laatste het broadcastadres is. Een /26 geeft je 62 bruikbare hosts, geen 64.

Twee prefixen doorbreken die min-tweeregel met opzet. Een wildcardmasker is geen subnetmasker, ook al belanden de twee voortdurend in elkaars velden. Wil je alleen het antwoord voor één blok, dan drukt de subnetcalculator het af; dit artikel gaat erover hoe je er zonder komt.

Wat CIDR-notatie eigenlijk zegt

Een subnetmasker is zelf ook een 32-bits getal, opgeschreven in dezelfde punt-decimale vorm als een adres. De bits vormen een reeks enen gevolgd door een reeks nullen. De enen markeren de netwerkbits, de nullen de hostbits. Schrijf een /26 helemaal uit en je krijgt:

11111111.11111111.11111111.11000000
    255  .   255  .   255  .   192

Reken elk octet terug naar decimaal en je hebt 255.255.255.192. CIDR-notatie telt de enen vooraan in plaats van ze alle tweeëndertig uit te schrijven. 192.168.1.0/26 en 192.168.1.0 255.255.255.192 zijn dezelfde uitspraak in twee schrijfwijzen, en welke van de twee een apparaat wil hebben, hangt volledig af van het commando dat je intikt.

Het tellen is de hele truc. /8, /16 en /24 vallen samen met octetgrenzen, en daarom zien ze er in decimaal netjes uit: 255.0.0.0, 255.255.0.0, 255.255.255.0. Niets in de notatie vereist dat. /22 en /27 zijn net zo geldig. Ze snijden dwars door het midden van een octet en leveren maskers op als 255.255.252.0, die willekeurig ogen tot je ze in binair opschrijft.

Waarom de klassen verdwenen. Vóór 1993 bepaalden de eerste bits van een adres hoe groot het was: klasse A kreeg een /8, klasse B een /16, klasse C een /24, en daartussen zat niets. Een organisatie met 300 hosts moest een klasse B opeisen en meer dan 65000 adressen verspillen, of twee klasse C-blokken nemen en twee routes meeslepen. CIDR (RFC 1519, later herzien als RFC 4632) brak die koppeling. Het prefix reist mee met het adres, dus een blok kan elke macht van twee zijn. Klassen duiken nog steeds op in certificeringsexamens en in oude documentatie, maar routering op basis van klassen is sindsdien achterhaald: het masker bepaalt waar een netwerk ophoudt, niet het eerste octet.

Het spiekbriefje voor subnetmaskers, /8 tot /32

De laatste kolom van de tabel hieronder staat er met opzet: die laat zien wat de algemene formule 2ⁿ − 2 oplevert, en dat komt overal overeen met het echte aantal bruikbare hosts behalve in de onderste twee rijen.

PrefixSubnetmaskerWildcardmaskerTotaal aantal adressenBruikbare hostsNaïeve 2ⁿ − 2 geeft
/8255.0.0.00.255.255.255167772161677721416777214
/9255.128.0.00.127.255.255838860883886068388606
/10255.192.0.00.63.255.255419430441943024194302
/11255.224.0.00.31.255.255209715220971502097150
/12255.240.0.00.15.255.255104857610485741048574
/13255.248.0.00.7.255.255524288524286524286
/14255.252.0.00.3.255.255262144262142262142
/15255.254.0.00.1.255.255131072131070131070
/16255.255.0.00.0.255.255655366553465534
/17255.255.128.00.0.127.255327683276632766
/18255.255.192.00.0.63.255163841638216382
/19255.255.224.00.0.31.255819281908190
/20255.255.240.00.0.15.255409640944094
/21255.255.248.00.0.7.255204820462046
/22255.255.252.00.0.3.255102410221022
/23255.255.254.00.0.1.255512510510
/24255.255.255.00.0.0.255256254254
/25255.255.255.1280.0.0.127128126126
/26255.255.255.1920.0.0.63646262
/27255.255.255.2240.0.0.31323030
/28255.255.255.2400.0.0.15161414
/29255.255.255.2480.0.0.7866
/30255.255.255.2520.0.0.3422
/31255.255.255.2540.0.0.1220
/32255.255.255.2550.0.0.011−1

Lees de tabel als een verzameling verbanden en niet als een lijst antwoorden. Elke rij naar beneden halveert het blok: een /24 bevat 256 adressen, een /25 128, een /26 64. De wildcardkolom is het subnetmasker met elke bit omgekeerd, en daarom staan 255.255.255.192 en 0.0.0.63 altijd op dezelfde regel. De twee vetgedrukte rijen zijn de plek waar de standaardformule de werkelijkheid niet meer beschrijft.

Alleen de waarden van het laatste octet in de maskerkolom hoef je te onthouden, want ze herhalen zich: 128, 192, 224, 240, 248, 252, 254, 255. Dat zijn de enige acht niet-triviale bytewaarden waarop een geldig masker kan eindigen. Wil je zelf zien waarom, dan drukt de talstelsel-omrekentool elk van die waarden in binair af.

De tabel achterstevoren lezen: van subnetmasker naar CIDR

Heb je een masker in punt-decimale notatie, tel dan de bits die op 1 staan. Elke 255 levert er 8, en het ene interessante octet levert de rest:

Laatste octet van het masker128192224240248252254255
Bits die het toevoegt12345678

Dus 255.255.255.192 is 8 + 8 + 8 + 2 = /26. En 255.255.252.0 is 8 + 8 + 6 + 0 = /22, want 252 is in binair 11111100.

Daar volgen twee dingen uit. Elk octet dat niet 255 en niet 0 is, is het grensoctet, en een geldig masker kan er maar één van hebben. Verder geeft de waarde van dat octet je meteen de blokgrootte.

Zo reken je een subnetmasker en een netwerk met de hand uit

De mechanische methode heeft drie stappen en werkt voor elk prefix. Het uitgewerkte voorbeeld hieronder gebruikt 192.168.1.130/26, maar het gaat om de procedure, niet om dit adres.

Stap 1 — bepaal de blokgrootte

De blokgrootte is 256 − het grensoctet van het masker.

Bij een /26 is het masker 255.255.255.192, dus is de blokgrootte 256 − 192 = 64. Subnetten van die omvang liggen op veelvouden van 64 in het vierde octet: 0, 64, 128, 192. Andere startpunten zijn er niet.

Blokgrootte en aantal adressen zijn hetzelfde getal; je komt er alleen via het masker uit in plaats van via het tellen van bits.

Stap 2 — bepaal in welk blok het adres valt

Deel het grensoctet van het adres door de blokgrootte en rond naar beneden af.

Het adres is 192.168.1.130, de blokgrootte is 64, dus 130 ÷ 64 = 2.03…, wat naar beneden afgerond 2 wordt. Vermenigvuldig terug: 2 × 64 = 128. Het adres zit in het blok dat bij 128 begint.

De meeste fouten ontstaan hier, en altijd in dezelfde richting: je neemt het adres dat je kreeg aan voor het begin van zijn blok, en dat is het meestal niet. 192.168.1.130 is een hostadres dat in het derde /26 van die /24 woont.

Stap 3 — netwerk, broadcast, eerste en laatste host

Het begin van het blok is het netwerkadres. Het broadcastadres is het begin van het blok plus de blokgrootte min één. Alles daar strikt tussenin is toewijsbaar:

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.63

Het broadcastadres is 128 + 64 − 1 = 191. De eerste host is netwerk + 1, de laatste host is broadcast − 1, en het aantal bruikbare adressen is 64 − 2 = 62, precies de /26-rij van het spiekbriefje.

In één zin die je tegen jezelf kunt opzeggen: de blokgrootte is 256 min het maskeroctet; rond het adres naar beneden af op een veelvoud daarvan; dat is je netwerk, en het begin van het volgende blok min één is je broadcastadres.

De methode is niet gebonden aan het vierde octet. Bij een /22 is het masker 255.255.252.0, dus is het grensoctet het derde en is de blokgrootte daar 256 − 252 = 4. Blokken beginnen dus bij 10.0.0.0, 10.0.4.0, 10.0.8.0, en het blok 10.0.0.0/22 loopt door tot broadcastadres 10.0.3.255 met bruikbare adressen 10.0.0.1 tot en met 10.0.3.254, oftewel vier opeenvolgende /24’s binnen één broadcastdomein. Dezelfde drie stappen, ander octet.

Loop je vast op de kant van binair naar decimaal, dan behandelt de gids over talstelsels omrekenen die conversie uitgebreider dan in een artikel over subnetten past.

Wil je je werk in een script nalopen in plaats van in je hoofd, dan kent de standaardbibliotheek van Python dit allemaal al:

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())))  # 62

Met strict=False mag je een hostadres doorgeven in plaats van een netwerkadres; met de standaardwaarde strict=True gooit dezelfde aanroep een ValueError.

Waar de min-tweeregel ophoudt te kloppen

Achter die aftrekking zit een reden: in een gewoon subnet duidt het patroon met alleen nullen in het hostdeel het netwerk zelf aan, en is het patroon met alleen enen het gerichte broadcastadres. Geen van beide kun je op een interface instellen, dus een blok van 2ⁿ adressen biedt er 2ⁿ − 2 aan hosts. Daarom geeft een /24 er 254 en een /26 er 62.

Die reden is meteen ook de grens. Zodra een blok te klein is om die twee gereserveerde adressen te bevatten, houdt het aftrekken ervan op zinnig te zijn.

Een /31 heeft twee adressen en twee bruikbare hosts. RFC 3021 definieert /31 voor point-to-point-links. Zo’n link heeft precies twee eindpunten en geen gedeeld segment, dus er valt voor een broadcastadres niets te doen en voor een netwerkadres niets aan te duiden. Beide adressen gaan naar de twee uiteinden. 2ⁿ − 2 hier toepassen geeft 0: een antwoord op een vraag die op zo’n link niet speelt. De voorwaarde die eraan vastzit is reëel: /31 is alleen geldig op echte point-to-point-interfaces. Een LAN-segment met meerdere apparaten heeft nog steeds /30 of korter nodig, en Windows accepteert geen /31 op een netwerkkaart.

Een /32 heeft één adres en één bruikbare host. Het is een route naar één host: loopback-interfaces, statische routes, anycast-adressen, firewallregels voor één adres. Er is geen broadcastadres, dus de − 2 uit de formule zou −1 opleveren.

Python is het met allebei eens:

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']

Je onthoudt dit het best niet als “er zijn twee uitzonderingen om uit je hoofd te leren”, maar als “de aftrekking haalt twee specifieke adressen weg, en je hoort te controleren of ze bestaan voordat je ze weghaalt”. Een /31 en een /32 hebben helemaal geen broadcastadres, dus valt er niets weg te halen.

Totaal, bruikbaar en aantal subnetten zijn drie verschillende getallen

Deze drie halen mensen voortdurend door elkaar, en die verwarring is begrijpelijk, want het zijn alle drie machten van twee die uit hetzelfde prefix volgen.

  • Het totale aantal adressen in een /p is 2^(32 − p). Bij een /26: 64.
  • Het aantal bruikbare hosts is dat min 2, behalve bij /31 en /32. Bij een /26: 62.
  • Het aantal subnetten dat je krijgt door een bovenliggend /p op te splitsen in kinderen /q is 2^(q − p). Een /24 opsplitsen in /26’s leent twee bits, dus 2² = 4 subnetten.

De drie beantwoorden verschillende vragen, dus een zin als “een /26 geeft je er 4” klopt alleen als de vraag over het opsplitsen van een /24 ging. Opsplitsen kost je bovendien adressen, want elk kindsubnet reserveert zijn eigen netwerk- en broadcastadres. Vier /26’s die uit een /24 gesneden zijn bevatten 4 × 62 = 248 bruikbare adressen tegenover de 254 van de ouder: zes adressen gaan op aan het opsplitsen zelf.

Wildcardmasker tegenover subnetmasker: welk commando wil welke

Een wildcardmasker is de bitsgewijze inverse van het subnetmasker. Waar het subnetmasker enen heeft, heeft het wildcardmasker nullen. Neem de /26-rij van het spiekbriefje: masker 255.255.255.192, wildcard 0.0.0.63. Keer elke bit van de een om en je hebt de ander, en daarom komen ze nooit los van elkaar voor.

De twee werken in tegengestelde richting, en dat is het stuk dat je je eigen moet maken. Een subnetmasker wordt toegepast met een bitsgewijze AND, dus een bit die 1 is betekent “deze bit hoort bij het netwerk”. Een wildcard is een matchfilter, dus een bit die 0 is betekent “deze bit moet overeenkomen” en een bit die 1 is betekent “maakt niet uit”. Dezelfde onderliggende bewerking, omgekeerde polariteit. Zijn de details op bitniveau wat vaag, dan behandelt de gids over bitsgewijze bewerkingen AND, OR en NOT in algemenere termen.

Welke van de twee een apparaat wil, is geen kwestie van voorkeur. Voor het blok 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 eth0

Cisco IOS-ACL’s en de network-statements van OSPF nemen het wildcardmasker; de ASA neemt in plaats daarvan het subnetmasker. Dat is één leverancier met twee conventies binnen dezelfde productfamilie, en daarom is dit zo’n klassieke kopieer-plakfout. Andere platforms hebben hun eigen conventies, dus controleer welke van de twee een onbekend veld verwacht voordat je er een waarde in plakt.

Het gevaar zit in de manier waarop het misgaat. Plak 255.255.255.192 in een IOS-ACL en de router leest het als een wildcard: drie octetten vol enen betekenen “maakt niet uit”, dus op de eerste drie octetten wordt helemaal niet meer gematcht en de regel reikt ver buiten het blok dat je voor ogen had. De router meldt geen syntaxfout en schrijft geen logregel; er staat alleen een permit-statement met het verkeerde bereik. De omgekeerde vergissing valt tenminste eerder op, want 0.0.0.63 is geen geldig subnetmasker: er staat geen aaneengesloten reeks enen vooraan. Of een bepaald platform hem weigert of stilzwijgend accepteert, kom je liever niet in productie te weten.

Waarom ACL-wildcards gaten mogen hebben en subnetmaskers niet

Een subnetmasker moet één aaneengesloten reeks enen zijn, gevolgd door nullen. Dat is geen afspraak: alleen zo kan de AND-bewerking een adres in precies twee delen splitsen. Een waarde als 255.0.255.0 heeft een gat, beschrijft geen samenhangende grens, en apparaten weigeren hem. Python ook:

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 network

Er zijn maar 33 geldige maskers, /0 tot en met /32. Al het andere is een typefout.

ACL-wildcards kennen die beperking niet, want ze splitsen geen adres in een netwerk- en een hostdeel. Ze zijn een matchfilter per bit, dus gaten zijn toegestaan en af en toe nuttig. Eén wildcard met een gat kan bijvoorbeeld elk oneven genummerd adres in een bereik matchen. Door dat verschil in zeggingskracht zijn de twee waarden niet verwisselbaar: het zijn niet dezelfde soort dingen, ze lijken in punt-decimale notatie alleen op elkaar.

Privé, CGNAT en andere gereserveerde bereiken

Een prefix vertelt je hoe groot een blok is. Welk blok het is, bepaalt of je het mag gebruiken.

BlokBereikGereserveerd door
10.0.0.0/810.0.0.0 – 10.255.255.255RFC 1918 privé
172.16.0.0/12172.16.0.0 – 172.31.255.255RFC 1918 privé
192.168.0.0/16192.168.0.0 – 192.168.255.255RFC 1918 privé
100.64.0.0/10100.64.0.0 – 100.127.255.255RFC 6598 carrier-grade NAT
169.254.0.0/16169.254.0.0 – 169.254.255.255RFC 3927 link-local
255.255.255.255/32één adresbeperkte broadcast

De RFC 1918-bereiken worden nooit over het publieke internet gerouteerd, en daarom kun je er veilig uit toewijzen. De overige drie duiken om heel andere redenen op.

100.64.0.0/10 is ruimte voor carrier-grade NAT. Geeft je provider je een adres daaruit, dan zit je achter hun NAT en bereikt geen enkele inkomende verbinding je zonder tunnel. Het is geen privéruimte in de zin van RFC 1918 en het is niet aan jou om er een intern plan op te bouwen, want je provider gebruikt het mogelijk al aan de andere kant van je router.

169.254.0.0/16 is link-local. Een host wijst zichzelf zo’n adres toe wanneer DHCP faalt, dus een 169.254-adres op een interface zien is eerder een diagnose dan een configuratie: er heeft niets op het DHCP-verzoek geantwoord. Verkeer daarnaartoe komt nooit langs een router.

Voor voorbeelden in documentatie en draaiboeken reserveert RFC 5737 juist 192.0.2.0/24, 198.51.100.0/24 en 203.0.113.0/24, zodat een gekopieerd voorbeeld nooit naar een echte host kan wijzen.

172.16.0.0/12 is zestien /16’s, niet één

Dit is het gereserveerde bereik waar mensen de mist in gaan, en het prefix is de reden. Een /12 leent vier bits uit het tweede octet, dus het blok loopt van 172.16.0.0 tot en met 172.31.255.255: zestien opeenvolgende /16’s, niet alleen 172.16.x.x.

De gevolgen gaan beide kanten op. Een adres als 172.20.5.1 is privé en ligt comfortabel binnen het bereik, ook al begint het niet met 172.16. En 172.15.x.x en 172.32.x.x zijn publieke adressen die aan iemand anders toebehoren, dus een firewallregel of een “vertrouw het interne bereik”-controle die tegen 172.0.0.0/8 is geschreven, vertrouwt stilzwijgend een flinke plak van het internet.

Moet je zo’n grens bevestigen, dan geeft het spiekbriefje je het rekenwerk: een /12 heeft 2^(32−12) adressen, het tweede octet loopt in stappen van 256 − 240 = 16, en 16 + 16 = 32, dus het blok eindigt vlak voor 172.32.0.0.

VLSM: één blok opsplitsen in ongelijke subnetten

Even grote subnetten zijn makkelijk en meestal verkeerd. Een filiaal dat één 192.168.1.0/24 krijgt, heeft misschien vier segmenten nodig die niets met elkaar gemeen hebben: honderd werkstations, vijftig telefoons, een stuk of twaalf servers en een handvol beheerinterfaces. Splits de /24 in vier gelijke /26’s en het werkstationsegment loopt over bij 62 hosts, terwijl het beheersegment op 62 adressen zit om tien apparaten te bedienen.

Variable Length Subnet Masking betekent dat je elk segment het prefix geeft dat het werkelijk nodig heeft. Dezelfde /24, nu opgedeeld in één /25, één /26 en twee /28’s.

Wijs toe van groot naar klein. Elk blok moet beginnen op een veelvoud van zijn eigen omvang, dus het grootste blok mag als eerste kiezen:

SegmentBenodigde hostsPrefixNetwerkBruikbaar bereikBroadcastSubnetmasker
Werkstations100/25192.168.1.0192.168.1.1 – 192.168.1.126192.168.1.127255.255.255.128
Telefonie50/26192.168.1.128192.168.1.129 – 192.168.1.190192.168.1.191255.255.255.192
Servers12/28192.168.1.192192.168.1.193 – 192.168.1.206192.168.1.207255.255.255.240
Beheer10/28192.168.1.208192.168.1.209 – 192.168.1.222192.168.1.223255.255.255.240
niet toegewezen/27192.168.1.224192.168.1.225 – 192.168.1.254192.168.1.255255.255.255.224

Met de driestapsmethode erdoorheen, blok voor blok:

  1. De /25 heeft blokgrootte 256 − 128 = 128, dus begint hij bij 0 en is zijn broadcastadres 0 + 128 − 1 = 127. Bruikbaar 1 tot en met 126, dat zijn 126 adressen, genoeg voor 100 werkstations met ruimte over. De /25-rij van het spiekbriefje bevestigt het: 128 totaal, 126 bruikbaar.
  2. Het volgende vrije adres is 128. De /26 heeft blokgrootte 64, en 128 is een veelvoud van 64, dus hij past: netwerk 192.168.1.128, broadcast 128 + 64 − 1 = 191, bruikbaar 129 tot en met 190. Dat is 62 bruikbaar voor 50 telefoons.
  3. Het volgende vrije adres is 192. De /28 heeft blokgrootte 16, en 192 = 16 × 12, dus hij past: netwerk 192.168.1.192, broadcast 207, bruikbaar 193 tot en met 206, dus 14 adressen voor 12 servers.
  4. Het volgende vrije adres is 208, en 208 = 16 × 13, dus de tweede /28 landt op 192.168.1.208 met broadcast 223 en bruikbaar 209 tot en met 222.

Dat verantwoordt 128 + 64 + 16 + 16 = 224 van de 256 adressen, en laat 192.168.1.224 tot en met 192.168.1.255 over. Die 32 adressen zijn toevallig precies één uitgelijnde /27, en daar zouden later de point-to-point-links vandaan komen: er passen zestien /31’s in, één per routerlink.

Waarom groot eerst, en wat het kost als je dat niet doet. Stel dat je de twee /28’s onderaan plaatst: 192.168.1.0/28 en 192.168.1.16/28. Het volgende vrije adres is 192.168.1.32, en een /25 moet beginnen op een veelvoud van 128, dus daar kan hij niet beginnen. Hij moet doorschuiven naar 192.168.1.128. De adressen van 32 tot en met 127 zijn niet verloren, maar ze zijn alleen bruikbaar als kleinere uitgelijnde stukken — een /27 op 192.168.1.32 en een /26 op 192.168.1.64 — waardoor de overgebleven ruimte verspreid raakt in plaats van als één aaneengesloten blok bovenaan te liggen. Voeg nog één segment aan de vraag toe en dezelfde manoeuvre past helemaal niet meer.

Op grootte sorteren voorkomt dat. Nadat je een blok hebt geplaatst, is het volgende vrije adres een veelvoud van de omvang van dat blok, en een veelvoud van een grotere macht van twee is automatisch een veelvoud van elke kleinere. Elk volgend, kleiner blok ligt dus uitgelijnd op de plek waar het vorige eindigde. Je hoeft nooit over te slaan. Voordat je zo’n plan aan een switch toevertrouwt, is het sneller om het door de verdelingstabel van de subnetcalculator te halen dan de uitlijning van elk segment met de hand na te lopen.

Vijf fouten die tot in productie overleven

1. Het adres dat je hebt ingetypt als netwerkadres behandelen

Symptoom: een firewallregel matcht niets, of een route dekt de verkeerde helft van een segment. Oorzaak: 192.168.1.130/26 werd gelezen als netwerk 192.168.1.0, broadcast 192.168.1.255, oftewel de /24-grens, want dat is de grens die mensen in decimaal zien. Oplossing: pas stap 2 toe. Blokgrootte 64, 130 ÷ 64 naar beneden afgerond is 2, dus het netwerk is 2 × 64 = 128. Het blok loopt van 192.168.1.128 tot en met 192.168.1.191, en 192.168.1.0 is een heel ander subnet. Is een prefix langer dan /24, ga er dan van uit dat het adres dat je kreeg een hostadres is totdat je het door het masker hebt gehaald.

2. 2ⁿ − 2 toepassen op een /31

Symptoom: een IPAM-tool of een spreadsheet meldt 0 bruikbare hosts voor een point-to-point-link die actief is en verkeer doorlaat. Oorzaak: de min-tweeregel gaat ervan uit dat er een netwerk- en een broadcastadres bestaan om af te trekken. Op een /31 bestaan die niet. Oplossing: behandel /31 en /32 als de randgevallen van de formule in plaats van als afwijkingen. RFC 3021 maakt beide adressen van een /31 toewijsbaar, en een /32 is een route naar één host met één adres. Alles wat 0 of −1 meldt, heeft de formule buiten haar geldigheidsgebied toegepast. Controleer eerst of de specifieke interface /31 ondersteunt, want de uitzondering geldt alleen op echte point-to-point-links.

3. 172.16.0.0/12 behandelen als alleen 172.16.x.x

Symptoom: een interne dienst is vanuit één kantoor onbereikbaar, of een regel die “alle privébereiken blokkeert” lekt. Oorzaak: de /12 werd gelezen alsof het een /16 was. Oplossing: het bereik loopt van 172.16.0.0 tot en met 172.31.255.255. Schrijf ACL’s en allowlists tegen het prefix 172.16.0.0/12 in plaats van tegen een octetpatroon, en onthoud dat 172.15.x.x en 172.32.x.x erbuiten vallen, op het publieke internet. Match je met de hand, dan is het tweede octet het grensoctet en loopt het in stappen van 16.

4. Een wildcard plakken in een veld dat een subnetmasker wil

Symptoom: een ACL staat veel meer of veel minder toe dan de bedoeling was, en niets in de configuratie ziet er verkeerd uit. Oorzaak: IOS-ACL’s en de network-statements van OSPF nemen het wildcardmasker terwijl de ASA het subnetmasker neemt, en 0.0.0.63 en 255.255.255.192 zijn op het eerste gezicht visueel verwisselbaar. Oplossing: controleer het veld voordat je plakt, niet erna. Een bruikbaar herkenningspunt: bij elk prefix van /8 of langer begint een subnetmasker met 255 en een wildcardmasker met 0. Begint een waarde in een ACL of een network-statement van OSPF met 255, dan staat er een subnetmasker in een wildcardveld.

5. Een niet-aaneengesloten masker schrijven, of er per ongeluk een genereren

Symptoom: een apparaat weigert een configuratieregel, of een zelfgebouwd script produceert maskers die plausibel ogen en fout zijn. Oorzaak: een waarde als 255.0.255.0 is geen geldig subnetmasker, want er zit een gat in. De gescripte variant is subtieler: in JavaScript nemen de shift-operatoren hun rechteroperand modulo 32, dus een prefix buiten bereik levert stilzwijgend een plausibel ogend fout masker op (33 wordt /1, −1 wordt /31) in plaats van een fout te gooien. Oplossing: valideer het prefixbereik voordat je gaat shiften, en weiger elk masker dat niet een aaneengesloten reeks enen gevolgd door nullen is. Een bibliotheek die bij verkeerde invoer een fout gooit is hier meer waard dan een die gokt, want beide faalvormen zijn stil.

FAQ

Wat is het verschil tussen een subnet en een VLAN?

Een VLAN is een broadcastdomein op laag 2 dat je op switches instelt; een subnet is een adresbereik op laag 3. Meestal koppel je ze één op één aan elkaar, maar niets dwingt dat af: je kunt twee subnetten op één VLAN zetten, of één VLAN over meerdere locaties trunken. Hernummer je het subnet, dan verandert het VLAN-ID niet.

Hoeveel subnetten krijg ik als ik een /24 in /26’s opsplits?

Vier. Het aantal is 2 tot de macht van het aantal geleende bits, en /26 is twee bits langer dan /24, dus 2² = 4 subnetten van elk 64 adressen. Elk kind reserveert zijn eigen netwerk- en broadcastadres, dus de vier /26’s bevatten samen 248 bruikbare adressen tegenover de 254 van de bovenliggende /24.

Werkt CIDR-notatie in IPv6 op dezelfde manier?

De schuine streep telt nog steeds de netwerkbits vooraan, dus /64 betekent 64 netwerkbits van de 128. Wat niet meekomt is de min-tweeregel: IPv6 heeft geen broadcastadres, dus er wordt niets van het totaal afgetrokken. Het spiekbriefje hierboven en de calculator erachter zijn alleen voor IPv4.

Wat betekent 0.0.0.0/0?

Nul netwerkbits, dus het matcht elk IPv4-adres. In een routeringstabel is het de standaardroute, gebruikt wanneer geen enkel specifieker prefix matcht. Als bindadres betekent het “alle interfaces”, en daarom is een dienst die op 0.0.0.0 luistert bereikbaar vanaf elk netwerk waarop de machine is aangesloten.

Wat gebeurt er als twee subnetten op hetzelfde netwerk overlappen?

Routers kiezen de specifiekere route, want bij het doorsturen wint altijd het langste overeenkomende prefix, terwijl hosts binnen de overlap het oneens zijn over welke bestemmingen lokaal zijn. Het symptoom is gedeeltelijk: sommige bestemmingen werken en andere niet, en welke dat zijn hangt af van waarvandaan je test.

Waarom zijn klasse A-, B- en C-adressen vervangen door CIDR?

Omdat de klassen maar drie maten boden: /8, /16 en /24. Een organisatie die 300 adressen nodig had, moest een klasse B nemen en het grootste deel ervan verspillen, of twee klasse C-routes onderhouden. CIDR liet een prefix elke lengte aannemen, wat de adresuitputting vertraagde en providers in staat stelde veel klantblokken in één route samen te vatten.

Mag ik een privébereik als 192.168.0.0/16 naar eigen inzicht opsplitsen?

Ja. RFC 1918-ruimte mag je op elke prefixlengte opdelen en niemand buiten je netwerk ziet het. De beperking is intern: overlappen met een partnernetwerk of een cloud-VPC waarmee je later peert, is duur om te ontwarren, en daarom mijden plannen doorgaans de blokken die elke thuisrouter al gebruikt.

Wat je hiervan meeneemt. Het prefix telt netwerkbits, en de blokgrootte is 256 − het grensoctet van het masker. Rond het adres naar beneden af op een veelvoud van de blokgrootte voor het netwerk, en tel de blokgrootte min één op voor het broadcastadres. Trek twee af voor het gereserveerde paar, maar alleen wanneer een /31 of /32 de reden om af te trekken niet al heeft weggenomen. Houd het wildcardmasker en het subnetmasker uit elkaar aan hun vorm. Wijs grote blokken toe vóór kleine.

Daar heb je geen enkele tool voor nodig zodra het in je vingers zit, en dat is de reden om het een keer met de hand door te werken. Wil je een plan controleren voordat het een router bereikt, of de binaire grens van een blok in één oogopslag aflezen, dan doet de subnetcalculator het rekenwerk lokaal in je browser.

Tags: networking subnetting cidr ip-address cheat-sheet

Gerelateerde artikelen

Alle artikelen bekijken