Notacja CIDR i maski podsieci: jak czytać zapis od /8 do /32
Liczba po ukośniku w 192.168.1.0/24 zlicza bity, a nie adresy. Mówi, ile spośród 32 bitów adresu IPv4 należy do sieci; cała reszta należy do hostów. To jedno zdanie wyczerpuje większość tego, czym jest notacja CIDR.
/24 zostawia 8 bitów hosta, więc blok mieści 2⁸ = 256 adresów. /26 zostawia 6, więc mieści 64. Każdy bit oddany stronie hosta podwaja blok; każdy bit zabrany podwaja liczbę bloków. Liczba adresów, które realnie da się przypisać urządzeniom, jest zwykle o dwa mniejsza od całości, bo pierwszy adres nazywa sieć, a ostatni jest adresem rozgłoszeniowym. /26 daje 62 użyteczne hosty, nie 64.
Dwa prefiksy łamią regułę minus dwa całkiem celowo. Maska wildcard nie jest maską podsieci, choć obie raz po raz lądują w polach przeznaczonych dla tej drugiej. Dalej idzie odczyt prefiksu, liczenie maski na piechotę i te miejsca, w których arytmetyka przestaje się zgadzać z intuicją. Jeśli potrzebna jest tylko odpowiedź dla jednego bloku, kalkulator podsieci ją wypisze; ten artykuł jest o dojściu do niej bez narzędzia.
Co właściwie mówi notacja CIDR
Maska podsieci sama jest liczbą 32-bitową, zapisywaną tak jak adres. Jej bity to ciąg jedynek, po którym następuje ciąg zer. Jedynki oznaczają bity sieci, zera — bity hosta. Po rozpisaniu /26 w całości wychodzi:
11111111.11111111.11111111.11000000
255 . 255 . 255 . 192Po przeliczeniu każdego oktetu z powrotem na dziesiętny wychodzi 255.255.255.192. Notacja CIDR zlicza wiodące jedynki, zamiast wypisywać wszystkie trzydzieści dwa bity. 192.168.1.0/26 i 192.168.1.0 255.255.255.192 to ta sama informacja w dwóch składniach, a to, której oczekuje urządzenie, zależy wyłącznie od wpisywanego polecenia.
Cała sztuczka polega na liczeniu. /8, /16 i /24 trafiają w granice oktetów i dlatego wyglądają schludnie w zapisie dziesiętnym: 255.0.0.0, 255.255.0.0, 255.255.255.0. Notacja niczego takiego nie wymaga. /22 i /27 są równie poprawne. Tną oktet w połowie i dają maski w rodzaju 255.255.252.0, które wyglądają na przypadkowe dokładnie do momentu rozpisania ich w postaci binarnej.
Przed 1993 rokiem o wielkości adresu decydowały jego wiodące bity: klasa A brała /8, klasa B — /16, klasa C — /24, i nie było nic pomiędzy. Organizacja z 300 hostami musiała wziąć klasę B i zmarnować ponad 65000 adresów albo wziąć dwa bloki klasy C i utrzymywać dwie trasy. CIDR (RFC 1519, później zrewidowany jako RFC 4632) zerwał to powiązanie. Prefiks podróżuje razem z adresem, więc blok może mieć dowolny rozmiar będący potęgą dwójki. Klasy wciąż pojawiają się w egzaminach certyfikacyjnych i w starej dokumentacji, ale routing klasowy jest przestarzały od 1993 roku: o tym, gdzie kończy się sieć, decyduje maska, a nie pierwszy oktet.
Ściąga z maskami podsieci, od /8 do /32
Poniższa tabela przelicza CIDR na maskę podsieci. Ostatnia kolumna jest celowa: pokazuje, co daje ogólny wzór 2ⁿ − 2, który zgadza się z rzeczywistą liczbą użytecznych adresów wszędzie poza dwoma ostatnimi wierszami.
| Prefiks | Maska podsieci | Maska wildcard | Adresy łącznie | Hosty użyteczne | Naiwny 2ⁿ − 2 daje |
|---|---|---|---|---|---|
| /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 |
Tabela pokazuje przede wszystkim zależności między kolumnami. Każdy wiersz w dół połowi blok: /24 mieści 256 adresów, /25 — 128, /26 — 64. Kolumna wildcard to maska podsieci z odwróconym każdym bitem i dlatego 255.255.255.192 oraz 0.0.0.63 zawsze stoją w tym samym wierszu. W dwóch pogrubionych wierszach standardowy wzór przestaje opisywać rzeczywistość.
Zapamiętać trzeba tylko wartości ostatniego oktetu z kolumny maski, bo one się powtarzają: 128, 192, 224, 240, 248, 252, 254, 255. To jedyne osiem nietrywialnych wartości bajtu, na których może kończyć się poprawna maska. Widać to od razu po rozpisaniu ich w postaci binarnej, a rozpisze je konwerter systemów liczbowych.
Czytanie tabeli od tyłu: z maski podsieci na CIDR
Mając maskę w zapisie kropkowo-dziesiętnym, wystarczy policzyć jedynki. Każde 255 wnosi 8, a jedyny interesujący oktet wnosi resztę:
| Ostatni oktet maski | 128 | 192 | 224 | 240 | 248 | 252 | 254 | 255 |
|---|---|---|---|---|---|---|---|---|
| Ile bitów dodaje | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
Zatem 255.255.255.192 to 8 + 8 + 8 + 2 = /26. A 255.255.252.0 to 8 + 8 + 6 + 0 = /22, bo 252 w zapisie binarnym to 11111100.
Wynikają z tego dwie rzeczy. Każdy oktet, który nie jest ani 255, ani 0, jest oktetem granicznym, a poprawna maska może mieć tylko jeden taki oktet. Druga rzecz jest praktyczniejsza: wartość tego oktetu daje bezpośrednio rozmiar bloku.
Jak policzyć maskę podsieci i adres sieci na piechotę
Metoda mechaniczna ma trzy kroki i działa dla dowolnego prefiksu. Rozpisany niżej przykład korzysta z 192.168.1.130/26, ale chodzi o procedurę, a nie o ten konkretny adres.
Krok 1 — znajdź rozmiar bloku
Rozmiar bloku to 256 − graniczny oktet maski.
Dla /26 maska to 255.255.255.192, więc rozmiar bloku wynosi 256 − 192 = 64. Podsieci tej wielkości leżą na wielokrotnościach 64 w czwartym oktecie: 0, 64, 128, 192. Innych możliwych punktów startowych nie ma.
Rozmiar bloku i liczba adresów to ta sama liczba, tyle że wyliczona od strony maski zamiast od strony liczby bitów.
Krok 2 — ustal, w którym bloku leży adres
Graniczny oktet adresu należy podzielić przez rozmiar bloku i zaokrąglić w dół.
Adres to 192.168.1.130, rozmiar bloku to 64, więc 130 ÷ 64 = 2.03…, co po zaokrągleniu w dół daje 2. Mnożenie z powrotem: 2 × 64 = 128. Adres leży w bloku zaczynającym się od 128.
Tu powstaje najwięcej błędów i zawsze w tę samą stronę: otrzymany adres bierze się za początek własnego bloku, a zwykle nim nie jest. 192.168.1.130 to adres hosta mieszkający w trzeciej podsieci /26 wewnątrz tego /24.
Krok 3 — sieć, rozgłoszenie, pierwszy i ostatni host
Początek bloku jest adresem sieci. Adres rozgłoszeniowy to początek bloku plus rozmiar bloku minus jeden. Wszystko ściśle pomiędzy nimi da się przypisać:
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.63Adres rozgłoszeniowy to 128 + 64 − 1 = 191. Pierwszy host to adres sieci + 1, ostatni host to adres rozgłoszeniowy − 1, a liczba użytecznych adresów to 64 − 2 = 62, zgodnie z wierszem /26 ze ściągi.
W jednym zdaniu: rozmiar bloku to 256 minus oktet maski, adres zaokrągla się w dół do wielokrotności tego rozmiaru i tak powstaje adres sieci, a początek następnego bloku minus jeden to adres rozgłoszeniowy.
Metoda nie jest przywiązana do czwartego oktetu. Dla /22 maska to 255.255.252.0, więc oktetem granicznym jest trzeci, a rozmiar bloku wynosi tam 256 − 252 = 4. Bloki zaczynają się zatem od 10.0.0.0, 10.0.4.0, 10.0.8.0, a blok 10.0.0.0/22 sięga adresu rozgłoszeniowego 10.0.3.255, z użytecznymi adresami od 10.0.0.1 do 10.0.3.254, czyli cztery kolejne sieci /24 w jednej domenie rozgłoszeniowej. Te same trzy kroki, inny oktet.
Jeśli robotę spowalnia samo przeliczanie binarno-dziesiętne, przewodnik po konwersji systemów liczbowych omawia tę konwersję dokładniej, niż wypada artykułowi o podsieciach.
Kto woli sprawdzać wyniki skryptem, ten nie musi tego implementować: biblioteka standardowa Pythona zna już całą tę arytmetykę.
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()))) # 62To strict=False pozwala podać adres hosta zamiast adresu sieci; przy domyślnym strict=True to samo wywołanie zgłasza ValueError.
Gdzie reguła minus dwa przestaje obowiązywać
Za tym odejmowaniem stoi konkretny powód. W zwykłej podsieci układ bitów hosta złożony z samych zer nazywa samą sieć, a układ z samych jedynek jest skierowanym adresem rozgłoszeniowym. Żadnego z nich nie da się skonfigurować na interfejsie, więc blok 2ⁿ adresów oferuje hostom 2ⁿ − 2. Dlatego /24 daje 254, a /26 — 62.
Ten powód jest zarazem granicą. Gdy blok jest za mały, by pomieścić te dwa zarezerwowane adresy, odejmowanie ich przestaje mieć sens.
Sieć /31 ma dwa adresy i dwa użyteczne hosty. RFC 3021 definiuje /31 dla łączy punkt-punkt. Takie łącze ma dokładnie dwa końce i żadnego wspólnego segmentu, więc adres rozgłoszeniowy nie ma tam czego robić, a adres sieci nie ma czego identyfikować. Oba adresy trafiają do dwóch końców. Wzór 2ⁿ − 2 zwraca tu 0, bo odejmuje zarezerwowaną parę, której w tej topologii nikt nie zarezerwował. Zastrzeżenie jest przy tym realne: /31 jest poprawne wyłącznie na naprawdę punkt-punktowych interfejsach. Segment LAN z dostępem wielopunktowym nadal potrzebuje /30 lub krótszego prefiksu, a Windows nie przyjmie /31 na karcie sieciowej.
Sieć /32 ma jeden adres i jeden użyteczny host. To pojedyncza trasa hosta: interfejsy loopback, trasy statyczne, adresy anycast, reguły zapory na jeden adres. Adresu rozgłoszeniowego nie ma, więc − 2 ze wzoru zwróciłoby −1.
Python potwierdza obie rzeczy:
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']Zwykle zapamiętuje się to jako „są dwa wyjątki do wykucia”, przez co wypada z głowy po tygodniu. Lepiej trzyma się wersja „odejmowanie usuwa dwa konkretne adresy, więc najpierw sprawdź, czy one istnieją”. W sieciach /31 i /32 adresu rozgłoszeniowego nie ma w ogóle, zatem nic nie zostaje usunięte.
Adresy łącznie, użyteczne i liczba podsieci to trzy różne liczby
Te trzy wartości myli się nagminnie, a pomyłka jest zrozumiała, bo wszystkie są potęgami dwójki wyprowadzonymi z tego samego prefiksu.
- Adresy łącznie w /p to
2^(32 − p). Dla /26: 64. - Hosty użyteczne to ta liczba minus 2, poza /31 i /32. Dla /26: 62.
- Liczba podsieci powstałych z podziału nadrzędnego /p na potomne /q to
2^(q − p). Podział /24 na sieci /26 pożycza dwa bity, więc daje2² = 4podsieci.
Każda z tych trzech odpowiada na inne pytanie, więc zdanie w rodzaju „/26 daje 4” jest prawdziwe tylko wtedy, gdy pytanie dotyczyło podziału /24. Podział kosztuje też adresy, bo każda podsieć potomna rezerwuje własną parę: adres sieci i adres rozgłoszeniowy. Cztery sieci /26 wykrojone z /24 mieszczą 4 × 62 = 248 użytecznych adresów wobec 254 w sieci nadrzędnej, czyli sześć adresów idzie na sam podział.
Maska wildcard a maska podsieci: które polecenie czego oczekuje
Maska wildcard jest bitową negacją maski podsieci. Tam, gdzie maska podsieci ma jedynki, wildcard ma zera. Wystarczy wziąć wiersz /26 ze ściągi: maska 255.255.255.192, wildcard 0.0.0.63. Odwrócenie każdego bitu jednej daje drugą i dlatego nigdy nie występują osobno.
Znaczenie bitu jest w obu przeciwne i na tym polega cały kłopot. Maskę podsieci stosuje się przez bitowe AND, więc bit 1 znaczy „ten bit należy do sieci”. Wildcard jest filtrem dopasowania, więc bit 0 znaczy „ten bit musi się zgadzać”, a bit 1 — „nieistotne”. Ta sama operacja pod spodem, odwrotna polaryzacja. Jeśli mechanika na poziomie bitów jest mglista, przewodnik po operacjach bitowych omawia AND, OR i NOT bardziej ogólnie.
Które z nich wpisać, dyktuje samo polecenie. Dla bloku 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 eth0Listy ACL w Cisco IOS oraz instrukcje network w OSPF przyjmują maskę wildcard; ASA przyjmuje za to maskę podsieci. Jeden producent, dwie konwencje w tej samej rodzinie produktów: stąd biorą się wpadki przy przenoszeniu wartości między konfiguracjami. Inne platformy mają własne konwencje, więc przed wklejeniem czegokolwiek w nieznane pole trzeba ustalić, której z tych dwóch ono oczekuje.
Niebezpieczny jest tu sposób, w jaki to zawodzi. Po wklejeniu 255.255.255.192 do listy ACL w IOS router odczyta tę wartość jako wildcard: trzy oktety samych jedynek znaczą „nieistotne”, więc pierwsze trzy oktety przestają być w ogóle dopasowywane, a reguła sięga daleko poza blok, o który chodziło. Żadnego błędu składni, żadnej linii w logu, po prostu instrukcja permit o złym zasięgu. Odwrotna pomyłka ma przynajmniej szansę zostać wychwycona, bo 0.0.0.63 nie jest poprawną maską podsieci: brakuje jej wiodącego ciągu jedynek. Tego, czy dana platforma ją odrzuci, czy po cichu przyjmie, lepiej nie odkrywać na produkcji.
Dlaczego wildcardy w ACL mogą mieć dziury, a maski podsieci nie
Maska podsieci musi być jednym ciągłym pasmem jedynek, po którym idą zera. Nie jest to konwencja: właśnie dzięki temu operacja AND dzieli adres na dokładnie dwie części. Wartość taka jak 255.0.255.0 ma w środku dziurę, nie opisuje żadnej spójnej granicy i urządzenia ją odrzucają. Python również:
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 networkPoprawnych masek jest tylko 33, od /0 do /32. Wszystko inne to literówka.
Wildcardy w ACL nie podlegają takiemu ograniczeniu, bo nie dzielą adresu na część sieciową i część hosta. Są filtrem dopasowania bit po bicie, więc dziury są dozwolone i czasem przydatne: pojedynczy wildcard z dziurą potrafi dopasować na przykład wszystkie adresy nieparzyste w zakresie. Właśnie dlatego obu wartości nie da się zamieniać miejscami. To dwa różne rodzaje obiektów, które przypadkiem wyglądają podobnie w zapisie kropkowo-dziesiętnym.
Adresy prywatne, CGNAT i inne zakresy zarezerwowane
Prefiks mówi, jak duży jest blok. To, który to blok, mówi, czy wolno go używać.
| Blok | Zakres | Zarezerwowany przez |
|---|---|---|
| 10.0.0.0/8 | 10.0.0.0 – 10.255.255.255 | RFC 1918, adresy prywatne |
| 172.16.0.0/12 | 172.16.0.0 – 172.31.255.255 | RFC 1918, adresy prywatne |
| 192.168.0.0/16 | 192.168.0.0 – 192.168.255.255 | RFC 1918, adresy prywatne |
| 100.64.0.0/10 | 100.64.0.0 – 100.127.255.255 | RFC 6598, carrier-grade NAT |
| 169.254.0.0/16 | 169.254.0.0 – 169.254.255.255 | RFC 3927, link-local |
| 255.255.255.255/32 | pojedynczy adres | rozgłoszenie ograniczone |
Zakresy z RFC 1918 nigdy nie są routowane w publicznym internecie i dlatego można z nich bezpiecznie przydzielać adresy. Pozostałe wiersze tabeli są zarezerwowane z innych powodów.
100.64.0.0/10 to przestrzeń carrier-grade NAT. Jeśli dostawca internetu przydziela adres z tego zakresu, ruch idzie przez jego NAT i żadne połączenie przychodzące nie dotrze bez tunelu. To nie jest przestrzeń prywatna w rozumieniu RFC 1918 i nie wolno jej używać we własnym planie adresacji, bo operator może już z niej korzystać po drugiej stronie routera.
169.254.0.0/16 to link-local. Host przypisuje sobie taki adres sam, gdy DHCP zawiedzie, więc adres 169.254 na interfejsie jest diagnozą, a nie konfiguracją: na żądanie DHCP nikt nie odpowiedział. Ruch do niego nigdy nie przechodzi przez router.
Na potrzeby przykładów w dokumentacji i procedurach operacyjnych RFC 5737 rezerwuje 192.0.2.0/24, 198.51.100.0/24 oraz 203.0.113.0/24 właśnie po to, żeby skopiowany przykład nie mógł wskazywać na prawdziwego hosta.
172.16.0.0/12 to szesnaście sieci /16, nie jedna
To ten zarezerwowany zakres, przy którym najczęściej dochodzi do pomyłki, a winny jest prefiks. /12 pożycza cztery bity z drugiego oktetu, więc blok rozciąga się od 172.16.0.0 do 172.31.255.255 — szesnaście kolejnych sieci /16, a nie tylko 172.16.x.x.
Konsekwencje działają w obie strony. Adres taki jak 172.20.5.1 jest prywatny i mieści się spokojnie w zakresie, choć nie zaczyna się od 172.16. Z kolei 172.15.x.x i 172.32.x.x to adresy publiczne, należące do kogoś innego, więc reguła zapory albo sprawdzenie w stylu „ufaj zakresowi wewnętrznemu” napisane dla 172.0.0.0/8 po cichu obdarza zaufaniem spory kawałek internetu.
Do potwierdzenia takiej granicy wystarczy arytmetyka ze ściągi: /12 ma 2^(32−12) adresów, drugi oktet przesuwa się skokami po 256 − 240 = 16, a 16 + 16 = 32, więc blok kończy się tuż przed 172.32.0.0.
VLSM: podział jednego bloku na nierówne podsieci
Podsieci równej wielkości są proste i zwykle błędne. Oddział firmy, który dostał jedną sieć 192.168.1.0/24, może potrzebować czterech segmentów niemających ze sobą nic wspólnego: sto stacji roboczych, pięćdziesiąt telefonów, dwanaście serwerów i garstka interfejsów zarządzania. Po podziale /24 na cztery równe sieci /26 segment stacji roboczych przepełnia się przy 62 hostach, a segment zarządzania siedzi na 62 adresach, obsługując dziesięć urządzeń.
Variable Length Subnet Masking, czyli maskowanie podsieci o zmiennej długości, oznacza przydzielenie każdemu segmentowi prefiksu, którego naprawdę potrzebuje. Oto ta sama sieć /24 pokrojona na jedną /25, jedną /26 i dwie /28.
Przydzielać trzeba od największego bloku do najmniejszego. Każdy blok musi zaczynać się na wielokrotności własnego rozmiaru, więc największy wybiera pierwszy:
| Segment | Potrzebne hosty | Prefiks | Sieć | Zakres użyteczny | Rozgłoszenie | Maska podsieci |
|---|---|---|---|---|---|---|
| Stacje robocze | 100 | /25 | 192.168.1.0 | 192.168.1.1 – 192.168.1.126 | 192.168.1.127 | 255.255.255.128 |
| Telefonia | 50 | /26 | 192.168.1.128 | 192.168.1.129 – 192.168.1.190 | 192.168.1.191 | 255.255.255.192 |
| Serwery | 12 | /28 | 192.168.1.192 | 192.168.1.193 – 192.168.1.206 | 192.168.1.207 | 255.255.255.240 |
| Zarządzanie | 10 | /28 | 192.168.1.208 | 192.168.1.209 – 192.168.1.222 | 192.168.1.223 | 255.255.255.240 |
| nieprzydzielone | — | /27 | 192.168.1.224 | 192.168.1.225 – 192.168.1.254 | 192.168.1.255 | 255.255.255.224 |
Przejście tego metodą trzech kroków:
- Sieć /25 ma rozmiar bloku
256 − 128 = 128, więc zaczyna się od 0, a jej adres rozgłoszeniowy to0 + 128 − 1 = 127. Użyteczne od 1 do 126, czyli 126 adresów: dość dla 100 stacji roboczych i jeszcze zostaje zapas. Wiersz /25 ze ściągi to potwierdza: 128 łącznie, 126 użytecznych. - Następny wolny adres to 128. Sieć /26 ma rozmiar bloku 64, a 128 jest wielokrotnością 64, więc się mieści: sieć 192.168.1.128, rozgłoszenie
128 + 64 − 1 = 191, użyteczne od 129 do 190. To 62 użyteczne adresy na 50 telefonów. Wiersz /26 ze ściągi: 64 łącznie, 62 użyteczne. - Następny wolny to 192. Sieć /28 ma rozmiar bloku 16, a
192 = 16 × 12, więc się mieści: sieć 192.168.1.192, rozgłoszenie 207, użyteczne od 193 do 206, czyli 14 adresów na 12 serwerów. Wiersz /28 ze ściągi: 16 łącznie, 14 użytecznych. - Następny wolny to 208, a
208 = 16 × 13, więc druga sieć /28 ląduje na 192.168.1.208 z rozgłoszeniem 223 i użytecznymi od 209 do 222.
To rozdysponowuje 128 + 64 + 16 + 16 = 224 z 256 adresów i zostawia zakres od 192.168.1.224 do 192.168.1.255. Te 32 adresy to dokładnie jedna wyrównana sieć /27, z której wzięłyby się później łącza punkt-punkt: mieści się w niej szesnaście sieci /31, po jednej na łącze między routerami.
Inna kolejność kosztuje i widać to od razu na przykładzie. Załóżmy, że obie sieci /28 lądują na samym dole: 192.168.1.0/28 i 192.168.1.16/28. Następny wolny adres to 192.168.1.32, a /25 musi zaczynać się na wielokrotności 128, więc tam się nie zacznie. Musi przeskoczyć do 192.168.1.128. Adresy od 32 do 127 nie przepadają, ale dają się wykorzystać wyłącznie jako mniejsze wyrównane kawałki (/27 pod 192.168.1.32 i /26 pod 192.168.1.64), przez co wolna przestrzeń kończy rozproszona zamiast leżeć w jednym ciągłym bloku na końcu. Wystarczy dołożyć do zamówienia jeszcze jeden segment i ten sam manewr przestaje się mieścić w ogóle.
Porządkowanie według rozmiaru to eliminuje. Po umieszczeniu bloku następny wolny adres jest wielokrotnością rozmiaru tego bloku, a wielokrotność większej potęgi dwójki jest automatycznie wielokrotnością każdej mniejszej. Każdy kolejny, mniejszy blok jest zatem wyrównany dokładnie tam, gdzie skończył się poprzedni. Przeskakiwać nie trzeba nigdy. Zanim taki plan trafi do przełącznika, szybciej jest przepuścić go przez tabelę podziału w kalkulatorze podsieci niż sprawdzać wyrównanie każdego segmentu ręcznie.
Pięć błędów, które dożywają produkcji
1. Traktowanie wpisanego adresu jako adresu sieci
Objaw: reguła zapory nie dopasowuje niczego albo trasa obejmuje niewłaściwą połowę segmentu.
Przyczyna: 192.168.1.130/26 odczytano jako sieć 192.168.1.0 z rozgłoszeniem 192.168.1.255, czyli po granicy /24, bo to ją widać w zapisie dziesiętnym.
Rozwiązanie: zastosować krok 2. Rozmiar bloku 64, 130 ÷ 64 po zaokrągleniu w dół daje 2, więc sieć to 2 × 64 = 128. Blok to 192.168.1.128 do 192.168.1.191, a 192.168.1.0 jest zupełnie inną podsiecią. Zawsze gdy prefiks jest dłuższy niż /24, otrzymany adres należy uznawać za adres hosta, dopóki nie zostanie przepuszczony przez maskę.
2. Stosowanie 2ⁿ − 2 do /31
Objaw: narzędzie IPAM albo arkusz kalkulacyjny raportuje 0 użytecznych hostów dla łącza punkt-punkt, które działa i przepuszcza ruch. Przyczyna: reguła minus dwa zakłada, że istnieją adres sieci i adres rozgłoszeniowy, które można odjąć. W /31 ich nie ma. Rozwiązanie: traktować /31 i /32 jako warunki brzegowe wzoru, a nie jako anomalie. RFC 3021 czyni oba adresy sieci /31 przypisywalnymi, a /32 to pojedyncza trasa hosta z jednym adresem. Cokolwiek raportuje 0 albo −1, zastosowało wzór poza jego dziedziną. Obsługę /31 trzeba jednak najpierw sprawdzić na konkretnym interfejsie, bo wyjątek obowiązuje wyłącznie na naprawdę punkt-punktowych łączach.
3. Traktowanie 172.16.0.0/12 wyłącznie jako 172.16.x.x
Objaw: usługa wewnętrzna jest nieosiągalna z jednego biura albo reguła „blokuj wszystkie zakresy prywatne” przecieka. Przyczyna: /12 odczytano tak, jakby było /16. Rozwiązanie: zakres to 172.16.0.0 do 172.31.255.255. Listy ACL i allowlisty należy pisać na prefiks 172.16.0.0/12, a nie na wzorzec oktetu, oraz pamiętać, że 172.15.x.x i 172.32.x.x leżą poza nim, w publicznym internecie. Przy dopasowywaniu ręcznym oktetem granicznym jest drugi oktet, a jego krok wynosi 16.
4. Wklejanie wildcarda w pole, które oczekuje maski podsieci
Objaw: lista ACL przepuszcza znacznie więcej albo znacznie mniej, niż zamierzano, a w konfiguracji nic nie wygląda źle. Przyczyna: listy ACL w IOS i instrukcje network w OSPF biorą wildcard, podczas gdy ASA bierze maskę podsieci, a 0.0.0.63 i 255.255.255.192 na pierwszy rzut oka wyglądają wymiennie. Rozwiązanie: sprawdzać pole przed wklejeniem, nie po. Skrót dla oka: dla każdego prefiksu /8 lub dłuższego maska podsieci zaczyna się od 255, a wildcard od 0. Jeśli wartość siedząca w liście ACL albo w instrukcji network OSPF zaczyna się od 255, to maska podsieci w polu na wildcard.
5. Zapisanie maski nieciągłej albo wygenerowanie takiej przypadkiem
Objaw: urządzenie odrzuca linię konfiguracji albo napisany własnoręcznie skrypt produkuje maski, które wyglądają wiarygodnie i są błędne. Przyczyna: wartość taka jak 255.0.255.0 nie jest poprawną maską podsieci, bo ma w środku dziurę. Wariant skryptowy jest subtelniejszy: w JavaScripcie operatory przesunięcia biorą prawy operand modulo 32, więc prefiks spoza zakresu po cichu daje wiarygodnie wyglądającą, błędną maskę (33 staje się /1, −1 staje się /31), zamiast zgłosić wyjątek. Rozwiązanie: sprawdzać zakres prefiksu przed przesunięciem i odrzucać każdą maskę, która nie jest litym pasmem jedynek zakończonym zerami. Biblioteka zgłaszająca wyjątek przy złym wejściu jest tu warta więcej niż taka, która zgaduje, bo oba tryby awarii są ciche.
FAQ
Czym różni się podsieć od VLAN-u?
VLAN to domena rozgłoszeniowa warstwy 2, konfigurowana na przełącznikach; podsieć to zakres adresów warstwy 3. Zwykle przyporządkowuje się je jeden do jednego, ale nic tego nie wymusza — na jednym VLAN-ie mogą działać dwie podsieci, a jeden VLAN można przeciągnąć trunkiem między lokalizacjami. Przenumerowanie podsieci nie zmienia identyfikatora VLAN.
Ile podsieci powstaje z podziału /24 na sieci /26?
Cztery. Liczba to 2 podniesione do potęgi równej liczbie pożyczonych bitów, a /26 jest o dwa bity dłuższe od /24, więc wychodzą 2² = 4 podsieci po 64 adresy. Każda podsieć potomna rezerwuje własny adres sieci i adres rozgłoszeniowy, więc cztery sieci /26 mieszczą 248 użytecznych adresów wobec 254 w nadrzędnej /24.
Czy notacja CIDR działa tak samo w IPv6?
Ukośnik nadal zlicza wiodące bity sieci, więc /64 znaczy 64 bity sieci ze 128. Nie przenosi się natomiast reguła minus dwa: IPv6 nie ma adresu rozgłoszeniowego, więc od całości nic się nie odejmuje. Powyższa ściąga i stojący za nią kalkulator dotyczą wyłącznie IPv4.
Co oznacza 0.0.0.0/0?
Zero bitów sieci, więc pasuje do każdego adresu IPv4. W tablicy routingu jest to trasa domyślna, używana wtedy, gdy nie pasuje żaden bardziej szczegółowy prefiks. Jako adres nasłuchu oznacza „wszystkie interfejsy” i dlatego usługa nasłuchująca na 0.0.0.0 jest osiągalna z każdej sieci, do której podłączona jest maszyna.
Co się dzieje, gdy dwie podsieci w tej samej sieci na siebie nachodzą?
Routery wybierają trasę bardziej szczegółową, bo przekazywanie zawsze preferuje najdłuższy pasujący prefiks, natomiast hosty w części wspólnej nie zgadzają się co do tego, które cele są lokalne. Objaw jest połowiczny: część celów działa, część nie, a podział między nimi zmienia się zależnie od tego, skąd prowadzi się test.
Dlaczego adresy klasy A, B i C zostały zastąpione przez CIDR?
Bo klasy oferowały tylko trzy rozmiary: /8, /16 i /24. Organizacja potrzebująca 300 adresów musiała wziąć klasę B i zmarnować jej większość albo utrzymywać dwie trasy klasy C. CIDR pozwolił prefiksowi mieć dowolną długość, co spowolniło wyczerpywanie adresów i umożliwiło operatorom agregowanie wielu bloków klienckich w jedną trasę.
Czy prywatny zakres w rodzaju 192.168.0.0/16 można dzielić dowolnie?
Tak. Przestrzeń z RFC 1918 wolno dzielić na dowolnej długości prefiksu i nikt spoza sieci tego nie widzi. Ograniczenie jest wewnętrzne: nałożenie się na sieć partnera albo na chmurowy VPC, z którym dojdzie później do peeringu, kosztownie się rozplątuje, dlatego plany zwykle omijają bloki, których używa już każdy domowy router.
Prefiks zlicza bity sieci, a rozmiar bloku to 256 − graniczny oktet maski. Adres zaokrągla się w dół do wielokrotności rozmiaru bloku, żeby dostać sieć, i dodaje rozmiar bloku minus jeden, żeby dostać rozgłoszenie. Odejmuje się dwa za zarezerwowaną parę, ale tylko wtedy, gdy /31 albo /32 nie usunęło już powodu do odejmowania. Wildcard od maski podsieci odróżnia się po kształcie. Duże bloki przydziela się przed małymi.
Gdy to raz wejdzie w krew, narzędzie przestaje być potrzebne. Po to właśnie przerabia się takie rachunki na piechotę. Do sprawdzenia planu, zanim trafi na router, albo do odczytania binarnej granicy bloku jednym spojrzeniem kalkulator podsieci wykona arytmetykę lokalnie w przeglądarce.