Адресация IPv4 и разбиение на подсети

В темах 4 и 5 узлы находили друг друга по MAC-адресам, а коммутаторы учились, за каким портом какой адрес находится. Этот способ хорош в пределах широковещательного домена, но не масштабируется дальше: MAC-адрес ничего не говорит о местоположении узла, и коммутатору приходится помнить каждый адрес отдельно и рассылать лавиной кадры к ещё не изученным. Сеть из миллиардов узлов на таком принципе построить нельзя. Сетевой уровень решает задачу доставки между сетями иначе — с помощью адресов, в которых закодировано, к какой сети принадлежит узел. Такие адреса и рассматриваются в этой теме.

Протокол IP четвёртой версии (англ. Internet Protocol version 4, IPv4) использует 32-битные адреса ¹. Каждый адрес делится на две части: старшие биты указывают на сеть, младшие — на узел внутри неё. Граница между частями и способы её задания составляют основную техническую сторону темы: от жёсткой классовой схемы 1981 года к бесклассовой адресации CIDR, позволяющей нарезать адресное пространство блоками любой длины, кратной степени двойки, и объединять маршруты к соседним блокам в один. Практическая сторона — расчёт подсетей: по адресу и префиксу найти сеть, широковещательный адрес и диапазон узлов, разделить выданный организации блок на подсети под отделы и сегменты, составить адресный план с запасом на рост.

Изложение построено так. Сначала разбираются структура адреса, двоичная запись и маска. Затем прослеживается история перехода от классов к CIDR и вводится агрегирование маршрутов. Третий раздел посвящён специальным адресам по реестру IANA, четвёртый — технике расчёта подсетей с проверкой модулем ipaddress языка Python, пятый — тому, как адреса распределяются между организациями и почему адреса IPv4 закончились. Устройство заголовка IP и работа ARP рассматриваются в теме 7, выбор маршрута по адресу — в теме 8, автоматическая выдача адресов — в теме 14, адресация IPv6 — в теме 11.

Иерархическая адресация и структура адреса IPv4

Зачем адресу иерархия

Адрес может быть плоским или иерархическим. Плоский адрес — уникальный номер без внутренней структуры, как MAC-адрес или номер паспорта: по нему можно опознать объект, но нельзя понять, где он находится. Иерархический адрес устроен как почтовый: страна, город, улица, дом, квартира. Почтовому отделению в Москве не нужно знать все дома Новосибирска — достаточно знать, что письма с городом «Новосибирск» отправляются в определённый сортировочный центр. Только последнее звено цепочки разбирается с номером квартиры.

Адрес IPv4 иерархичен в том же смысле. Маршрутизатор хранит не адреса отдельных узлов, а записи о сетях: «адреса, начинающиеся с таких-то битов, — через такой-то соседний маршрутизатор». Одна запись покрывает сколько угодно узлов одной сети, а при правильно спланированном распределении адресов — и множество соседних сетей сразу. Благодаря этому таблица маршрутизации ядра Интернета насчитывает около миллиона записей при нескольких миллиардах подключённых устройств, а таблица маршрутизатора небольшой организации — единицы записей. Плата за иерархию — адрес узла зависит от его места в сети ¹³: при переезде в другую сеть узел получает новый адрес, и это одна из причин, по которым IP-адреса на практике назначаются автоматически (тема 14).

Заметим, что адрес IP, строго говоря, принадлежит не узлу, а его сетевому интерфейсу. Маршрутизатор с тремя интерфейсами имеет три адреса в трёх разных сетях, а хост с проводным и беспроводным подключениями — два. Говоря «адрес узла», подразумевают адрес интерфейса, если из контекста не следует иное.

Двоичная и десятичная запись

Адрес IPv4 — 32-битное число; всего таких чисел 2³² = 4 294 967 296. Для записи человеком используется точечно-десятичная нотация (англ. dotted decimal notation): 32 бита делятся на четыре байта, называемых октетами (англ. octet), каждый октет записывается десятичным числом от 0 до 255, и числа разделяются точками ¹. Адрес 192.168.10.77 в двоичной записи выглядит так:

192       168       10        77
11000000  10101000  00001010  01001101

Перевод октета в двоичную форму выполняется разложением по степеням двойки: веса битов слева направо равны 128, 64, 32, 16, 8, 4, 2, 1. Число 77 = 64 + 8 + 4 + 1, поэтому установлены биты с весами 64, 8, 4 и 1: 01001101. Обратный перевод — суммирование весов установленных битов: 11000000 = 128 + 64 = 192. При расчёте подсетей полезно помнить значения октетов, состоящих из единиц в старших разрядах, — именно такие октеты встречаются в масках:

Точечно-десятичная запись — лишь удобство для человека. Компьютер работает с адресом как с 32-битным числом, и в заголовке пакета адрес передаётся четырьмя байтами в сетевом порядке (старший байт первым). Отсюда несколько неочевидных следствий: запись 010.1.1.1 некоторые программы понимают как восьмеричную (010 = 8), а ping 3232238157 в Linux отправит эхо-запрос на 192.168.10.77, потому что 3 232 238 157 — то же число в десятичной записи целиком.

Сеть и узел: маска и длина префикса

Граница между сетевой частью и номером узла задаётся маской подсети (англ. subnet mask) — 32-битным числом, у которого единицы стоят в разрядах сетевой части, а нули — в разрядах номера узла. Маска записывается так же, как адрес, точечно-десятичной нотацией: маска 255.255.255.192 содержит 26 единиц и 6 нулей. Единицы маски обязаны идти подряд с самого старшего разряда; ранние стандарты формально допускали «разрывные» маски ², но современная адресация и все реализации маршрутизации требуют непрерывности ³. Поэтому маску однозначно определяет число единиц — длина префикса (англ. prefix length), — и принято записывать адрес вместе с длиной префикса через косую черту: 192.168.10.77/26. Такая запись называется нотацией CIDR.

Сетевая часть адреса — его префикс — вычисляется поразрядной операцией «И» (англ. bitwise AND) адреса и маски: в разрядах, где у маски единица, бит адреса сохраняется, где ноль — обнуляется. Номер узла получается операцией «И» адреса с инвертированной маской.

Рисунок показывает вычисление для адреса 192.168.10.77/26. Первые три октета маски — 255, они пропускают октеты адреса без изменений. Четвёртый октет маски 11000000 оставляет от 01001101 только два старших бита: 01000000 = 64. Сеть — 192.168.10.64/26. Номер узла — шесть младших битов 001101 = 13, то есть узел 13 в этой сети. В сети с префиксом длины p номер узла занимает 32 − p бит, поэтому сеть содержит 2³²⁻ᵖ адресов. Для /26 это 2⁶ = 64 адреса: от 192.168.10.64 до 192.168.10.127.

Два адреса каждой сети зарезервированы. Адрес, у которого все биты номера узла нулевые, обозначает саму сеть (англ. network address) и не назначается интерфейсу. Адрес, у которого все биты номера узла единичные, — широковещательный адрес этой сети (англ. directed broadcast address): пакет на него доставляется всем узлам сети ². Для назначения интерфейсам остаётся 2³²⁻ᵖ − 2 адресов; в сети /26 — 62 адреса, от .65 до .126. Исключения из этого правила — сети /31 и /32 — рассматриваются в разделе о специальных адресах.

Операционная система применяет маску постоянно. Получив от приложения пакет для отправки, хост сравнивает префикс адреса назначения с префиксом своего интерфейса: если они совпадают, получатель находится в той же сети, и пакет отправляется ему непосредственно (сначала нужно узнать его MAC-адрес — тема 7); если нет — пакет отправляется маршрутизатору. В Linux адрес с префиксом задаётся командой ip addr add; ключ brd + просит вычислить широковещательный адрес из префикса. Ядро сразу добавляет в таблицу маршрутизации запись о непосредственно подключённой сети:

ip addr add 10.5.0.1/24 brd + dev eth0
ip -4 addr show dev eth0
ip route

6: eth0@x: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.5.0.1/24 brd 10.5.0.255 scope global eth0
       valid_lft forever preferred_lft forever
10.5.0.0/24 dev eth0 proto kernel scope link src 10.5.0.1

Поле brd показывает широковещательный адрес, а строка маршрута — сеть, которую ядро считает непосредственно достижимой. Неверная маска — одна из самых частых ошибок настройки: узел с маской /16 вместо /24 будет пытаться достичь «соседей» непосредственно, хотя они находятся за маршрутизатором, а узел с маской /28 вместо /24 отправит маршрутизатору пакеты для соседей по сегменту.

От классов к бесклассовой адресации

Классовая адресация

Первоначальная схема, закреплённая в RFC 791 в 1981 году, не нуждалась в маске: граница между сетью и узлом определялась первыми битами самого адреса ¹. Адресное пространство делилось на классы.

Как видно на рисунке, классовая схема позволяет маршрутизатору определить сетевую часть по одному взгляду на первые биты адреса. Но выбор оказался слишком грубым. Сетей класса A было всего 128, и каждая содержала более 16 миллионов адресов; ими владели крупные корпорации и ведомства, использовавшие лишь малую долю. Сеть класса C в 256 адресов была мала для большинства организаций, поэтому они запрашивали сеть класса B на 65 536 адресов, даже если им нужно было 2000. К началу 1990-х годов стало ясно, что сетей класса B хватит лишь на несколько лет, а если раздавать вместо них множество сетей класса C, таблицы маршрутизации магистральных маршрутизаторов разрастутся до неприемлемых размеров ³. Две проблемы — расточительное расходование адресов и рост таблиц — потребовали отказаться от классов.

Подсети и бесклассовая маршрутизация

Первый шаг был сделан ещё в 1985 году: RFC 950 разрешил организации делить свою классовую сеть на подсети (англ. subnets), заимствуя старшие биты номера узла под номер подсети и задавая границу маской ². Сеть класса B 172.16.0.0 можно было разбить, например, на 256 подсетей по 256 адресов маской 255.255.255.0. Снаружи организация по-прежнему выглядела одной сетью класса B, и внешние маршрутизаторы о подсетях не знали.

Решающим стал переход к бесклассовой междоменной маршрутизации (англ. Classless Inter-Domain Routing, CIDR), предложенной в 1993 году в RFC 1519 и обновлённой в 2006 году в RFC 4632 ³. CIDR отменил классы целиком: граница между сетью и узлом может проходить после любого бита, длина префикса передаётся явно вместе с каждым маршрутом, а блоки адресов выдаются организациям размером «по потребности» — 2ᵏ адресов при подходящем k. Организации, которой нужно 2000 адресов, выдаётся блок /21 (2048 адресов), а не сеть класса B. Протоколы маршрутизации, передававшие только адрес сети без маски, были заменены или дополнены (BGP четвёртой версии, OSPF и RIPv2 передают длину префикса), и маршрутизаторы научились выбирать маршрут по наибольшему совпадающему префиксу — подробно в теме 8.

Классовая терминология тем не менее сохранилась в профессиональной речи: «сеть класса C» часто говорят о любом блоке /24, а некоторые программы при отсутствии явной маски подставляют классовую. Настраивая адрес, маску следует указывать всегда.

Агрегирование маршрутов

Вторая сторона CIDR — агрегирование (англ. route aggregation, также summarization, суммаризация): несколько соседних блоков с общим префиксом можно описать одной записью с более коротким префиксом ³. Пусть филиалу выделены сети 10.20.0.0/24, 10.20.1.0/24, 10.20.2.0/24 и 10.20.3.0/24. Выпишем третий октет:

10.20.0.0   ...  00000000
10.20.1.0   ...  00000001
10.20.2.0   ...  00000010
10.20.3.0   ...  00000011

У всех четырёх сетей совпадают первые 16 бит и ещё 6 старших бит третьего октета — всего 22 бита, а различаются только два последних бита третьего октета. Значит, вместе они образуют блок 10.20.0.0/22, и маршрутизатору главного офиса достаточно одной записи «10.20.0.0/22 — через маршрутизатор филиала» вместо четырёх. Блок /22 при этом содержит ровно эти четыре сети, не больше и не меньше.

Агрегировать можно не любые соседние сети. Сети 10.20.1.0/24 и 10.20.2.0/24 соседние, но в одну сеть /23 не объединяются: блок /23 должен начинаться с адреса, у которого последний бит сетевой части равен нулю, а 10.20.1.0 (третий октет 00000001) этому не удовлетворяет. Ближайший общий блок — 10.20.0.0/22 — включает и чужие сети 10.20.0.0/24 и 10.20.3.0/24. Общее правило: блок длины p начинается с адреса, кратного 2³²⁻ᵖ, и 2ᵏ блоков длины p объединяются в один блок длины p − k, только если первый из них выровнен по границе 2³²⁻⁽ᵖ⁻ᵏ⁾.

Агрегирование оправдывает иерархическое распределение адресов. Провайдер, получивший блок /16, выдаёт клиентам блоки из него и объявляет в Интернет один маршрут /16, а не сотни клиентских. Организация, раздавшая адреса филиалам из непрерывных выровненных блоков, обходится в главном офисе одной записью на филиал. Если же адреса раздавались бессистемно, агрегирование становится невозможным, и каждый новый сегмент прибавляет запись в таблицы всех маршрутизаторов. Поэтому адресный план составляют с расчётом на агрегирование с самого начала.

Специальные адреса

Адреса сети, широковещательные адреса и короткие сети

Помимо адресов сети и направленного широковещания, о которых говорилось выше, есть ограниченный широковещательный адрес (англ. limited broadcast) 255.255.255.255: пакет на него доставляется всем узлам своего сегмента и никогда не пересылается маршрутизаторами. Им пользуется, например, клиент DHCP, ещё не знающий ни своего адреса, ни адреса сети (тема 14). Направленное широковещание в чужую сеть (пакет на 192.168.10.127 извне сети 192.168.10.64/26) маршрутизаторы по умолчанию тоже не пересылают: в 1990-е годы такие пакеты использовались для атак с усилением (англ. smurf attack), когда один пакет, отправленный на широковещательный адрес чужой сети, вызывал ответы всех её узлов.

Резервирование двух адресов неприятно на звеньях «точка — точка» между двумя маршрутизаторами: сеть /30 содержит четыре адреса, из которых используются два, и половина адресного пространства звеньев тратится впустую. RFC 3021 разрешил использовать на таких звеньях сети /31 из двух адресов без адреса сети и широковещательного: оба адреса назначаются интерфейсам ⁹. Префикс /32 обозначает один адрес; так записываются маршруты к отдельному узлу и адреса интерфейсов обратной петли маршрутизаторов.

Реестр адресов специального назначения

Ряд блоков адресного пространства IPv4 зарезервирован для особых целей. Их перечень ведёт IANA в реестре адресов специального назначения (англ. IANA IPv4 Special-Purpose Address Registry), правила ведения которого установлены RFC 6890 ⁶. В таблице — блоки, которые встречаются на практике.

Блок 127.0.0.0/8 целиком принадлежит интерфейсу обратной петли: пакет на любой его адрес не покидает узел. Это 16 миллионов адресов, используемых на практике одним 127.0.0.1, — наследие классовой эпохи, когда меньший блок выделить было нельзя. Блок 240.0.0.0/4 — ещё 268 миллионов адресов — формально свободен, но многие операционные системы и сетевое оборудование отказываются работать с такими адресами, и предложения вернуть его в оборот пока не приняты.

Частные, общие и локальные адреса

Частные адреса (англ. private addresses) RFC 1918 — три блока, которые любая организация может использовать внутри своей сети без согласования с кем-либо ⁴. Они не уникальны глобально: адрес 192.168.1.1 есть в миллионах домашних сетей. Поэтому маршрутизаторы Интернета не принимают маршрутов к частным адресам, а узел с частным адресом выходит в Интернет через трансляцию адресов NAT, заменяющую его адрес на публичный (тема 14). Выбор блока — дело вкуса и масштаба: 192.168.0.0/16 удобен для небольших сетей, 10.0.0.0/8 даёт 16 миллионов адресов для крупных организаций. Практический совет — избегать самых популярных сетей 192.168.0.0/24 и 192.168.1.0/24 в корпоративной сети: сотрудник, подключившийся через VPN из дома, где используется та же сеть, получит конфликт маршрутов.

Блок 100.64.0.0/10 выделен в 2012 году для провайдеров, которым не хватает публичных адресов для абонентов ⁵. Провайдер назначает абонентским маршрутизаторам адреса из этого блока и транслирует их в публичные на своём оборудовании — трансляция операторского уровня (англ. Carrier-Grade NAT, CGNAT). Отдельный блок понадобился потому, что частные адреса RFC 1918 уже использует сам абонент внутри дома, и одна и та же сеть по разные стороны абонентского маршрутизатора сделала бы маршрутизацию невозможной. Если интерфейс домашнего маршрутизатора со стороны провайдера имеет адрес из 100.64.0.0/10, абонент находится за CGNAT и входящие соединения из Интернета к нему невозможны без участия провайдера.

Локальные адреса канала 169.254.0.0/16 узел назначает себе сам, если в сети нет сервера DHCP: выбирает случайный адрес из блока и проверяет с помощью ARP, что он свободен ⁷. Такие адреса действуют только в пределах одного сегмента и маршрутизаторами не пересылаются. Появление адреса 169.254.x.y на рабочей станции — верный признак того, что она не получила адрес от DHCP. Адрес 169.254.169.254 используется облачными платформами для службы метаданных виртуальных машин.

Документационные блоки RFC 5737 предназначены для книг, статей и примеров конфигураций ⁸: в них можно писать «публичные» адреса, не рискуя, что читатель, скопировав пример, нарушит работу чужой сети. В этом курсе публичные адреса берутся из этих блоков.

Блок групповой рассылки 224.0.0.0/4 делится на подблоки по назначению ¹⁰. Адреса 224.0.0.0/24 локальны для сегмента (например, 224.0.0.5 — все маршрутизаторы OSPF, тема 9; 224.0.0.251 — mDNS); адреса 239.0.0.0/8 предназначены для использования внутри организации, как частные адреса для одноадресной связи. Групповой адрес обозначает не узел, а группу получателей и не может быть адресом источника.

Модуль ipaddress стандартной библиотеки Python знает реестр специальных адресов и позволяет проверить принадлежность адреса к категориям ¹¹:

import ipaddress
for a in ["10.1.2.3", "100.64.1.1", "169.254.7.7", "192.0.2.10", "224.0.0.5", "8.8.8.8"]:
    x = ipaddress.ip_address(a)
    print(f"{a:12} private={x.is_private!s:5} global={x.is_global!s:5} "
          f"link_local={x.is_link_local!s:5} multicast={x.is_multicast}")

10.1.2.3     private=True  global=False link_local=False multicast=False
100.64.1.1   private=False global=False link_local=False multicast=False
169.254.7.7  private=True  global=False link_local=True  multicast=False
192.0.2.10   private=True  global=False link_local=False multicast=False
224.0.0.5    private=False global=True  link_local=False multicast=True
8.8.8.8      private=False global=True  link_local=False multicast=False

Обратим внимание, что признак is_private в модуле понимается шире, чем в RFC 1918: он истинен для всех блоков, которые реестр IANA помечает как не глобально достижимые, включая документационные и локальные адреса канала, но не для общего адресного пространства 100.64.0.0/10, которое не является ни частным, ни глобальным. Признак is_global у группового адреса 224.0.0.5 истинен, хотя адреса 224.0.0.0/24 за пределы сегмента не выходят: модуль классифицирует адреса по реестру одноадресных блоков, а область действия групповых адресов не учитывает. Вывод получен на Python 3.10; в версиях 3.11.10+, 3.12.4+ и 3.13 классификация is_private/is_global была пересмотрена вслед за реестром IANA, поэтому на Ubuntu 24.04 (Python 3.12) вывод для части адресов может отличаться, поэтому для проверки принадлежности к RFC 1918 надёжнее явно сравнивать с тремя блоками.

Расчёт подсетей

Обратная задача: сеть по адресу

Самая частая задача — по адресу интерфейса и длине префикса найти адрес сети, широковещательный адрес, диапазон адресов узлов и их число. Вычисление через двоичную запись всегда возможно, но для расчётов в уме удобнее приём «интересного октета». Октет, в котором проходит граница префикса, называют интересным (при префиксе от 17 до 24 — третий, от 25 до 32 — четвёртый). Размер блока в этом октете равен 256 минус значение маски в нём. Адрес сети получается округлением интересного октета адреса вниз до числа, кратного размеру блока; октеты левее копируются из адреса, правее — заполняются нулями. Широковещательный адрес — адрес сети плюс размер блока минус единица в интересном октете и 255 во всех октетах правее.

Подробный пример. Дан адрес 172.16.45.201/21.

1. Маска /21: 8 + 8 + 5 единиц, то есть 255.255.248.0. Интересный октет — третий, значение маски в нём 248 (11111000).
2. Размер блока: 256 − 248 = 8. Сети идут по третьему октету с шагом 8: 0, 8, 16, 24, 32, 40, 48, …
3. Третий октет адреса — 45. Наибольшее кратное 8, не превышающее 45, — 40. Адрес сети: 172.16.40.0/21.
4. Широковещательный адрес: третий октет 40 + 8 − 1 = 47, четвёртый — 255: 172.16.47.255.
5. Адреса узлов: от 172.16.40.1 до 172.16.47.254; их число 2³²⁻²¹ − 2 = 2048 − 2 = 2046.

Проверим двоичной записью третьего октета: 45 = 00101101; маска оставляет пять старших бит 00101 и обнуляет три младших — 00101000 = 40. Совпадает. Модуль ipaddress даёт тот же результат:

import ipaddress
i = ipaddress.ip_interface("172.16.45.201/21")
n = i.network
print(n, n.netmask, n.broadcast_address, n[1], n[-2], n.num_addresses - 2)

172.16.40.0/21 255.255.248.0 172.16.47.255 172.16.40.1 172.16.47.254 2046

Тот же приём отвечает и на вопрос «находятся ли два адреса в одной сети». Адреса 172.16.40.10/21 и 172.16.47.200/21 — в одной сети (третьи октеты 40 и 47 попадают в один блок 40–47), а 172.16.39.250/21 — в соседней сети 172.16.32.0/21, хотя численно этот адрес ближе к первому, чем 172.16.47.200. Граница сетей определяется выравниванием блоков, а не близостью чисел.

Деление сети на равные подсети

Обратная операция — разделить блок на подсети. Если блок длины p нужно разделить на 2ᵏ равных подсетей, их префикс равен p + k, а размер каждой — 2³²⁻⁽ᵖ⁺ᵏ⁾. Разделим сеть 192.168.10.0/24 на четыре подсети: k = 2, префикс подсетей /26, размер 64 адреса.

Если требуется не число подсетей, а число узлов в каждой, вычисляется минимальное h такое, что 2ʰ − 2 не меньше требуемого числа узлов, и префикс равен 32 − h. Для 100 узлов: 2⁶ − 2 = 62 мало, 2⁷ − 2 = 126 достаточно, префикс /25. В число узлов обязательно включается интерфейс маршрутизатора — шлюза сегмента, а также адреса принтеров, точек доступа, коммутаторов с управляющими адресами.

Исторически одна из подсетей вызывала сомнения: RFC 950 не рекомендовал использовать «нулевую» подсеть (первую, у которой номер подсети состоит из нулей) и подсеть «из всех единиц», так как их адреса сети и широковещательный совпадали с адресами исходной классовой сети ². В бесклассовой адресации это ограничение потеряло смысл, и все подсети используются наравне ³. Старые учебники и задачники иногда сохраняют правило «2ᵏ − 2 подсетей» — в современной практике подсетей 2ᵏ.

VLSM и адресный план

Сегменты реальной сети имеют разные размеры, и деление на равные подсети расточительно: если все подсети сделать по размеру наибольшей, маленьким сегментам достанется много лишних адресов. Метод масок переменной длины (англ. Variable Length Subnet Masking, VLSM) выделяет каждому сегменту подсеть подходящего размера из общего блока ³. Чтобы блоки не пересекались и были правильно выровнены, применяется простой алгоритм: требования сортируются по убыванию размера, и подсети выделяются подряд, начиная с наибольшей; каждая следующая начинается с первого свободного адреса, выровненного по её размеру. При выделении по убыванию выравнивание соблюдается автоматически, потому что размер каждой следующей подсети делит размер всех предыдущих.

Составим адресный план офиса «Северного узла», которому выделен блок частных адресов 10.10.0.0/22 (1024 адреса). Требования заданы числом узлов, включая шлюз сегмента, и к каждому добавлен запас на рост 25 % с округлением вверх. Для двух звеньев «точка — точка» между маршрутизаторами запас не нужен.

Проверим одно значение. Сегменту «Бухгалтерия» с запасом нужно 57 адресов узлов: 2⁶ − 2 = 62 ≥ 57, значит, префикс /26. После подсетей разработки, гостевой сети и продаж первый свободный адрес — 10.10.2.128; он кратен 64 (128 = 2 · 64), поэтому подсеть начинается прямо с него. Распределение занимает 760 адресов из 1024, свободными остаются 10.10.2.248/29 и 10.10.3.0/24. Свободный блок /24 в конце важнее, чем может показаться: он позволит без перенумерации добавить новый сегмент среднего размера или расширить один из существующих.

Рисунок показывает план в виде линейки адресного пространства. Видно, что подсети не пересекаются, каждая начинается на границе своего размера, а весь план агрегируется одной записью 10.10.0.0/22 для маршрутизаторов филиала и провайдера VPN. Хороший адресный план обладает и свойствами, которые не следуют из алгоритма, а задаются соглашениями: адрес шлюза в каждом сегменте выбирается единообразно (обычно первый адрес подсети, .1), номер VLAN связан с адресом (например, VLAN 20 — подсеть 10.10.2.0/25), диапазоны под статические адреса серверов и под выдачу по DHCP разделены, и план документирован в таблице, подобной приведённой выше.

Типичные ошибки адресного плана таковы. Пересечение подсетей: если «Продажам» выдать 10.10.2.0/24, этот блок включит и подсети бухгалтерии, серверной и управления, и маршрутизатор не сможет однозначно решить, в какой сегмент направить пакет. Неверное выравнивание: подсеть 10.10.2.160/26 не существует, потому что 160 не кратно 64, — адрес 10.10.2.160 с префиксом /26 принадлежит сети 10.10.2.128/26. Отсутствие запаса: сегмент, в который через год не помещаются новые сотрудники, приходится перенумеровывать вместе со всеми настройками и правилами межсетевого экрана. Разбросанность: подсети одного филиала, выделенные из разных частей адресного пространства, не агрегируются.

Проверка расчётов программой

Расчёт подсетей легко автоматизировать, и для проверки ручного расчёта модуль ipaddress незаменим ¹¹. Объект IPv4Network поддерживает перечисление подсетей заданной длины, проверку вложенности и пересечения, исключение подсети из блока и объединение соседних блоков:

import ipaddress as ip
base = ip.ip_network("10.10.0.0/22")
plan = [ip.ip_network(s) for s in (
    "10.10.0.0/24", "10.10.1.0/24", "10.10.2.0/25", "10.10.2.128/26",
    "10.10.2.192/27", "10.10.2.224/28", "10.10.2.240/30", "10.10.2.244/30")]
assert all(n.subnet_of(base) for n in plan)                       # все внутри блока
assert not any(a.overlaps(b) for i, a in enumerate(plan) for b in plan[i+1:])
free = [base]
for n in plan:                                                    # вычесть занятые
    free = [r for f in free for r in (f.address_exclude(n) if n.subnet_of(f) else [f])]
print(sorted(free))
print(list(ip.collapse_addresses(ip.ip_network(f"10.20.{k}.0/24") for k in range(4))))
print(ip.ip_network("10.10.2.160/26"))

[IPv4Network('10.10.2.248/29'), IPv4Network('10.10.3.0/24')]
[IPv4Network('10.20.0.0/22')]
Traceback (most recent call last):
  ...
ValueError: 10.10.2.160/26 has host bits set

Последняя строка программы показывает, что модуль отвергает «сеть», у которой установлены биты номера узла: 10.10.2.160/26 — это адрес узла, а не адрес сети. Для получения сети по адресу узла служит ip_interface(...).network или параметр strict=False. В лабораторной работе 6 на основе этого модуля пишется калькулятор подсетей, а в практическом занятии 6 решаются задачи на ручной расчёт.

Распределение адресного пространства

IANA, региональные регистратуры и локальные регистратуры

Уникальность публичных адресов обеспечивает иерархия организаций, называемая системой реестров интернет-номеров ¹². На вершине находится IANA (англ. Internet Assigned Numbers Authority) — функция, исполняемая ныне организацией PTI в составе ICANN. IANA распределяет адресное пространство блоками /8 между пятью региональными интернет-регистратурами (англ. Regional Internet Registry, RIR):

• AFRINIC — Африка;
• APNIC — Азиатско-Тихоокеанский регион;
• ARIN — США, Канада, часть Карибского бассейна;
• LACNIC — Латинская Америка и часть Карибского бассейна;
• RIPE NCC — Европа, Ближний Восток и Центральная Азия, включая Россию.

Региональные регистратуры, в свою очередь, выделяют блоки своим членам — локальным интернет-регистратурам (англ. Local Internet Registry, LIR), которыми обычно выступают провайдеры и крупные организации. Провайдер назначает адреса из своего блока клиентам. Правила распределения в каждом регионе вырабатывает сообщество по открытой процедуре: в регионе RIPE NCC — рабочие группы RIPE, решения которых оформляются документами политики. Сведения о том, кому выделен блок, публикуются в базах данных регистратур и доступны по протоколу WHOIS и его преемнику RDAP (whois 193.0.6.139 вернёт запись о сети RIPE NCC).

Иерархия, изображённая на рисунке, повторяет иерархию самих адресов и служит агрегированию: адреса клиентов провайдера входят в его блок, и в таблицах маршрутизации Интернета провайдер представлен одним или несколькими префиксами. Организации, которые не хотят зависеть от провайдера при смене подключения, получают собственный независимый блок (англ. provider-independent, PI) и объявляют его по BGP (тема 10). Цена — лишняя запись в таблицах всех маршрутизаторов Интернета, поэтому в глобальной маршрутизации не принимаются префиксы длиннее /24.

Исчерпание адресов IPv4

Тридцать два бита казались в 1981 году неисчерпаемым запасом, но рост Интернета в 1990-е и 2000-е годы показал обратное. Из 4,3 миллиарда адресов около 590 миллионов недоступны для одноадресного использования (групповой и зарезервированный бывшие классы D и E, обратная петля, частные блоки), а распределение блоками неизбежно оставляет часть адресов неиспользованной. Работа над преемником — IPv6 со 128-битными адресами — началась ещё в первой половине 1990-х годов (тема 11), а CIDR и NAT задумывались как временные меры, позволяющие дотянуть до его внедрения.

Исчерпание произошло в несколько этапов ¹⁴. 3 февраля 2011 года IANA выделила последние пять блоков /8, по одному каждой регистратуре, и центральный запас закончился. В апреле 2011 года APNIC перешла к выдаче из последнего блока /8 по строгим правилам — не более /22 на одного члена. RIPE NCC достигла последнего /8 14 сентября 2012 года и 25 ноября 2019 года объявила о полном исчерпании свободного пространства; с тех пор новым членам выдаются лишь возвращённые адреса в порядке очереди, блоками /24. ARIN исчерпала свободный пул в сентябре 2015 года, LACNIC — в 2020 году. AFRINIC дольше других сохраняла запас и тоже перешла к последней фазе распределения.

Рынок адресов и последствия исчерпания

Исчерпание свободного пула не означает, что адресов нет: они распределены, но используются неравномерно. Организации, получившие крупные блоки в классовую эпоху, используют лишь их часть, и политика регистратур с начала 2010-х годов разрешила передачу адресов (англ. transfer) между организациями. Возник рынок адресов IPv4: адреса покупаются и продаются через брокеров, а регистратура лишь фиксирует смену владельца. По данным брокеров, цена одного адреса выросла с порядка 10 долларов США в середине 2010-х годов до 50–60 долларов в 2021–2022 годах, после чего снизилась; отдельные крупные блоки продавались за десятки миллионов долларов. Распространена и аренда адресов.

Для пользователей сети исчерпание имеет практические следствия. Домашние абоненты всё чаще оказываются за CGNAT и не могут принимать входящие соединения. Облачные платформы начали взимать плату за каждый публичный адрес IPv4. Организации экономят публичные адреса, размещая за одним адресом множество служб с помощью трансляции адресов и обратных прокси-серверов (темы 14 и 16). Долгосрочное решение — IPv6, доля которого в трафике крупных платформ превысила 40 %, но двойной стек IPv4 и IPv6 сохранится ещё долго, и умение рассчитывать подсети IPv4 остаётся обязательным навыком сетевого инженера.

Итоги темы

Адрес IPv4 — 32-битное число, записываемое четырьмя десятичными октетами, и смысл его определяется делением на сетевую часть и номер узла. Иерархия адреса позволяет маршрутизаторам хранить сведения о сетях, а не об отдельных узлах. Граница частей задаётся маской или, что то же, длиной префикса; адрес сети вычисляется поразрядным «И» адреса и маски, а сеть с префиксом p содержит 2³²⁻ᵖ адресов, из которых два — адрес сети и широковещательный — не назначаются интерфейсам, кроме сетей /31 и /32.

Классовая адресация с границей, зашитой в первых битах адреса, привела к расточительному распределению и росту таблиц маршрутизации и в 1993 году уступила место бесклассовой адресации CIDR, в которой длина префикса произвольна и передаётся с каждым маршрутом. Вторая сторона CIDR — агрегирование: выровненные соседние блоки объединяются в один, и именно ради агрегирования адреса распределяются иерархически, от IANA через региональные регистратуры к провайдерам и организациям. Ряд блоков зарезервирован для особых целей — частные адреса RFC 1918, общее пространство CGNAT, локальные адреса канала, обратная петля, документационные и групповые адреса, — и сетевой инженер должен узнавать их с первого взгляда.

Расчёт подсетей сводится к нескольким приёмам: найти сеть по адресу через интересный октет и размер блока, разделить блок на равные подсети, распределить блок между сегментами разного размера методом VLSM по убыванию размеров с выравниванием и запасом на рост. Хороший адресный план не содержит пересечений, агрегируется, оставляет резерв и документирован; результат расчёта проверяется программой с модулем ipaddress.

Свободный пул адресов IPv4 исчерпан с 2011–2020 годов, и последствия исчерпания — CGNAT, рынок адресов, платные публичные адреса — определяют облик современных сетей. Адреса и подсети, рассмотренные в этой теме, — исходный материал для следующих: в теме 7 будет показано, как пакет с этими адресами устроен и как хост находит MAC-адрес соседа по сети, в теме 8 — как маршрутизатор выбирает путь по наибольшему совпадающему префиксу.

Литература

1. Postel J. Internet Protocol. — RFC 791, IETF, 1981. https://www.rfc-editor.org/rfc/rfc791
2. Mogul J., Postel J. Internet Standard Subnetting Procedure. — RFC 950, IETF, 1985. https://www.rfc-editor.org/rfc/rfc950
3. Fuller V., Li T. Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. — RFC 4632, IETF, 2006. https://www.rfc-editor.org/rfc/rfc4632
4. Rekhter Y., Moskowitz B., Karrenberg D., de Groot G. J., Lear E. Address Allocation for Private Internets. — RFC 1918, IETF, 1996. https://www.rfc-editor.org/rfc/rfc1918
5. Weil J., Kuarsingh V., Donley C., Liljenstolpe C., Azinger M. IANA-Reserved IPv4 Prefix for Shared Address Space. — RFC 6598, IETF, 2012. https://www.rfc-editor.org/rfc/rfc6598
6. Cotton M., Vegoda L., Bonica R., Haberman B. Special-Purpose IP Address Registries. — RFC 6890, IETF, 2013. https://www.rfc-editor.org/rfc/rfc6890
7. Cheshire S., Aboba B., Guttman E. Dynamic Configuration of IPv4 Link-Local Addresses. — RFC 3927, IETF, 2005. https://www.rfc-editor.org/rfc/rfc3927
8. Arkko J., Cotton M., Vegoda L. IPv4 Address Blocks Reserved for Documentation. — RFC 5737, IETF, 2010. https://www.rfc-editor.org/rfc/rfc5737
9. Retana A., White R., Fuller V., McPherson D. Using 31-Bit Prefixes on IPv4 Point-to-Point Links. — RFC 3021, IETF, 2000. https://www.rfc-editor.org/rfc/rfc3021
10. Cotton M., Vegoda L., Meyer D. IANA Guidelines for IPv4 Multicast Address Assignments. — RFC 5771, IETF, 2010. https://www.rfc-editor.org/rfc/rfc5771
11. Python Software Foundation. ipaddress — IPv4/IPv6 manipulation library. — 2025. https://docs.python.org/3/library/ipaddress.html
12. Housley R., Curran J., Huston G., Conrad D. The Internet Numbers Registry System. — RFC 7020, IETF, 2013. https://www.rfc-editor.org/rfc/rfc7020
13. Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach. 8th ed. — Pearson, 2021.
14. Huston G. IPv4 Address Report. — 2025. https://ipv4.potaroo.net/

Дополнительные материалы

Вопросы для самопроверки

1. Чем иерархический адрес отличается от плоского и почему иерархия уменьшает таблицы маршрутизации?
2. Почему говорят, что адрес IP принадлежит интерфейсу, а не узлу? Сколько адресов у маршрутизатора с тремя подключёнными сетями?
3. Переведите 10.200.15.129 в двоичную запись и найдите сеть этого адреса при префиксах /20, /25 и /30.
4. Почему единицы маски обязаны идти подряд? Что было бы неудобно при «разрывной» маске?
5. Какие две проблемы привели к отказу от классовой адресации? Как CIDR решает каждую?
6. При каком условии четыре сети /24 объединяются в одну /22? Приведите пример четырёх соседних сетей /24, которые в одну /22 не объединяются.
7. Чем ограниченный широковещательный адрес отличается от направленного? Почему маршрутизаторы не пересылают направленные широковещательные пакеты из чужих сетей?
8. Зачем RFC 3021 разрешил префикс /31 и почему он подходит только для звеньев «точка — точка»?
9. Почему для CGNAT выделен отдельный блок 100.64.0.0/10, а не используются частные адреса RFC 1918?
10. Что означает появление на рабочей станции адреса из 169.254.0.0/16?
11. Почему при выделении подсетей методом VLSM их выделяют по убыванию размера?
12. Назовите четыре типичные ошибки адресного плана и способ обнаружить каждую.
13. Как распределяются адреса IPv4 от IANA до конечного пользователя? Какая регистратура обслуживает Россию?
14. Когда и в какой последовательности закончились свободные адреса IPv4 у IANA и региональных регистратур?
15. Какие практические последствия исчерпания адресов IPv4 видны рядовому пользователю?

Глоссарий темы

Шпаргалка по инструментам

Адреса интерфейсов в Linux:

ip -4 addr show                          # адреса IPv4 всех интерфейсов
ip -br -4 addr                           # кратко: интерфейс, состояние, адреса
ip addr add 10.61.0.2/24 brd + dev eth0  # назначить адрес, вычислить широковещательный
ip addr del 10.61.0.2/24 dev eth0        # удалить адрес
ip -4 addr flush dev eth0                # удалить все адреса IPv4 интерфейса
ip route                                 # таблица маршрутизации (сети на интерфейсах)
ip route get 10.61.1.2                   # как будет доставлен пакет на адрес
ip neigh                                 # таблица соседей (ARP)
ping -b 10.61.0.255                      # эхо-запрос на широковещательный адрес
whois 193.0.6.139                        # кому выделен адрес (пакет whois)

Модуль ipaddress:

import ipaddress as ip
i = ip.ip_interface("172.16.45.201/21")    # адрес узла с префиксом
n = i.network                              # IPv4Network('172.16.40.0/21')
n.netmask, n.hostmask, n.broadcast_address # маска, инверсная маска, широковещательный
n.num_addresses, list(n.hosts())[:3]       # число адресов, первые узлы
ip.ip_network("10.0.0.0/24").subnets(new_prefix=26)       # деление на подсети
ip.ip_network("10.0.0.0/24").supernet(new_prefix=22)      # охватывающий блок
ip.collapse_addresses([...])               # агрегирование списка сетей
a.overlaps(b), a.subnet_of(b)              # пересечение, вложенность
ip.ip_network("10.0.0.0/22").address_exclude(ip.ip_network("10.0.1.0/24"))
ip.ip_address("100.64.1.1").is_private     # категории адресов по реестру IANA
int(ip.ip_address("192.168.10.77"))        # адрес как число: 3232238157

Ручной расчёт:

Что почитать и посмотреть

• RFC 4632 «Classless Inter-domain Routing (CIDR)»: https://www.rfc-editor.org/rfc/rfc4632 — исходный документ бесклассовой адресации; разделы 1–3 объясняют, почему от классов отказались, и содержат примеры агрегирования.
• RFC 1918 «Address Allocation for Private Internets»: https://www.rfc-editor.org/rfc/rfc1918 — короткий документ, где кроме блоков частных адресов обсуждаются преимущества и недостатки их использования.
• Реестр адресов специального назначения IANA: https://www.iana.org/assignments/iana-ipv4-special-registry/ — актуальная таблица специальных блоков с флагами «источник», «назначение», «пересылаемый», «глобально достижимый».
• Документация модуля ipaddress: https://docs.python.org/3/library/ipaddress.html — справочник и введение в модуль, полезный инструмент для любых расчётов с адресами.
• Geoff Huston. IPv4 Address Report: https://ipv4.potaroo.net/ — ежедневно обновляемые данные о распределении и использовании адресного пространства IPv4; там же ежегодные обзоры рынка адресов в блоге APNIC.
• RIPE NCC. IPv4 Exhaustion: https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-run-out/ — история исчерпания адресов в регионе RIPE и действующие правила выдачи.
• Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach, раздел 4.3 «The Internet Protocol (IP)» — изложение адресации IPv4, CIDR и DHCP с хорошими примерами.
• Julia Evans. Networking zines (https://wizardzines.com/) — иллюстрированные брошюры о сетях; хорошо подходят для быстрого повторения смысла масок и подсетей.
• Википедия, статья «Classless Inter-Domain Routing»: https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing — таблицы префиксов и краткая история перехода от классов.

Углубление (по желанию)

Почему в RFC 791 было восемь бит на сеть

Ранние версии адресации ARPANET отводили на номер сети 8 бит, а на номер узла 24: предполагалось, что сетей будет немного — несколько десятков крупных исследовательских сетей, — а узлов в каждой много. Уже к 1981 году, когда вышел RFC 791, стало ясно, что сетей будет больше, и деление на классы стало компромиссом: несколько больших сетей класса A, побольше средних класса B и много малых класса C. Первые биты адреса кодировали класс, чтобы маршрутизатор мог определить границу без дополнительных сведений, — память и вычислительные ресурсы маршрутизаторов того времени были крайне ограничены. Классовая схема прожила около двенадцати лет и сменилась CIDR, когда рост числа сетей и таблиц маршрутизации стал угрожать работе магистрали.

Блок 240.0.0.0/4 и «пропавшие» адреса

Бывший класс E — 268 миллионов адресов — с 1989 года зарезервирован «для будущего использования». С наступлением дефицита адресов не раз предлагалось сделать его обычным одноадресным пространством. Препятствие — не стандарт, а установленная база: многие операционные системы, маршрутизаторы и межсетевые экраны отбрасывают пакеты с такими адресами, и для глобального использования блока пришлось бы обновить огромное число устройств, что по трудоёмкости сравнимо с переходом на IPv6. Linux с версии ядра 2.6.25 позволяет назначать адреса из этого блока интерфейсам, и некоторые крупные компании используют его как дополнительное частное пространство в своих сетях. Аналогичная история с 127.0.0.0/8: шестнадцать миллионов адресов обратной петли используются ради одного 127.0.0.1.

Сколько стоит /24

Рынок адресов IPv4 — необычный пример того, как технический ресурс превратился в товар. Цена блока определяется не только числом адресов, но и его «чистотой»: блок, ранее использовавшийся для рассылки спама, может быть занесён в чёрные списки, и покупателю придётся долго восстанавливать его репутацию. Регистратуры требуют обосновать потребность получателя и фиксируют передачу в своей базе, а межрегиональные передачи допускаются по согласованным правилам. Крупные облачные провайдеры стали одними из главных покупателей, и они же первыми ввели плату за публичные адреса IPv4, стимулируя клиентов переходить на IPv6.

Практическое занятие 6. Расчёт подсетей и адресный план

• Раздел курса: тема 6 «Адресация IPv4 и разбиение на подсети»

Цель занятия

Выработать навык ручного расчёта параметров подсетей IPv4: перевода адресов и масок между двоичной и десятичной записью, нахождения сети, широковещательного адреса и диапазона узлов по адресу и префиксу, деления блока на подсети равного и переменного размера, агрегирования маршрутов и поиска ошибок в адресном плане. Все ответы занятия проверены модулем ipaddress языка Python; после ручного решения рекомендуется проверять себя так же.

Краткая теория

Адрес IPv4 — 32 бита, записываемые четырьмя октетами. Веса битов октета слева направо: 128, 64, 32, 16, 8, 4, 2, 1.

Длина префикса p — число единиц маски, идущих подряд со старшего разряда. Маска с префиксом p в интересном октете имеет значение 256 − 2⁸⁻ʳ, где r — число единиц маски в этом октете (1–8). Допустимые значения октета маски: 0, 128, 192, 224, 240, 248, 252, 254, 255.

Основные соотношения для сети с префиксом p:

• число адресов в сети: 2³²⁻ᵖ;
• число адресов для узлов: 2³²⁻ᵖ − 2 (для p = 31 — 2 адреса по RFC 3021, для p = 32 — 1);
• адрес сети: адрес И маска (все биты номера узла нулевые);
• широковещательный адрес: адрес сети, у которого все биты номера узла единичные;
• первый узел — адрес сети + 1, последний — широковещательный − 1.

Приём «интересного октета». Интересный октет — тот, в котором проходит граница префикса: первый для p от 1 до 8, второй — от 9 до 16, третий — от 17 до 24, четвёртый — от 25 до 32. Размер блока в нём B = 256 − (значение маски в этом октете). Адрес сети: интересный октет округляется вниз до кратного B, октеты правее — нули. Широковещательный адрес: интересный октет = (октет сети) + B − 1, октеты правее — 255.

Подбор префикса под число узлов N: наименьшее h, при котором 2ʰ − 2 ≥ N; префикс 32 − h. В N включаются шлюз и все устройства с адресами.

Деление на равные подсети: блок длины p делится на 2ᵏ подсетей длины p + k.

VLSM: требования сортируются по убыванию размера, подсети выделяются подряд с начала блока; каждая подсеть начинается с адреса, кратного её размеру.

Агрегирование: 2ᵏ соседних блоков длины p объединяются в один блок длины p − k, если первый из них начинается с адреса, кратного 2³²⁻⁽ᵖ⁻ᵏ⁾. Наименьший общий блок для набора сетей находится по числу совпадающих старших битов их адресов.

Проверка модулем ipaddress:

import ipaddress as ip
n = ip.ip_interface("10.37.129.250/19").network      # сеть по адресу узла
print(n, n.netmask, n.broadcast_address, n[1], n[-2], n.num_addresses - 2)
print(list(ip.ip_network("198.51.100.0/24").subnets(new_prefix=27)))   # деление
print(list(ip.collapse_addresses([ip.ip_network("10.1.4.0/24"),
                                  ip.ip_network("10.1.5.0/24")])))      # агрегирование
print(ip.ip_network("10.1.0.0/24").overlaps(ip.ip_network("10.1.0.128/25")))  # пересечение

Разобранные примеры

Пример 1. Сеть по адресу узла

Условие. Интерфейсу назначен адрес 10.37.129.250/19. Найти маску, адрес сети, широковещательный адрес, диапазон адресов узлов и их число.

Решение. Префикс 19 = 8 + 8 + 3: два октета маски по 255 и три единицы в третьем октете — 11100000 = 224. Маска 255.255.224.0. Интересный октет третий, размер блока B = 256 − 224 = 32. Сети идут по третьему октету с шагом 32: 0, 32, 64, 96, 128, 160, … Третий октет адреса 129 попадает в блок, начинающийся с 128. Адрес сети 10.37.128.0/19. Широковещательный: 128 + 32 − 1 = 159 в третьем октете и 255 в четвёртом — 10.37.159.255. Узлы: 10.37.128.1–10.37.159.254, их 2¹³ − 2 = 8190.

Проверка двоичной записью: 129 = 10000001, маска 11100000 оставляет 10000000 = 128. Совпадает.

Пример 2. Адресный план методом VLSM

Условие. Организации выделен блок 192.168.40.0/22. Требуются сегменты: A — 250 узлов, B — 100, C — 60, D — 28, E — 12 и одно звено «точка — точка» между маршрутизаторами. Запас не требуется. Составить план и указать свободные блоки.

Решение. Подбираем префиксы: 250 → 2⁸ − 2 = 254, /24; 100 → 2⁷ − 2 = 126, /25; 60 → 2⁶ − 2 = 62, /26; 28 → 2⁵ − 2 = 30, /27; 12 → 2⁴ − 2 = 14, /28; звено — /30. Требования уже упорядочены по убыванию. Выделяем подряд с начала блока.

Каждая подсеть начинается с адреса, кратного её размеру: например, C начинается с .41.128, а 128 кратно 64. Свободными остаются 192.168.41.244/30, 192.168.41.248/29 и 192.168.42.0/23. Важно, что половина блока — /23 — осталась непрерывной: в неё поместится ещё один сегмент на 510 узлов.

Пример 3. Агрегирование маршрутов

Условие. Маршрутизатор филиала обслуживает сети 172.20.16.0/24, 172.20.17.0/24, …, 172.20.23.0/24 (восемь сетей). Можно ли объявить их одним маршрутом? А сети 10.20.1.0/24 и 10.20.2.0/24?

Решение. Третьи октеты 16–23 в двоичной записи: от 00010000 до 00010111. Общие старшие биты третьего октета — 00010 (пять бит), различаются три младших. Общий префикс 16 + 5 = 21 бит, и восемь сетей /24 образуют ровно блок 172.20.16.0/21: восемь = 2³ сетей, первая начинается с 16, кратного 8. Объявляется один маршрут 172.20.16.0/21.

Для 10.20.1.0/24 и 10.20.2.0/24: третьи октеты 00000001 и 00000010 совпадают лишь в шести старших битах, общий префикс — 22 бита, наименьший общий блок 10.20.0.0/22. Он включает ещё две сети 10.20.0.0/24 и 10.20.3.0/24, не принадлежащие филиалу. Объединить две сети в /23 нельзя, так как первая из них не начинается с адреса, кратного 512 адресам (третий октет 1 нечётен). Точное агрегирование невозможно; либо объявляются две записи, либо маршрут /22 с риском притянуть трафик к чужим сетям.

Пример 4. Ошибки в чужом плане

Условие. Коллега составил план для блока 172.20.0.0/23. Найти ошибки.

Решение. Проверяем каждую строку. Офис: 254 ≥ 200, верно. Склад: 126 ≥ 100, верно. Серверы: 172.20.1.96/26 — не адрес сети, 96 не кратно 64; адрес .96 с префиксом /26 принадлежит сети 172.20.1.64/26, которая пересекается со складом (.0–.127). Камеры: /27 даёт 30 узлов при потребности 40 — сегмент мал. Управление: адрес 172.20.1.175 — широковещательный адрес сети 172.20.1.160/28 (.160 + 16 − 1), назначить его шлюзу нельзя. Звено — верно.

Можно ли исправить план в пределах блока? Суммарная потребность после подбора префиксов: 256 + 128 + 64 + 64 + 16 + 4 = 532 адреса, а блок /23 содержит 512. Блока недостаточно: нужно либо расширить его до /22, либо уменьшить требования (например, вынести звено и управление в другой блок). Этот вывод — самый важный в задаче: подсчёт суммарного объёма с учётом округления до степеней двойки выполняется до распределения.

Задачи для самостоятельного решения

1. Переведите в двоичную запись адреса 172.31.200.9 и 10.255.0.128.
2. Переведите в точечно-десятичную запись: 11000000.10101000.01100100.11111110 и 00001010.00000001.10000000.00000001.
3. Запишите маски для префиксов /19, /27, /12. Найдите длину префикса для масок 255.255.240.0, 255.255.255.248, 255.192.0.0.
4. Является ли число 255.255.253.0 маской подсети? Обоснуйте.
5. Для адреса 192.168.5.130/25 найдите адрес сети, широковещательный адрес, диапазон узлов и их число.
6. То же для 10.44.77.200/20.
7. То же для 172.18.255.1/14.
8. То же для 203.0.113.77/29.
9. Находятся ли узлы 192.168.20.30/27 и 192.168.20.33/27 в одной сети? Смогут ли они обмениваться пакетами без маршрутизатора?
10. Можно ли назначить интерфейсу адрес 192.168.7.255/23? А адрес 192.168.7.0/23?
11. Сколько подсетей /28 содержится в сети /24 и сколько узлов в каждой?
12. Разделите сеть 198.51.100.0/24 на 8 равных подсетей. Перечислите их адреса.
13. Какой наименьший блок нужен сегменту на 500 узлов? На 1000? На 30? На 31?
14. Провайдер выдаёт клиентам блоки /28 из своей сети 203.0.113.0/24. Сколько клиентов он может обслужить? Какой блок получит седьмой клиент, если блоки выдаются по порядку с начала сети?
15. Сколько адресов узлов в сети 10.10.2.250/31? Какие адреса назначаются интерфейсам? Почему такая сеть допустима только на звене «точка — точка»?
16. Определите категорию каждого адреса (частный RFC 1918, общий CGNAT, локальный канала, обратная петля, документационный, групповой, публичный): 100.72.3.4, 172.32.0.1, 169.254.10.10, 192.0.2.55, 127.10.0.1, 239.1.1.1, 172.20.5.5.
17. Объедините в наименьшее число записей сети 10.1.4.0/24, 10.1.5.0/24, 10.1.6.0/24, 10.1.7.0/24.
18. Сети 192.168.16.0/24, 192.168.17.0/24, 192.168.18.0/24, 192.168.19.0/24 и 192.168.20.0/23 нужно описать: а) наименьшим числом точных записей; б) одной записью, возможно с захватом лишних адресов. Сколько лишних адресов захватывает запись в варианте б?
19. Объедините в наименьшее число записей 10.8.0.0/24, 10.8.1.0/24, 10.8.2.0/24.
20. Хост настроен так: адрес 192.168.5.130/25, шлюз по умолчанию 192.168.5.1. Пользователь жалуется, что «Интернет не работает, а соседи пингуются». Объясните причину.
21. Распределите блок 172.16.8.0/22 между сегментами на 300, 120, 60 и 25 узлов и двумя звеньями «точка — точка» (запас не требуется). Укажите свободные блоки.
22. Распределите блок 192.168.100.0/24 между сегментами на 50, 40, 20, 10 и 5 узлов, добавив к каждому запас 20 % с округлением вверх. Укажите свободные блоки.
23. Филиалу выделен блок 10.30.0.0/21. Сегменты: офис — 700 узлов, Wi-Fi — 400, склад — 90, серверы — 40, камеры — 30, управление — 12, три звена «точка — точка». Запас 25 % для сегментов (не для звеньев). Составьте план, укажите свободные блоки и долю занятого адресного пространства.
24. Коллега утверждает: «Подсети 10.0.0.0/25 и 10.0.0.64/26 не пересекаются, так как у них разные маски». Прав ли он? Как проверить пересечение двух подсетей в общем случае?

Ответы

1. 172.31.200.9 = 10101100.00011111.11001000.00001001; 10.255.0.128 = 00001010.11111111.00000000.10000000.
2. 192.168.100.254; 10.1.128.1.
3. /19 — 255.255.224.0; /27 — 255.255.255.224; /12 — 255.240.0.0. 255.255.240.0 — /20; 255.255.255.248 — /29; 255.192.0.0 — /10.
4. Нет. 253 = 11111101: после нуля снова идёт единица, единицы маски не непрерывны. Модуль ipaddress такую маску отвергает.
5. Сеть 192.168.5.128/25, широковещательный 192.168.5.255, узлы 192.168.5.129–192.168.5.254, 126 узлов.
6. Маска 255.255.240.0, B = 16; 77 → 64. Сеть 10.44.64.0/20, широковещательный 10.44.79.255, узлы 10.44.64.1–10.44.79.254, 4094 узла.
7. Маска 255.252.0.0, интересный октет второй, B = 4; 18 → 16. Сеть 172.16.0.0/14, широковещательный 172.19.255.255, узлы 172.16.0.1–172.19.255.254, 262 142 узла.
8. B = 8; 77 → 72. Сеть 203.0.113.72/29, широковещательный 203.0.113.79, узлы 203.0.113.73–203.0.113.78, 6 узлов.
9. Нет: первый узел в сети 192.168.20.0/27 (.0–.31), второй — в 192.168.20.32/27 (.32–.63). Каждый считает другого находящимся в чужой сети и отправит пакет шлюзу; без маршрутизатора связи не будет.
10. 192.168.7.255/23 — нельзя: это широковещательный адрес сети 192.168.6.0/23 (192.168.6.0–192.168.7.255). 192.168.7.0/23 — можно: это обычный адрес узла той же сети, хотя он и оканчивается на 0.
11. 2⁴ = 16 подсетей по 14 узлов.
12. 198.51.100.0/27, .32/27, .64/27, .96/27, .128/27, .160/27, .192/27, .224/27.
13. 500 узлов — /23 (510); 1000 — /22 (1022); 30 — /27 (30); 31 — /26 (62), так как /27 вмещает только 30.
14. 16 клиентов; седьмой получит 203.0.113.96/28 (блоки 0, 16, 32, 48, 64, 80, 96).
15. Два адреса: 10.10.2.250 и 10.10.2.251, оба назначаются интерфейсам; адреса сети и широковещательного нет (RFC 3021). На звене «точка — точка» широковещание не нужно: у каждого конца ровно один сосед.
16. 100.72.3.4 — общий CGNAT (100.64.0.0/10); 172.32.0.1 — публичный (блок RFC 1918 кончается на 172.31.255.255); 169.254.10.10 — локальный канала; 192.0.2.55 — документационный (TEST-NET-1); 127.10.0.1 — обратная петля (весь 127.0.0.0/8); 239.1.1.1 — групповой, из блока для использования внутри организации; 172.20.5.5 — частный RFC 1918.
17. Одна запись 10.1.4.0/22 (третий октет 4 кратен 4).
18. а) Две записи: 192.168.16.0/22 и 192.168.20.0/23. б) 192.168.16.0/21; она захватывает лишние 192.168.22.0/23 — 512 адресов.
19. Две записи: 10.8.0.0/23 и 10.8.2.0/24. Три сети не образуют блок степени двойки.
20. Шлюз 192.168.5.1 не принадлежит сети хоста 192.168.5.128/25 (.128–.255). Хост не может отправить кадр шлюзу, находящемуся вне его сегмента: Linux откажется добавить такой маршрут по умолчанию (Nexthop has invalid gateway), другие системы — не получат ответ на ARP. Соседи в .129–.254 достижимы непосредственно. Либо маска должна быть /24, либо шлюзу нужен адрес из .129–.254.
21. 172.16.8.0/23 (300), 172.16.10.0/25 (120), 172.16.10.128/26 (60), 172.16.10.192/27 (25), 172.16.10.224/30 и 172.16.10.228/30 (звенья). Свободны 172.16.10.232/29, 172.16.10.240/28, 172.16.11.0/24.
22. С запасом: 60, 48, 24, 12, 6. Подсети: 192.168.100.0/26 (50), 192.168.100.64/26 (40), 192.168.100.128/27 (20), 192.168.100.160/28 (10), 192.168.100.176/29 (5). Свободны 192.168.100.184/29 и 192.168.100.192/26.
23. С запасом: 875, 500, 113, 50, 38, 15. Подсети: офис 10.30.0.0/22, Wi-Fi 10.30.4.0/23, склад 10.30.6.0/25, серверы 10.30.6.128/26, камеры 10.30.6.192/26, управление 10.30.7.0/27, звенья 10.30.7.32/30, 10.30.7.36/30, 10.30.7.40/30. Свободны 10.30.7.44/30, 10.30.7.48/28, 10.30.7.64/26, 10.30.7.128/25. Занято 1024 + 512 + 128 + 64 + 64 + 32 + 12 = 1836 адресов из 2048, около 90 %.
24. Не прав: 10.0.0.64/26 (.64–.127) целиком лежит внутри 10.0.0.0/25 (.0–.127). Две подсети либо не пересекаются, либо одна вложена в другую (частичного пересечения у выровненных блоков не бывает). Проверка: сеть с более коротким префиксом A и сеть B пересекаются, если адрес сети B И маска A равен адресу сети A; в Python — a.overlaps(b).

Лабораторная работа 6. Адресный план в учебной сети

• Раздел курса: тема 6 «Адресация IPv4 и разбиение на подсети»

Введение

В практическом занятии 6 подсети рассчитывались на бумаге. В настоящей работе расчёт становится проектом: задаётся блок адресов и требования отделов компании «Северный узел», нужно составить адресный план, реализовать его на учебной сети из сетевых пространств имён и проверить, что сеть ведёт себя так, как предсказывает план. Работа связывает тему 6 с предыдущими: сегменты сети построены из мостов Linux, знакомых по лабораторным работам 4 и 5, а связность проверяется уже не на канальном, а на сетевом уровне — по тому, как хост решает, можно ли доставить пакет непосредственно.

Вторая линия работы — программирование. Нужно написать на Python калькулятор подсетей, реализуя вычисления поразрядными операциями над 32-битными числами, и проверить его автоматическими тестами, сравнивающими результаты с модулем ipaddress стандартной библиотеки. Тот же калькулятор используется для проверки собственного ручного плана. Завершает базовую часть поиск ошибок в «испорченной» конфигурации коллеги.

Работа состоит из базовой части (части 1–5) и продвинутой части (часть 6) — программной проверки адресного плана и агрегирования, выполняемой по желанию.

Цель работы

Освоить проектирование адресного плана IPv4 методом VLSM, его реализацию на интерфейсах Linux и программную проверку расчётов.

После выполнения работы можно будет:

• составить адресный план по требованиям к сегментам с запасом на рост и обосновать выбор каждого префикса;
• назначить адреса интерфейсам командой ip addr и прочитать вывод ip addr и ip route;
• предсказать и объяснить по выводу ping, ip route и ip neigh, какие узлы связаны без маршрутизатора и почему;
• реализовать вычисление сети, широковещательного адреса и диапазона узлов поразрядными операциями и проверить реализацию автоматическими тестами;
• найти в конфигурации ошибки адресации — неверную маску, адрес вне подсети, пересекающиеся подсети — по симптомам и захвату трафика;
• программно проверить адресный план на пересечения и выравнивание и найти агрегирующий префикс (продвинутая часть).

Теоретический минимум

Материал изложен в теме 6: разделы «Иерархическая адресация и структура адреса IPv4» (маска, префикс, решение хоста о непосредственной доставке), «Специальные адреса» и «Расчёт подсетей» (обратная задача, VLSM, проверка модулем ipaddress). Формулы расчёта собраны в разделе «Краткая теория» практического занятия 6.

Учебная топология. Пространство имён sw содержит три независимых моста — три сегмента сети, как три отдельных коммутатора или три VLAN. Маршрутизатора в топологии нет: связь между сегментами появится в теме 8.

   сегмент A (разработка)     сегмент B (продажи)      сегмент C (серверная)
      a1          a2             b1          b2           c1          c2
       \          /               \          /             \          /
        +-- brA --+                +-- brB --+              +-- brC --+
        |_______________________ пространство sw ______________________|

Команды работы.

Полезные фильтры захвата: arp — запросы и ответы ARP (подробно ARP изучается в теме 7; здесь достаточно знать, что хост спрашивает «у кого адрес X?» широковещательным кадром, прежде чем отправить пакет соседу), icmp — эхо-запросы и ответы ping.

Перечень оснащения

• Ubuntu 24.04 (физическая или виртуальная машина либо WSL2) с пакетами из лабораторной работы 1: iproute2, iputils-ping, tcpdump, python3 (версия 3.10 или новее).
• Архив окружения lr-env: скрипты up.sh, down.sh, apply-plan.sh, break.sh, пример плана plan.example.txt, заготовка калькулятора subnetcalc.py, тесты test_subnetcalc.py, README.md.
• Права администратора (sudo) для скриптов топологии; калькулятор и тесты запускаются без них.
• Текстовый редактор для программы на Python.

Порядок выполнения работы

Распакуйте архив и поднимите топологию:

unzip lr-env.zip -d ~/lab06 && cd ~/lab06/lr-env && chmod +x *.sh *.py
sudo ./up.sh
ns() { sudo ip netns exec "$@"; }

После up.sh у хостов нет адресов IPv4. Разобрать топологию — sudo ./down.sh; поднять заново можно в любой момент, план затем применяется повторно apply-plan.sh.

Вариант задания определяется числом V (от 1 до 30), которое вы выбираете сами: компании выделен блок 10.N.0.0/22, где N = 60 + V. Например, для варианта 1 блок — 10.61.0.0/22, для варианта 12 — 10.72.0.0/22. Ниже в примерах используется вариант 1.

Расчёты частей 1 и 4 выполняйте сначала вручную, затем проверяйте программой: в журнале работы должны быть видны оба результата и их сравнение.

Часть 1. Проектирование адресного плана

Задание

1. Требования отделов офиса «Северного узла» заданы числом устройств, включая шлюз сегмента:

   Сегмент	Устройств	Реализуется в топологии
   Разработка	150	сегмент A
   Гостевая Wi-Fi	90	—
   Продажи	70	сегмент B
   Бухгалтерия	35	—
   Серверная	20	сегмент C
   Управление сетевым оборудованием	8	—
   Звено офис — филиал	2	—
   Звено офис — межсетевой экран	2	—

   К каждому сегменту, кроме звеньев, добавьте запас на рост 25 % с округлением вверх.

2. Для каждого сегмента подберите префикс, показав неравенство 2ʰ − 2 ≥ N. Подсчитайте суммарный объём выделяемых адресов и убедитесь, что он не превышает 1024.

3. Распределите блок методом VLSM: отсортируйте сегменты по убыванию, выделяйте подряд с начала блока, начиная каждую подсеть с адреса, кратного её размеру. Для каждой подсети укажите адрес сети, маску в точечно-десятичной записи, диапазон узлов, широковещательный адрес, адрес шлюза (первый адрес диапазона).

4. Укажите оставшиеся свободные блоки. Какой наибольший сегмент можно будет добавить без перенумерации?

5. Один из коллег предлагает «для простоты» выдать каждому сегменту по /24. Поместится ли такой план в блок /22? Сколько адресов он потратит впустую?

Что должно получиться

Таблица адресного плана со всеми полями, расчёт префиксов с неравенствами, перечень свободных блоков, ответы на вопросы пп. 4–5. Для варианта 1 первая строка плана должна выглядеть так: «Разработка — 150 — с запасом 188 — /24 — 10.61.0.0/24».

Часть 2. Реализация плана на хостах

Задание

1. Создайте файл plan.txt по образцу plan.example.txt: хостам a1, a2 — адреса из подсети разработки, b1, b2 — из подсети продаж, c1, c2 — из подсети серверной. Первый адрес каждой подсети оставьте для будущего шлюза, хостам назначьте второй и третий.
2. Примените план: sudo ./apply-plan.sh plan.txt. Выведите ip -n a1 -4 addr show dev eth0 и ip -n a1 route. Объясните каждое поле строки inet и строку таблицы маршрутизации: откуда ядро взяло сеть, указанную в маршруте?
3. Проверьте связность внутри каждого сегмента: ns a1 ping -c 2 <адрес a2> и аналогично для b1–b2, c1–c2.
4. Запустите захват ns a2 tcpdump -i eth0 -e -nn arp or icmp, очистите кеш соседей a1 (sudo ip -n a1 neigh flush all) и повторите ping от a1 к a2. Какой кадр a1 отправляет первым и на какой MAC-адрес? Каким становится состояние записи в ip -n a1 neigh после обмена?

Что должно получиться

Файл plan.txt, выводы ip addr и ip route с пояснениями, результаты ping внутри сегментов, фрагмент захвата с ARP-запросом и ответом и вывод ip neigh.

Часть 3. Связность между сегментами без маршрутизатора

Задание

1. Предскажите результат ns a1 ping -c 2 <адрес b1> — и не только «будет ли ответ», но и какое именно сообщение выведет ping. Проверьте. Выполните ip -n a1 route get <адрес b1> и объясните результат через таблицу маршрутизации a1.

2. Эксперимент «та же подсеть в чужом сегменте». Назначьте хосту b1 адрес из подсети разработки, например 10.61.0.9/24 для варианта 1:

   sudo ip -n b1 -4 addr flush dev eth0
   sudo ip -n b1 addr add 10.61.0.9/24 brd + dev eth0
   

   Предскажите, ответит ли b1 на ping от a1. Проверьте, затем выведите ip -n a1 neigh show 10.61.0.9. Запустите захват ARP на b1 во время ping. Приходит ли к b1 ARP-запрос от a1? Почему сообщение ping отличается от сообщения в п. 1? Что доказывает этот эксперимент о соотношении IP-подсети и широковещательного домена?

3. Эксперимент «адрес, который нельзя назначать». Назначьте хосту a2 широковещательный адрес подсети разработки (10.61.0.255/24 для варианта 1). Принимает ли ядро Linux такую команду? Выполните ns a1 ping -c 1 <этот адрес> и объясните сообщение ping. Почему в адресном плане такой адрес хосту назначать нельзя, даже если система не запрещает?

4. Попробуйте назначить адреса 10.61.0.300/24 и 10.61.0.5/33. Какие ошибки выдаёт ip и какие ошибки, наоборот, не обнаруживает?

5. Восстановите план командой sudo ./apply-plan.sh plan.txt.

Что должно получиться

Предсказания и фактические результаты трёх экспериментов, выводы ip route get и ip neigh, фрагмент захвата, объяснение разницы между «Network is unreachable» и потерей пакетов без сообщения. Ответ на вопрос: чего не хватает в топологии, чтобы a1 мог связаться с b1, и какие две настройки потребуются (тема 8).

Часть 4. Калькулятор подсетей на Python

Задание

1. Откройте заготовку subnetcalc.py. Функции ip_to_int и int_to_ip уже реализованы; разберите, как они переводят адрес в 32-битное число и обратно. Вычислите вручную ip_to_int("10.61.1.130") и проверьте вызовом из интерпретатора.

2. Реализуйте функции prefix_to_mask и mask_to_prefix, используя только поразрядные операции и арифметику (модуль ipaddress в subnetcalc.py не импортировать). Функция mask_to_prefix должна отвергать маски с разрывом в единицах. Подсказка: маску можно проверить, восстановив её из числа единиц и сравнив с исходной.

3. Реализуйте network_info: адрес сети — адрес & маска, широковещательный — сеть | (~маска & 0xFFFFFFFF). Обратите внимание на особые случаи /31 и /32, описанные в строке документации функции. Почему без & 0xFFFFFFFF результат в Python будет неверным?

4. Реализуйте prefix_for_hosts и vlsm по описанию в строках документации.

5. Запустите тесты: python3 test_subnetcalc.py -v. Тесты сравнивают ваши функции с модулем ipaddress на примерах из темы 6 и на 500 случайных адресах. Добейтесь прохождения всех тестов; если какой-то тест не проходил, опишите в журнале работы, какую ошибку он выявил.

6. Проверьте программой свой план из части 1:

   python3 subnetcalc.py vlsm 10.61.0.0/22 Разработка=188 Гостевая=113 Продажи=88 \
       Бухгалтерия=44 Серверная=25 Управление=10 Звено1=2 Звено2=2
   

   Совпадает ли результат с ручным расчётом? Если нет — найдите, где ошибка: в ручном расчёте или в программе.

Что должно получиться

Исходный текст реализованных функций, вывод тестов, сравнение программного и ручного плана, ответы на вопросы пп. 1 и 3.

Часть 5. Найти ошибку в конфигурации коллеги

Задание

1. Выполните sudo ./break.sh. Скрипт назначает хостам адреса по плану коллеги для блока 10.6.0.0/22: сегмент A — 10.6.0.0/24, сегмент B — 10.6.1.0/25, сегмент C — 10.6.2.0/26. Не читайте скрипт до завершения части.
2. Составьте таблицу связности: для каждой пары хостов одного сегмента проверьте ping в обоих направлениях и запишите сообщение ping. Сколько пар работают так, как задумано?
3. Для каждой неработающей пары найдите причину, используя только наблюдения: ip -4 addr, ip route, ip route get, ip neigh и захват arp or icmp на обоих хостах. Сопоставьте каждый адрес с подсетью, которую по плану должен занимать его сегмент.
4. Обратите внимание на пару a1–a2: в одном направлении ping сообщает «Network is unreachable», в другом пакеты просто теряются. По захвату на a2 установите, доходит ли до a2 эхо-запрос от a1 и почему a2 не отвечает.
5. Для каждой ошибки сформулируйте диагноз в терминах темы 6 (неверная маска, адрес вне подсети сегмента, подсеть, пересекающаяся с подсетью другого сегмента) и предложите исправление. Исправьте конфигурацию командами ip addr и проверьте, что все пары внутри сегментов связаны.

Что должно получиться

Таблица связности с сообщениями ping, для каждой ошибки — наблюдения, на которых основан диагноз, и команда исправления, итоговая таблица связности после исправления.

Часть 6. Продвинутая: проверка плана и агрегирование

Задание

1. Добавьте в subnetcalc.py функцию check_plan(plan), принимающую список пар «имя сегмента, строка адреса с префиксом» в том виде, в каком они заданы в файле плана или в таблице, и возвращающую список найденных проблем:

   • строка задаёт адрес узла, а не адрес сети, и это не предполагалось (для таблицы подсетей);
   • подсети двух сегментов пересекаются;
   • адрес хоста совпадает с адресом сети или широковещательным адресом своей подсети;
   • два хоста имеют одинаковый адрес.

   Реализуйте проверки поразрядными операциями, а результат сверьте с методами overlaps и subnet_of модуля ipaddress. Проверьте функцию на конфигурации из части 5 и на таблице из примера 4 практического занятия 6.

2. Реализуйте функцию summarize(nets), возвращающую наименьший список префиксов, точно покрывающий заданные сети (аналог ipaddress.collapse_addresses), и функцию supernet(nets), возвращающую один наименьший префикс, покрывающий их все. Проверьте на задачах 17–19 практического занятия 6.

3. Примените supernet к своему плану из части 1. Какой префикс должен объявлять маршрутизатор офиса филиалу? Совпадает ли он с выделенным блоком /22? Сколько записей потребовалось бы без агрегирования?

4. Сравните производительность: сколько времени занимает расчёт network_info для миллиона случайных адресов вашей реализацией и модулем ipaddress (модуль time или timeit)? Объясните разницу.

Что должно получиться

Исходный текст функций check_plan, summarize, supernet, результаты проверки конфигураций, агрегирующий префикс собственного плана, результаты измерения производительности с объяснением.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод и объяснение расхождений. Таблицы, графики и файлы захватов, перечисленные в разделах «Что должно получиться», удобно хранить там же. В конце полезно сформулировать несколько предложений собственных выводов по работе.

Контрольные вопросы

1. Почему хост, получив пакет для отправки, сравнивает с адресом назначения именно префикс своего интерфейса, а не весь адрес? Что произойдёт, если маска на хосте длиннее, чем следует? Короче?
2. Почему при выделении подсетей методом VLSM их выделяют по убыванию размера? Приведите пример, где выделение в произвольном порядке приводит к потере адресов.
3. Почему подсеть 10.61.0.160/26 не существует, а адрес 10.61.0.160/26 назначить интерфейсу можно?
4. В части 3 хосты a1 и b1 с адресами из одной подсети не связались. Какие два условия должны выполняться, чтобы два узла могли обмениваться пакетами без маршрутизатора?
5. Почему ping в одних случаях сразу сообщает «Network is unreachable», а в других отправляет пакет и не получает ответа? Какое из этих двух поведений указывает на ошибку на самом хосте?
6. Сегмент рассчитан на 120 устройств и получил /25. Через год в нём 140 устройств. Какие варианты действий у администратора и почему свободный блок сразу за подсетью облегчает задачу?
7. Почему для звеньев между маршрутизаторами используют /30 или /31, а не /24? Какое ограничение снял RFC 3021?
8. Почему адресный план, в котором подсети одного филиала разбросаны по всему адресному пространству организации, плох, даже если подсети не пересекаются?
9. Зачем при вычислении широковещательного адреса в Python понадобилась операция & 0xFFFFFFFF? Как эту проблему решают языки с беззнаковыми 32-битными целыми?
10. Почему адреса из блока 100.64.0.0/10 нельзя использовать для внутреннего адресного плана «Северного узла», хотя они тоже не маршрутизируются в Интернете?