Практика выделения IP-подсетей

Настройка протокола IP

Протокол IP является базовым в корпоративных сетях. На нем, как на фундамен­те, выстраивают свою работу практически все остальные сопутствующие техноло­гии. Незнание этого протокола делает бессмысленными все дальнейшие попытки получения знаний в данной области. По этой причине автор счел необходимым включить в книгу материал по протоколу IP, сделав акцент на практических мето­дах его использования. Кроме того, логика изложения материала книги требует рассмотрения протокола IP именно в этой главе. Для четкого уяснения положе­ния маршрутизаторов в распределенной сети, понимания технологии трансляции адресов, принципов работы протоколов маршрутизации и многих других техноло­гий необходимо твердое знание механизма назначения адресного пространства в протоколе IP.

Протокол IP

Очень кратко рассмотрим основы протокола. Его описание дано в документе RFC 791. IP (Internet Protocol) является базовым протоколом всего стека TCP/ IP — он отвечает за передачу информации по сети. Информация передается бло­ками, которые называются дейтаграммами. IP является протоколом сетевого уров­ня, при этом для каждой среды передачи данных, например Ethernet и ATM, опре­делен свой способ инкапсуляции IP-дейтаграмм. Маршрутизаторы пересылают инкапсулированные дейтаграммы по различным сетям, образуя объединение IP-сетей, по которому каждая рабочая станция может поддерживать связь по прото­колу IP с любой другой рабочей станцией.

Услуги, предлагаемые протоколом IP, сводятся к негарантированной доставке дейтаграмм. Протокол IP не исключает потерь и дублирования дейтаграмм, до­ставки дейтаграмм с ошибками, а также нарушения порядка следования дейта­грамм, заданного при их отправлении.

Протокол IP выполняет фрагментацию и сборку дейтаграмм, если принятый размер кадров в рабочей сети (или участке распределенной сети) отличается от размера исходных дейтаграмм. В протоколе IP отсутствуют механизмы повыше­ния достоверности передачи данных, управления протоколом и синхронизации, которые обычно предоставляются в протоколах более высокого уровня. Протокол IP получает информацию для передачи от протоколов, расположенных по сравне­нию с ним на более высоком уровне. К этим протоколам, прежде всего, относятся протоколы TCP и UDP. После получения информации протокол IP передает дей­таграммы через распределенную сеть, используя сервисы локальных сетей. Дей­таграмма состоит из заголовка и поля данных, которое следует сразу за заголов­ком. Длина поля данных определяется полем «Общая длина» в заголовке. На рис. 2.1 показан формат заголовка IP-дейтаграммы.

Номер версии 4 бита	Длина заголовка 4 бита	Тип сервиса 8 бита	Общая длина 16 бита
Идентификатор (16 бит)	Флаги (3 бита)	Смещение фрагмента (13 бит)
Время жизни (8 бит)	Протокол (8 бит)	Контрольная сумма заголовка (16 бит)
Адрес отправителя (32 бита)
Адрес получателя (32 бита)
Опции (поле переменной длины)	Выравнивание до 32-разрядной граници

Рис. 2.1. Формат заголовка дейтаграммы протокола IP

· Поле «Номер версии» (Version) указывает на версию используемого прото­кола IP. В настоящее время распространена версия 4, но планируется переход к версии 6.

· Поле «Длина заголовка» (Header Lenght) определяет длину заголовка в 32-разрядных словах. Минимальный размер заголовка — 5 слов (20 байт). Следу­ет отметить, что при увеличении объема служебной информации эта длина мо­жет быть увеличена за счет поля «Опции».

· Поле «Тип сервиса»- (Type of Service) определяет способ обслуживания дей­таграммы. Протокол IP обрабатывает каждую дейтаграмму независимо от ее принадлежности к тому или иному пакету. При этом используются четыре ос­новных механизма: установка типа сервиса, установка времени жизни, установка опций и вычисление контрольной суммы заголовка. Типом сервиса характери­зуется набор услуг, которые требуются от маршрутизаторов в распределенной сети. Эти параметры должны использоваться для управления выбором реаль­ных рабочих характеристик при передаче дейтаграмм. В некоторых случаях передача дейтаграммы осуществляется с установкой приоритета, который дает данной дейтаграмме некоторые преимущества при обработке по сравнению с остальными.

· Поле «Время жизни»- (Time to live). При определенных условиях IP-дейта­граммы могут попасть в замкнутый логический контур (петлю), образованный некоторой группой маршрутизаторов. Иногда такие логические контуры суще­ствуют в течение короткого промежутка времени, но иногда они оказываются достаточно долговечными. Чтобы избавить сеть от дейтаграмм, циркулирую­щих в логических контурах слишком долго, протоколом IP устанавливается предельный срок пребывания дейтаграммы в сети. Он задается в поле «Время жизни» (TTL — Time To Live). Его содержимое уменьшается на единицу при прохождении дейтаграммы через маршрутизатор; при обнулении поля TTL дей­таграмма отбрасывается. Первоначально спецификации IP включали еще одно требование: поле TTL должно уменьшаться, по крайней мере, один раз в секунду. Поскольку поле TTL является 8-разрядным, это означает, что теоретически дейтаграмма может на­ходиться в сети не более 4,25 минуты. На практике требование ежесекундного уменьшения поля TTL игнорируется, тем не менее в спецификациях многих протоколов следующих уровней (TCP) по-прежнему предполагается, что мак­симальное время жизни дейтаграммы в сети составляет лишь несколько минут.

· Поле «Идентификатор»- (Identification) используется для распознавания дей­таграмм, образованных в результате фрагментации. Все части фрагментирован-ной дейтаграммы должны иметь одинаковое значение этого поля.

· Поле «Общая длина» (Total Length) указывает общую длину дейтаграммы (заголовок и поле данных). Максимальный размер дейтаграммы может со­ставлять 65 535 байт. В подавляющем большинстве сетей такой размер дейта­грамм не используется. По стандарту все устройства в сети должны быть гото­вы принимать дейтаграммы длиной 576 байт. Эти ограничения необходимы для передачи дейтаграмм в физических кадрах. Передача дейтаграммы в кадре на­зывается инкапсуляцией. С точки зрения низших уровней дейтаграмма выгля­дит так же, как и любое другое сообщение в сети. Сетевое оборудование не ра­ботает с дейтаграммами, поэтому дейтаграмма является частью области данных кадра. Функции фрагментации и сборки также возложены на протокол IP. Фрагмен­тация — это разделение большой дейтаграммы на несколько небольших частей. В большинстве локальных и глобальных сетей есть ограничения на максималь­ный размер единицы передаваемой информации. Эту величину называют мак­симальной единицей передачи (MTU — Maximum Transmission Unit). Напри­мер, в сетях Ethernet данная величина составляет 1500 байт, а в сетях FDDI — 4096 байт. Когда маршрутизатор переправляет дейтаграмму из одной сети в другую, мо­жет оказаться, что размер дейтаграммы окажется недопустимым в новой сети. Спецификация IP предусматривает следующее решение этой проблемы: мар­шрутизатор может разбить дейтаграмму на мелкие фрагменты, приемлемые для выходной среды, а в пункте назначения эти фрагменты будут объединены в дей­таграмму исходного вида. Формируемые маршрутизатором фрагменты иден­тифицируются смещением относительно начала исходной дейтаграммы. Дей­таграмма идентифицируется по отправителю, пункту назначения, типу прото­кола высокого уровня и 16-разрядному полю «Идентификатор». Все это в со­вокупности должно образовывать уникальную комбинацию. Следует подчеркнуть связь между полями «Время жизни» и «Идентификатор». Действительно, во избежание смешивания фрагментов двух разных дейтаграмм отправитель IP-данных обязан исключить ситуацию, когда в один пункт назначе­ния по одному и тому же протоколу в течение жизненного цикла дейтаграммы будут отправлены две дейтаграммы с совпадающими идентификаторами. В связи с тем, что идентификатор 16-разрядный, а наибольшее время жизни дейтаграммы исчисляется минутами (будем считать, что оно порядка 2 минут), получаем ско­рость передачи — 546 дейтаграмм в секунду. При максимальном размере дейта­граммы, равном 64 Кбайт, имеем результирующую скорость около 300 Мбит/с. Проблема эффективного использования битов идентификатора оказалась прак­тически решенной с появлением метода MTU Discovery, позволяющего опре­делить значения MTU на всем пути к пункту назначения. Фрагментация и сборка производятся автоматически и не требуют от отпра­вителя специальных действий. Каждая фрагментированная часть имеет тот же формат, что и исходная дейтаграмма. Использование фрагментации повышает вероятность потери исходной дейтаграммы, так как потеря даже одного фраг­мента приводит к потере всей дейтаграммы. Сборка дейтаграммы осуществля­ется на месте назначения. Такой метод позволяет маршрутизировать фрагмен­ты независимо.

· Поле «Флаги» (Flags) используется при фрагментации. Нулевое значение пер­вого бита разрешает фрагментацию, а единичное — запрещает. Единичный вто­рой бит указывает на последний фрагмент дейтаграммы.

· Поле «Смещение фрагмента» используется для указания смещения данных во фрагменте относительно начала исходной дейтаграммы. Чтобы получить сме­щение в байтах, надо умножить значение этого поля на 8. Первый фрагмент всегда имеет нулевое смещение. Поле используется при сборке фрагментов дей­таграммы после передачи по сетям с различными MTU.

ПРИМЕЧАНИЕ ------------------------------------------------------------------------

Здесь стоит упомянуть об атаке TearDrop Fragmentation. Эта атака относится к типу DoS (см. главу 4) и направлена на выведение компьютера из строя (общий сбой системы или потерю взаимодействия с другими компьютерами) за счет нестандартной фрагментации дейтаграмм протокола IP. Суще­ствует несколько вариантов этой атаки, таких как NewTear, Nestea, SynDrop и Bonk. Так, существует вариант, при котором атакующий посылает специально сформированную пару фрагментов дейта­грамм IP, которые при сборке на атакуемой системе формируют некорректный пакет протокола UDP. Причем второй фрагмент при сборке перезаписывает данные в середине заголовка UDP, со­держащегося в первом фрагменте таким образом, что результирующая дейтаграмма получается как бы незавершенной, что может, например, вызвать останов операционной системы Windows NT с ошибкой STOP 0x0000000A или 0x00000019. Согласно данным компании ISS (Internet Security Sys­tems), уязвимыми для этой атаки являются такие системы, как Windows NT, Windows 95, Linux. Ком­пания Microsoft выпустила исправление, информацию о котором можно найти по следующему адре­су (статья Q179129 «STOP 0x0000000A or 0x00000019 Due to Modified Teardrop Attack»): http://sup-port.microsoft.com/suppo rt/kb/articles/ql79/l/29.asp.

· Поле «Протокол» (Protocol) показывает, какому протоколу верхнего уровня принадлежит дейтаграмма. При поступлении дейтаграммы это поле указывает, какому приложению следует ее передать. Таблица 2.1 содержит перечень (не­полный) ПРОТОКОЛОВ,

 

· Поле «Контрольная сумма» рассчитывается по всему заголовку. Так как неко­торые поля заголовка меняют свое значение, например «Время жизни», при про­хождении дейтаграммы через маршрутизаторы контрольная сумма проверяется и повторно рассчитывается при каждой модификации заголовка. Определение контрольной суммы заголовка обеспечивает безошибочность передачи дейта­граммы через сеть. Перед отправкой дейтаграммы вычисляется контрольная сумма, которая вносится в ее заголовок. При получении дейтаграммы вычис­ляется ее контрольная сумма, которая сравнивается со значением контрольной суммы в ее заголовке. Если в контрольной сумме обнаруживается ошибка, дей­таграмма отбрасывается. Контрольная сумма заголовка дейтаграммы применя­ется и во многих других протоколах, таких как UDP, TCP, ICMP и OSPF.

· Поля «Адрес отправителя» и «Адрес получателя» (Source Address, Destina­tion Address) имеют одинаковую длину и структуру. Поля содержат 32-раз­рядные IP-адреса отправителя и получателя дейтаграммы.

· Поле «Опции» (Options) не обязательно и обычно используется при настрой­ке сети. В этом поле может быть указан точный маршрут прохождения дейта­граммы в распределенной сети, данные о безопасности, различные временные отметки и т. д. Поле не имеет фиксированной длины, поэтому для выравнива­ния заголовка дейтаграммы по 32-разрядной границе предусмотрено следую­щее поле — поле «Выравнивание» (Padding). Выравнивание осуществляется нулями.

Классы адресов и их маски

Межсетевая схема адресации протокола IP описана в документах RFC 990 и RFC 997. При разработке протоколов стека TCP/IP рассматривался целый ряд методов идентификации конечных устройств в сети. Окончательным стало реше­ние о присвоении адреса как сети, так и устройствам в этой сети. Основными дово­дами в пользу такого подхода явились: широкий диапазон назначений номеров сетей и устройств в них и возможность реализации маршрутизации. При этом ад­реса должны назначаться упорядоченно, для того чтобы сделать маршрутизацию более эффективной.

В сети, построенной на базе протокола TCP/IP, конечные устройства получа­ют уникальные адреса. Эти устройства могут быть персональными компьютера­ми, коммуникационными серверами, маршрутизаторами и т. д. При этом некото­рые устройства, которые имеют несколько физических интерфейсов, например маршрутизаторы, должны иметь уникальный адрес для каждого из своих интер­фейсов. Исходя из схемы адресации и возможности того, что некоторые устрой­ства в сети будут иметь несколько адресов, можно сделать вывод, что такая схема адресации описывает не само устройство в сети, а определенное соединение этого устройства с сетью. Это приводит к ряду неудобств. Одним из них является необ­ходимость замены адреса устройства при перемещении его в другую сеть. Основ­ной же недостаток в том, что для работы с устройствами, имеющими несколько подключений в распределенной сети, необходимо знать все его адреса, идентифи­цирующие эти подключения. Незнание хотя бы одного адреса может привести к тому, что эти устройства не получат необходимую информацию при отказе других соединений.

При стандартизации протокола IP в сентябре 1981 года его спецификация тре­бовала, чтобы каждое устройство, подключенное к сети, имело уникальный 32-раз­рядный адрес. Этот адрес разбивается на две части. Первая часть адреса иденти­фицирует сеть, в которой располагается устройство. Вторая часть однозначно иден­тифицирует само устройство. Такая схема создает двухуровневую адресную иерар­хию (см. рис. 2.2).

1 2 3......30 31

КлючНомер сетиНомер хоста

Рис. 2.2. Формат адреса

В последнее время поле номера сети в адресе называется сетевым префиксом. Это связано с тем, что первая порция каждого IP-адреса идентифицирует номер сети. Все хосты в определенной сети имеют один и тот же сетевой префикс, но при этом номера хостов должны быть уникальны. Аналогично, любые два хоста, рас­положенные в разных сетях, должны иметь различные сетевые префиксы, но при этом они могут иметь одинаковые номера хостов.

Для обеспечения гибкости в присвоении адресов компьютерным сетям разра­ботчики определили, что адресное пространство протокола IP должно быть разде­лено на три различных класса — А, В и С. Каждый из этих основных классов фик­сирует границу между сетевым префиксом и номером хоста в различных точках 32-разрядного адреса. На рис. 2.3 показаны форматы основных классов.

Одно из основных достоинств использования классов заключается в том, что каждый адрес содержит ключ, который идентифицирует точку, расположенную между сетевым префиксом и номером хоста. Например, если старшие два бита ад­реса установлены в 10, то точка раздела находится между 15 и 16-м битами.

Недостатком этого метода является необходимость изменения сетевого адреса, когда в сетях класса С число устройств становится больше 255. В этом случае воз­никает необходимость замены адресов класса С на адреса класса В. Изменение сетевых адресов может потребовать от администратора сети больших усилий и достаточно много времени для проведения работ по отладке. Ввиду того, что су ществует четкая граница между классами адресов, администраторы сетей не могут заранее спланировать плавный переход изменения адресов. Вместо этого прихо­дится достаточно жестко вмешиваться в работу сети: вводится запрет на использо­вание некоторых сетевых адресов, производится одновременное изменение всех ад­ресов устройств в этой сети. И только после этого сеть вновь включается в работу. Еще одним недостатком введения классов адресов является значительное уменьше­ние числа теоретически возможных индивидуальных адресов. В текущей версии протокола IP (версия 4) общее число адресов может составлять 2³² (4 294 967 296), так как протокол предусматривает использование 32 бит для задания адреса. Ис­пользование части битов в служебных целях уменьшает доступное количество ин­дивидуальных адресов.

Адрес класса А предназначен для использования в больших сетях, где количе­ство компьютеров исчисляется тысячами. Каждый адрес класса А имеет 8-разряд­ный префикс сети, в котором старший бит установлен в 1, а следующие 7 бит ис­пользуются для задания номера сети. Для задания номера хоста используются ос­тавшиеся 24 бита. В настоящее время все адреса класса А уже выделены. Сети класса А также обозначаются записью /8, так как адреса этого класса имеют 8-разрядный сетевой префикс (7 + 1 = 8).

Максимальное число сетей класса А, которые можно определить, составляет 126 (2⁷-2). Каждая сеть этого класса поддерживает максимум 16 777 214 (2²⁴-2) хостов. Так как адресный блок класса А может содержать максимум 2³¹ (2 147 483 648) ин­дивидуальных адресов, а в протоколе IP версии 4 может поддерживаться максимум 2³² (4 294 967 296) адресов, то адресное пространство класса А занимает 50% преду­смотренного адресного пространства.

Адрес класса В используется в сетях среднего размера, например в сетях круп­ной организации. Каждая сеть класса В имеет 16-разрядный префикс сети, в кото­ром два старших бита установлены в 10, а следующие 14 бит используются для задания номера сети. Для задания номера хоста используются оставшиеся 16 бит. Сети класса В также обозначаются записью /16.

Максимальное число сетей класса В, которые можно определить, составляет 16 384 (2¹⁴). Каждая сеть этого класса поддерживает максимум 65 534 (2¹⁶-2) хоста. Так как весь адресный блок класса В может содержать максимум 2³⁰ (1 073 741 824) индивидуальных адресов, то он занимает 25% предусмотренного адресного про­странства.

Адреса класса С используются в сетях с небольшим числом компьютеров. Каж­дая сеть класса С имеет 24-разрядный префикс сети, в котором три старших бита установлены в 110, а следующие 21 бит используются для задания номера сети. Для задания номера хоста используются оставшиеся 8 бит. Сети класса С также обозначаются записью /24.

Максимально возможное число сетей класса С составляет 2 097 152 (2²¹). Каж­дая сеть этого класса поддерживает максимум 254 (2⁸-2) хоста. Так как весь адрес­ный блок класса С может содержать максимум 2²⁹ (536,870,912) индивидуальных адресов, он занимает 12,5% предусмотренного адресного пространства.

В дополнение к этим трем наиболее популярным классам адресов существует еще два класса. В классе D старшие четыре бита установлены в 1110. Этот класс используется для поддержки групповой передачи данных. В классе Е старшие че­тыре бита установлены в 1111, и этот класс является зарезервированным для экс­периментального использования.

Для удобства в технической литературе, в прикладных программах и т. д. адре­са протокола IP обычно представляются как четыре десятичных числа, разделен­ные точками. Каждое из этих чисел представляет значение одного из четырех ок­тетов IP-адреса. При этом один октет соответствует 8 битам адреса. Рисунок 2.4 показывает, как адрес класса В может быть представлен в точечно-десятичной но­тации.

Таблица 2.2 содержит диапазоны десятичных значений трех классов адресов. В этой таблице запись XXX представляет поле для указания адреса хоста.

Некоторые IP-адреса зарезервированы для определенных целей и не могут при­сваиваться конечным устройствам в сети. В табл. 2.3 перечислены зарезервиро­ванные IP-адреса.

В зарезервированных IP-адресах все установленные в ноль биты соответству ют либо данному устройству, либо данной сети. IP-адреса, все биты которых уста новлены в 1, используются при широковещательной передаче информации. Дл; ссылки на всю IP-сеть в целом используется адрес с номером хоста, у которого вс< биты установлены в 0. Сетевой адрес класса А 127.0.0.0 зарезервирован для обрат ной связи и введен для тестирования взаимодействия процессов на одной машине Когда приложение использует адрес обратной связи, стек TCP/IP возвращает эт! данные приложению, ничего не посылая по сети. Следует отметить, что в сетях построенных на базе протокола IP, запрещается присваивать устройствам IP-ад реса, начинающиеся с числа 127.

Все вышесказанное о классах адресов в протоколе IP и их свойствах можш обобщить в одной таблице (табл. 2.4). Обратите внимание на формат записи адре са для соответствующего класса: N обозначает адрес сети, а Н — адрес хоста в это! сети. Как уже отмечено, класс D используется для групповой доставки информа ции, а Е — экспериментальный класс.

Помимо возможности направленной передачи информации определенному хосту, существует широковещательная передача (broadcasting), при которой ин­формацию получают все хосты в указанной сети. Положениями стандарта опреде­лено, что любой адрес, состоящий из одних единиц, зарезервирован для широко­вещания. В протоколе IP существует два типа широковещания: направленное (directed) и ограниченное (limited). Направленное широковещание позволяет хо­сту на удаленной сети передавать одну дейтаграмму, которая будет доставлена всем хостам в адресованной сети. Дейтаграмма с направленным широковещательным адресом может проходить через маршрутизаторы в распределенной сети, при этом исходная дейтаграмма будет доставлена всем хостам только в нужной сети, а не в промежуточных сетях.

При направленном широковещании адрес получателя содержит корректный номер сети и номер хоста, все биты которого установлены в нули или единицы. Например, адреса 185.100.255.255 и 185.100.0.0 будут рассматриваться как адреса направленного широковещания для сети 185.100.xxx.xxx класса В. Таким образом, направленные широковещательные адреса обеспечивают мощный механизм, по­зволяющий удаленному устройству посылать одну IP-дейтаграмму, которая бу­дет доставлена в режиме широковещания в указанную сеть. Для получения более подробной информации о направленном широковещании можно обратиться к до­кументу RFC 1812.

СОВЕТ

В рекомендациях компании Cisco Systems по внедрению системы безопасности в распределенной сети предлагается отключать поддержку направленного широковещания на промежуточных марш­рутизаторах. В общем случае это отключение не повлияет на работоспособность конечных уст­ройств в сети и на их связь друг с другом. Отключение направленного широковещания может пре­пятствовать попыткам заполнения целевой сети ненужным широковещательным трафиком, кото­рый способен помешать нормальной работе. Для отключения этого механизма следует использо­вать команду no ip directed-broadcast в режиме конфигурации интерфейсов. Следующие команды отключают направленное широковещание через интерфейс EthernetO:

Router(config)#int ethQ Router(config)#no ip directed-broadcast

С точки зрения адресации, главным недостатком направленного широковеща­ния является то, что требуется знание номера целевой сети. Вторая форма широ­ковещания, называемая ограниченной, обеспечивает широковещательную передачу для сети отправителя независимо от указанного IP-адреса. Дейтаграмма с ограни­ченным широковещательным адресом никогда не сможет пройти через маршрути­заторы — последние не пропустят ее дальше себя в остальные части распределен­ной сети. При ограниченном широковещании биты номера сети и номера хоста состоят из одних нулей или единиц. Таким образом, дейтаграмма с адресом полу­чателя 255.255.255.255 или 0.0.0.0 будет рассматриваться как дейтаграмма с огра­ниченным широковещанием.

Прежде чем использовать в сети (подключенной к Интернету) протоколы сте­ка TCP/IP, необходимо получить один или несколько официальных сетевых но­меров. Все адреса назначает одна организация — Internet Network Information Centre (InterNIC), что обеспечивает уникальность адресов. До апреля 1993 года назначением IP-адресов занималась организация Network Information Center (NIC).

В настоящее время эта организация выполняет запросы только для сетей Defense Data Network (DDN), иначе говоря для военных целей. Организация InterNIC на­значает только сетевую часть адреса, или сетевой префикс, оставляя ответствен­ность за назначение номеров хостов в этой сети самой организации, запросившей этот адрес.

Подсети

В 1985 году документом RFC 950 был определен стандартный процесс поддержки формирования подсетей, или разделения единственного номера сети классов А, В и С на меньшие части. Формирование подсетей было введено для преодоления следующих проблем:

· резкий рост таблиц маршрутизации в Интернете;

· появление дефицита номеров сетей при необходимости расширения их коли­чества.

Обе эти проблемы решались путем добавления еще одного уровня иерархии к адресной структуре протокола IP. Вместо двухуровневой иерархии новая кон­цепция формирования подсетей вводит поддержку еще одного уровня — третьего. На рис. 2.5 представлен процесс формирования подсетей, в котором номер хоста делится на две части: номер подсети и номер хоста в этой подсети.

Формирование подсетей решает проблему роста таблиц маршрутизации, так как конфигурация подсетей корпоративной сети никогда не видна за пределами организации. Маршруты из Интернета в любую подсеть данного IP-адреса одина­ковы, независимо от того, на какой подсети расположен получатель. Это стало воз­можным потому, что все подсети данного номера сети используют один и тот же сетевой префикс, но с разными номерами подсетей. Маршрутизаторам в частной сети требуется различать отдельные подсети, а у маршрутизаторов в Интернете все эти подсети определены единственной записью в таблицах маршрутизации. Это позволяет администратору частной сети вносить любые изменения в логиче­скую структуру сети без влияния на размер таблиц маршрутизации у маршрутиза­торов в Интернете.

Формирование подсетей также позволяет решить вторую проблему, связанную с выделением организации нового сетевого номера или номеров при ее росте. Орга­низации можно выделить один номер сети, после чего администратор имеет возможность произвольно присваивать номера подсетей

каждой из своих внутрен­них сетей. Это позволяет внедрять дополнительные подсети без необходимости получения нового сетевого номера.

На рис. 2.6 показан пример распределенной сети, состоящей из нескольких ло­гических сетей, которые используют концепцию подсетей внутри одного адреса класса В. Граничный маршрутизатор получает весь трафик, адресованный сети 130.5.0.0 из Интернета, и передает его внутренним подсетям, основываясь на ин­формации, содержащейся в третьем октете.

Формирование подсетей внутри частной сети организации дает следующие преимущества:

· размер глобальных таблиц маршрутизации в Интернете не растет, так как ад­министратор частной сети не нуждается в получении дополнительной адрес­ной информации;

· администратор получает возможность по своему усмотрению внедрять допол­нительные подсети без получения новых номеров сетей;

· изменение топологии частной сети не влияет на таблицы маршрутизации в Интернете, поскольку маршрутизаторы в Интернете не имеют маршрутов в индивидуальные подсети организации — они имеют только маршрут в роди­тельскую сеть.

Маска подсети

Если маршрутизаторы в Интернете используют для передачи трафика в окруже­ние подсетей только сетевой префикс адреса получателя, то маршрутизаторы внут­ри этого окружения для передачи трафика индивидуальным подсетям использу­ют расширенный сетевой префикс. Расширенный сетевой префикс состоит из пре­фикса сети и номера подсети (см. рис. 2.7).

Структуру расширенного сетевого префикса можно представить в виде маски подсети (subnet mask). Маска подсети — это число, двоичная запись которого со­держит единицы в тех разрядах, которые должны интерпретироваться как номер сети. Маска подсети позволяет провести четкую границу между двумя частями IP-адреса. Одна часть идентифицирует номер подсети, вторая используется для идентификации хостов в этой подсети.

Хосты и маршрутизаторы используют старшие биты IP-адреса для определе­ния его класса. После того как класс определен, хост может легко найти границу между битами, использующимися для идентификации номера сети и для иденти­фикации номера хоста в этой сети. Однако для определения границ битов, иденти­фицирующих номер подсети, такая схема не подходит. Для решения этого вопроса используется 32-разрядная маска подсети, которая помогает однозначно опреде­лить требуемую границу. Для стандартных классов сетей маски имеют следующие значения:

255.0.0.0 — маска для сети класса А;

255.255.0.0 — маска для сети класса В;

255.255.255.0 — маска для сети класса С.

Например, если используется адрес класса В 130.5.0.0 и сетевой администратор хочет использовать весь третий октет для номера подсети, ему необходимо указать маску подсети 255.255.255.0. Биты в маске подсети задают способ интерпретации битов адреса: если бит в маске подсети равен 1, то система, проверяющая адрес, должна рассматривать соответствующий бит в IP-адресе как часть расширенного сетевого префикса. Другими словами, после определения класса IP-адреса любой бит в части номера хоста, которому соответствует единичный бит в маске подсети, используется для идентификации номера подсети. Оставшаяся часть номера хос­та, которой соответствует нулевое значение маски подсети, используется для зада­ния номера хоста. На рис. 2.8 показан пример IP-адреса класса В с соответствую­щей маской подсети.

Все сказанное можно проиллюстрировать рисунком, из которого становится понятным механизм формирования маски подсети — происходит простое преоб­разование двоичной записи в десятичную (см. рис. 2.9).

В стандартах, описывающих современные протоколы маршрутизации, часто делается ссылка на длину расширенного сетевого префикса, а не на маску подсети. Данная длина эквивалентна количеству единичных битов в маске подсети. Это означает, что сетевой адрес 130.5.5.25 с маской подсети 255.255.255.0 может быть также записан как 130.5.5.25/24. Число 24 указывает на то, что в маске подсети

255.255.255.0 количество единичных битов равно 24. Такая запись является более компактной и легкой для понимания, чем запись с использованием маски подсети в ее традиционной точечно-десятичной нотации. Рисунок 2.10 иллюстрирует при­мер записи расширенного сетевого префикса.

. Следует отметить, что большинство современных протоколов маршрутизации переносят маску подсети в своих сообщениях. В то же время не существует стан­дартного протокола маршрутизации, который имел бы дополнительное однобай­товое поле в заголовке своих сообщений, определяющее число битов в расширен­ном сетевом префиксе. Протоколы маршрутизации передают полную четырехок-тетную маску подсети.

Перед тем как разрабатывать сеть на базе протокола IP, сетевому администра­тору необходимо ответить на следующие четыре важных вопроса:

1. Как много подсетей требуется организации сегодня?

2. Как много подсетей может потребоваться организации в будущем?

Для определения какой-либо подсети адмтмотриаиг к: метает двоичное пред­ставление ее номера (в данном примере для восыш твасегхш. это может быть чис­ло от 0 до 7) в битовое поле номера подсети. Наяршмвр,ЯШ1 определения подсети #4 администратор просто помещает двоичное преяопшвашве числа 4 (00000100₂) в трехбитовое поле номера подсети. Таблица 2.5. совдрввг нж восемь возможных вариантов подсетей рассматриваемого примера.

Самым простым способом проверки корректности опредевшиишииоетей явля­ется контроль кратности всех десятичных номеров подсетей померят подсети #1. В данном примере все номера подсетей кратны 32.

ПРИМЕЧАНИЕ

Компания Cisco Systems включила в свой программный продукт ConfigMaker v2.4 инструмент рабо­ты с адресами, называемый IP Subnet Calculator. Администратор, введя адрес и маску подсети, полу­чает полную классификацию (см. рис. 2.12).

Когда схема введения подсетей была опубликована в документе RFC 950, за­прещалось использование номеров подсетей, у которых все биты установлены в единицы или нули. Причиной такого ограничения является необходимость устра­нения возможных проблем при работе тех протоколов маршрутизации, которые не переносят в своих служебных сообщениях ни маску подсети, ни длину расши­ренного сетевого префикса. Например, если используется протокол маршрутиза­ции RIP (его первая версия — обозначается как RIP-1), который не переносит маску подсети и длину расширенного сетевого префикса, маршруты в разные подсети с адресами 193.1.1.0 /27 и 193.1.1.0 /24 будут рассматриваться как идентичные. То есть без указания маски подсети маршрутизатор не делает различий между марш­рутом в одну подсеть и маршрутом во всю сеть. Похожая проблема, но только с определением направления широковещания возникает и в случае равенства всех битов единице. Например, один адрес 193.1.1.255 используется как широковеща­тельный для всей сети 193.1.1.0/24 и для подсети 193.1.1.224/27. Рисунок 2.13 иллюстрирует обе рассмотренные ситуации.

С разработкой протоколов маршрутизации, переносящих маску подсети (OSPF, IS-IS) с каждым рекламируемым маршрутом, стало возможно вопреки документу RFC 950 использовать подсети, все биты которых установлены в единицу и ноль. По этой причине производители позволяют настраивать подсети с такими номе­рами на портах своих маршрутизаторов. При этом нужно учитывать следующие два фактора: используемые в корпоративной сети протоколы маршрутизации, от­носящиеся к классу IGP, должны поддерживать маску подсети или расширенный сетевой префикс; необходима поддержка номеров подсетей со всеми единичными и нулевыми битами всеми маршрутизаторами в сети. Кроме того, иногда важно учитывать номер версии программного обеспечения маршрутизатора.

В рассматриваемом примере (табл. 2.6) остается 5 бит для задания адресов хос­тов в каждой подсети. В результате каждая подсеть может содержать блок из 30 адресов хостов (2⁵ - 2 = 30), которые нумеруются от 1 до 30. Для определения адреса хоста N в сети администратор помещает

двоичноевракпввеяне числа N в поле номера хоста. Например, для определения адреса, иин^ийигпйипщшп при­своить хосту #28 в подсети #2, администратор просто ппмицаит дрииинпр пред­ставление 28 (11100₂) в пятибитовое поле подсети #2. В табл. 25 •оказаны неко­торые возможные комбинации номеров хостов в подсети #2.

Для того чтобы проверить корректность широковещательного адреса для опре­деленной подсети, можно использовать следующее простое правило: во всег слу­чаях широковещательный адрес для подсети #N на единицу меньше, чем базовый адрес для подсети #(N+1). Например, широковещательный адрес для подсети #2 (193.1.1.95) на единицу меньше базового адреса подсети #3 (193.1.1.96).

Перед передачей дейтаграммы хосту необходимо определить:

1. Располагается ли получатель в той же подсети, что и отправитель?

2. Если существует более чем один маршрутизатор, имеющий маршрут в нужную сеть, какой маршрутизатор необходимо использовать отправителю?

До введения подсетей процесс передачи выполнялся путем выделения поля сетевого номера из IP-адреса получателя, содержащегося в заголовке IP-дейта­граммы, и последующего сравнения с собственным IP-адресом хоста. Если сете­вые номера адреса отправителя и получателя совпадают, то они располагаются в одной локальной сети, и дейтаграмма может быть передана напрямую. Если но­мера сетей разные, то дейтаграмму необходимо посылать получателю, используя маршрутизатор по умолчанию.

После введения подсетей этот процесс значительно усложнился, так как полу­чатель может располагаться в другой подсети той же самой сети, что и получатель. Для осуществления процесса передачи в этом случае используется маска подсети. Выполняется операция «логическое И» между IP-адресом получателя и маской подсети. Результат сравнивается с результатом выполнения той же операции, но для собственного IP-адреса хоста и той же маски подсети. Если результаты этих двух операций идентичны, то отправитель и получатель находятся в одной подсе­ти и дейтаграмма может быть послана напрямую. Если результаты различны, то получатель находится в другой подсети. В этом случае дейтаграмма посылается маршрутизатору.

В табл. 2.7 и 2.8 представлены некоторые возможные (и наиболее часто исполь­зуемые) варианты выделения подсетей для сетей классов В и С.

При рассмотрении примера разделения на подсети сети класса С 193.1.1.0 /24 была отмечена рекомендация относительно порядка битов при выделении подсе­тей. В документе RFC 1219 есть основное правило, которому желательно следо­вать при присвоении номеров подсетям и хостам. Номера подсетей назначают та­ким образом, чтобы старшие биты в номере подсети устанавливались первыми. Например, если поле номера подсети состоит из 4 бит, то первые несколько номе­ров подсетей должны быть следующими: 8 (1000₂), 4 (0100₂), 12 (1100₂), 2 (0010₂), 6 (0110₂) и т. д. Иными словами, единичные биты номеров подсетей рекомендует­ся устанавливать, начиная с крайней левой позиции. В то время как единичные биты номеров хостов рекомендуется устанавливать, начиная с крайней правой позиции (табл. 2.9).

Если следовать этому правилу, то на границе между номером подсети и номе­ром хоста будут существовать нулевые биты. Это позволяет менять маску подсети без изменения IP-адреса, присвоенного хосту. Необходимость в изменении маски подсети может возникнуть при расширении числа хостов в каждой подсети, с уче­том того, что планируемое число возможных подсетей обычно больше необходи­мого в настоящий момент. В этом случае существует возможность «заимствова­ния» под номера подсетей некоторых битов из числа зарезервированных. Досто­инством описанного правила является то, что администратору достаточно изме­нить маску подсети на каждом хосте и не нужно переконфигурировать IP-адреса хостов во всей организации. Изменение адресов потребует больших усилий от ад­министратора, так как в данном случае может потребоваться изменение почтовых сервисов, статических таблиц маршрутизации и т. д.

В сети, которая была разбита на подсети, можно использовать два типа широ­ковещательной передачи информации: направленное широковещание и ограни­ченное. Направленное широковещание используется для передачи дейтаграммы всем хостам в определенной подсети. Для посылки дейтаграммы всем хостам во всех подсетях необходимо использовать ограниченное широковещание с адресом 255.255.255.255. Однако необходимо учесть, что маршрутизаторы не пропускают дейтаграммы с таким адресом. Существует одно ограничение, накладываемое на направленное широковещание в средах с подсетями. Биты, назначенные для фор­мирования номеров подсетей, обычно являются частью поля номера хоста и не могут быть все установлены в нули или единицы. Например, если есть адрес клас­са В, в котором третий байт выделен под номера подсетей — 128.1.<Номер подсе-ти>.<Номер хоста>, то в этом случае адрес направленного широковещания не мо­жет быть равен 128.1.255.255,128.1.0.255,128.1.255.0 и 128.1.0.0.

Существуют теоретические и практические аргументы, призывающие не исполь­зовать верхние (все биты единичные) и нижние подсети (все биты нулевые) в рас­пределенных сетях (можно также встретить термин «граничные подсети»). Как уже не раз отмечалось, теоретически битовое поле содержит два специальных зна­чения: все биты установлены в ноль, что обычно означает «данный», например «данное устройство» или «данная сеть», и все биты установлены в единицу, что

Если следовать этому правилу, то на границе между номером подсети и номе­ром хоста будут существовать нулевые биты. Это позволяет менять маску подсети без изменения IP-адреса, присвоенного хосту. Необходимость в изменении маски подсети может возникнуть при расширении числа хостов в каждой подсети, с уче­том того, что планируемое число возможных подсетей обычно больше необходи­мого в настоящий момент. В этом случае существует возможность «заимствова­ния» под номера подсетей некоторых битов из числа зарезервированных. Досто­инством описанного правила является то, что администратору достаточно изме­нить маску подсети на каждом хосте и не нужно переконфигурировать IP-адреса хостов во всей организации. Изменение адресов потребует больших усилий от ад­министратора, так как в данном случае может потребоваться изменение почтовых сервисов, статических таблиц маршрутизации и т. д.

В сети, которая была разбита на подсети, можно использовать два типа широ­ковещательной передачи информации: направленное широковещание и ограни­ченное. Направленное широковещание используется для передачи дейтаграммы всем хостам в определенной подсети. Для посылки дейтаграммы всем хостам во всех подсетях необходимо использовать ограниченное широковещание с адресом 255.255.255.255. Однако необходимо учесть, что маршрутизаторы не пропускают дейтаграммы с таким адресом. Существует одно ограничение, накладываемое на направленное широковещание в средах с подсетями. Биты, назначенные для фор­мирования номеров подсетей, обычно являются частью поля номера хоста и не могут быть все установлены в нули или единицы. Например, если есть адрес клас­са В, в котором третий байт выделен под номера подсетей — 128.1.<Номер подсети>.<Номер хоста>, то в этом случае адрес направленного широковещания не мо­жет быть равен 128.1.255.255,128.1.0.255,128.1.255.0 и 128.1.0.0.

Существуют теоретические и практические аргументы, призывающие не исполь­зовать верхние (все биты единичные) и нижние подсети (все биты нулевые) в рас­пределенных сетях (можно также встретить термин «граничные подсети»). Как уже не раз отмечалось, теоретически битовое поле содержит два специальных зна­чения: все биты установлены в ноль, что обычно означает «данный», например «данное устройство» или «данная сеть», и все биты установлены в единицу, что

означает «все», например «все устройства» или «все сети». Ранние документы, рег­ламентирующие адресацию в Интернете, рекомендовали оставлять эти значения неиспользуемыми. Это определяло запрет на использование адреса нижней сети из всех нулей и адреса верхней сети из всех единиц. В результате программное обеспечение, обслуживающее протокол IP на сетевых устройствах, проверяло факт настройки пользователем адресации в обход этих правил. На практике использо­вание этих подсетей может быть проблематичным, так как не все устройства, осо­бенно выпущенные давно, поддерживают такую настройку. Для того чтобы избе­жать проблем, следует быть хорошо осведомленным о конкретном устройстве и выяснить, какое адресное пространство оно позволяет настроить. Маршрутиза­торы фирмы Cisco Systems допускают настройку на использование рассматривае­мых подсетей, так что в свое распоряжение можно получить еще одну подсеть. Для того чтобы использовать нижнюю подсеть, нужно выполнить команду ip subnet-zero в глобальном режиме конфигурации.

Routerfconfigure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)#ip subnet-zero

В том случае, если администратор сети не вводил эту команду на маршрутиза­торе, попытка настроить интерфейс с адресом нижней подсети приведет к появле­нию сообщения об ошибке:

Routerfconfigure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)#no ip subnet-zero

Router(config)#interface sen all

Router(config-if)#ip address 192.168.1.2 255.255.255.224

Bad mask /27 for address 192.168.1.2

Практика выделения IP-подсетей

Рассмотрим практические примеры выделения подсетей и назначения адресов устройствам в этих подсетях. Предположим, что организации для ее корпоратив­ной сети назначен сетевой адрес 140.25.0.0/16 (или адрес 140.25.0.0 класса В — в существующей технической литературе автор не нашел устоявшегося определе­ния). При этом организация планирует разделить сеть на несколько подсетей, каж­дая из которых должна поддерживать до 60 устройств. На первом шаге необходимо определить число битов, требуемых для иденти­фикации 60 устройств в подсети. Адрес конкретного устройства имеет определен­ное двоичное представление, и верхняя граница адресного пространства для уст­ройств одной подсети представляется степенью числа 2. Это, в частности, означа­ет, что невозможно выделить адресное пространство точно для 60 устройств, так как 60 не является степенью двойки. Ближайшая большая степень двойки — это 64 = 2⁶. На самом деле, к числу устройств нужно прибавить 2, так как адреса, содер­жащие только нули или только единицы, не используются для адресации отдель­ных устройств. Выбрав эту степень двойки, мы ввели два запасных адреса:

(60+2=62) < 64. Однако, удовлетворяя существующие на сегодня потребности по числу рабочих мест, такой выбор не оставляет адресного пространства для воз­можного роста подсети. И хотя следующая степень двойки равна 128 (2⁷) и число адресов устройств будет равно 2⁷- 2 = 126, то есть намного больше требуемого в настоящий момент, сетевому администратору необходимо выбрать именно это адресное пространство и получить 66 (126 - 60) дополнительных адресов для каж­дой подсети. Такой выбор означает, что поле адреса устройства займет 7 бит.

На втором шаге определяется маска подсети и длина расширенного сетевого префикса. Так как для идентификации устройств из 32-разрядного IP-адреса ре­шено выделить 7 бит, получаем расширенный сетевой префикс /25 (32 - 7 = 25). Такой 25-разрядный расширенный сетевой префикс может быть выражен в точеч­но-десятичном представлении маской подсети 255.255.255.128. Рисунок 2.14 по­казывает запись маски подсети и расширенного сетевого префикса.

Как видно, 25-разрядный расширенный префикс предполагает выделение 9 бит для идентификации подсетей. Теперь можно вычислить количество идентифици­руемых подсетей: 2⁹= 512, то есть 9 бит позволяют назначить адреса 512 подсетям. Понятно, что администратор сети получает в этом случае некоторую свободу дей­ствий при определении соотношения числа идентифицируемых устройств и чис­ла подсетей. Выделяя большее число битов в поле идентификации устройств, ад­министратор может включать в подсеть больше устройств. С другой стороны, чем меньше битов выделено для идентификации устройств, тем больше подсетей мо­жет создать администратор. Все зависит от текущих требований организации.

Выделенные 512 подсетей пронумеруем от 0 до 511. Если выделить 9 разрядов для двоичного представления десятичных чисел от 0 до 511, то получим:

0(000000000₂). 1(000000001₂). 2(000000010₂). 3(000000011₂),.....,511(111111111₂).

Например, для определения подсети номер 3 (#3) сетевой администратор разме­щает двоичное представление числа 3 (000000011)₂ в 9 битах номера подсети. Но­мера подсетей для рассматриваемого примера приводятся ниже. В каждом адресе курсивом выделен расширенный сетевой префикс всего адреса, в то время как 9-битовое представление поля номера подсети выделено полужирным шрифтом:

Базовая сеть: 10001100.00011001.00000000.0 0000000 = 140.25.0.0/16 Подсеть #0: 10001100.0001100. 00000000.0 0000000 = 140.25.0.0/25

Подсеть #1: 10001100.00011001. 00000000.1 0000000 = 140.25.0.128/25

Подсеть #2: 10001100.00011001. 00000001.0 0000000 - 140.25.1.0/25

Подсеть #3: 10001100.00011001. 00000001.1 0000000 = 140.25.1.128/25

Подсеть #4: 10001100.00011001. 00000010.0 0000000 = 140.25.2.0/25

Подсеть #5: 10001100.00011001. 00000010.1 0000000 = 140.25.2.128/25

Подсеть #6: 10001100.00011001. 00000011.0 0000000 = 140.25.3.0/25

Подсеть #7: 10001100.00011001. 00000011.1 0000000 = 140.25.3.128/25

Подсеть #8: 10001100.00011001. 00000100.0 0000000 = 140.25.4.0/25

Подсеть #9: 10001100.00011001. 00000100.l 0000000 = 140.25.4.128/25

Подсеть #510: 10001100.00011001. 11111111. 0 0000000 = 140.25.255.0/25

Подсеть #511: 10001100.00011001. 11111111. 1 0000000 = 140.25.255.128/25

Итак, администратор выделил 7 бит для идентификации устройств в каждой подсети. Это означает, что каждая подсеть имеет 126 адресов для идентификации устройств. Устройства в подсети нумеруются от 1 до 126. Приведем перечень ад­ресов устройств для подсети #3. При этом курсивом выделен расширенный сете­вой префикс, а жирным шрифтом показано 7-разрядное поле номера устройства:

Подсеть #3: 10001100.00011001.00000001.1 0000000 = 140.25.1.128/25

Устройство #1: 10001100.00011001.00000001. 1 0000001 = 140.25.1.129/25

Устройство #2: 10001100.00011001.00000001. 1 0000010 = 140.25.1.130/25

Устройство #3: 10001100.00011001.00000001. 1 0000011 = 140.25.1.131/25

Устройство #4: 10001100.00011001.00000001.1 0000100 - 140.25.1.132/25

Устройство #5: 10001100.00011001.00000001.1 0000101 = 140.25.1.133/25

Устройство #6: 10001100.00011001.00000001.1 0000110 = 140.25.1.134/25

Устройство #62: 10001100.00011001.00000001. 1 0111110 = 140.25.1.190/25

Устройство #63: 10001100.00011001.00000001. 1 0111111 - 140.25.1.191/25

Устройство #64: 10001100.00011001.00000001.1 1000000 = 140.25.1.192/25

Устройство #65: 10001100.00011001.00000001.1 0000001 = 140.25.1.193/25

Устройство #123: 10001100.00011001.00000001. 1 1111011 = 140.25.1.251/25

Устройство #124: 10001100.00011001.00000001. 1 1111100 = 140.25.1.252/25

Устройство #125: 10001100.00014001.00000001. 1 1111101 = 140.25.1.253/25

Устройство #126: 10001100.00011001.00000001. 1 1111110 = 140.25.1.254/25

Для подсети #3 широковещательным адресом будет адрес, в котором все биты поля номера устройства установлены в единицу:

10001100.00011001.00000001. 1 1111111 = 140.25.1.255.

Следует отметить, что широковещательный адрес для подсети #3 ровно на еди­ницу меньше базового адреса подсети #4 (140.25.2.0).

Рассмотрим другую ситуацию. Пусть организации назначен сетевой адрес 132.45.0.0/16. Администратору поручено сформировать 8 подсетей. Для иденти­фикации такого количества подсетей требуется 3 бита. В этом случае расширен­ный сетевой префикс будет равен /19 (маска подсети 255.255.224.0). Приведем адреса этих подсетей в двоичном и десятичном представлениях:

Подсеть #0: 10000100.00101101. 000 00000.00000000 = 132.45.0.0/19

Подсеть #1: 10000100.00101101. 001 00000.00000000 = 132.45.32.0/19

Подсеть #2: 10000100.00101101. 010 00000.00000000 = 132.45.64.0/19

Подсеть #3: 10000100.00101101. 011 00000.00000000 = 132.45.96.0/19

Подсеть #4: 10000100.00101101. 100 00000.00000000 = 132.45.128.0/19

Подсеть #5: 10000100.00101101. 101 00000.00000000 = 132.45.160.0/19

Подсеть #6: 10000100.00101101. 110 00000.00000000 = 132.45.192.0/19

Подсеть #7: 10000100.00101101. 111 00000.00000000=132.45.224.0/19

Теперь определим адреса устройств для подсети #3 (132.45.96.0/19, или 10000100.00101101.011 00000.00000000):

Подсеть #3: 10000100.00101101. 011 00000.00000000 = 132.45.96.0/19

Устройство #1: 10000100.00101101. 011 00000.00000001 = 132.45.96.1/19

Устройство #2: 10000100.00101101. 011 00000.00000010 = 132.45.96.2/19

Устройство #3: 10000100.00101101. 011 00000.00000011 = 132.45.96.3/19

Устройство #8190: 10000100.00101101. 011 11111.11111110 = 132.45.127.254/19

Определим широковещательный адрес для подсети #3 (132.45.96.0/19): 10000100.00101101. 011 11111.11111111 - 132.45.127.255/19

Проделаем те же операции для сетевого адреса 200.35.1.0/24. Пусть также в каж­дой подсети необходимо предусмотреть адресное пространство для 20 устройств. Требуется определить расширенный сетевой префикс. Для идентификации уст­ройств требуется минимум 5 бит. Поэтому расширенный сетевой префикс будет равен /27 (32-5=27). При этом максимальное количество устройств в каждой под­сети равно 30 (32-2=30), а максимальное число подсетей равно 8 (23).

Приведем номера получившихся подсетей в двоичном и десятичном представ­лениях:

Подсеть #0: 11001000.00100011.00000001. 000 00000 = 200.35.1.0/27

Подсеть #1: 11001000.00100011.00000001. 001 00000 = 200.35.1.32/27

Подсеть #2: 11001000.00100011.00000001. 010 00000 = 200.35.1.64/27

Подсеть #3: 11001000.00100011.00000001. 011 00000 = 200.35.1.96/27

Подсеть #4: 11001000.00100011.00000001. 100 00000 = 200.35.1.128/27

Подсеть #5: 11001000.00100011.00000001. 101 00000 = 200.35.1.160/27

Подсеть #6: 11001000.00100011.00000001. 110 00000 = 200.35.1.192/27

Подсеть #7: 11001000.00100011.00000001. 111 00000 = 200.35.1.224/27

Приведем список адресов устройств, которые могут быть определены в подсе­ти #6 (200.35.1.192/27):

Подсеть #6: 11001000.00100011.00000001. 110 00000 = 200.35.1.192/27

Устройство #1: 11001000.00100011.00000001. 110 00001 = 200.35.1.193/27

Устройство #2: 11001000.00100011.00000001. 110 00010 = 200.35.1.194/27

Устройство #3: 1001000.00100011.00000001. 110 00011 = 200.35.1.195/27

Устройство #29: 11001000.00100011.00000001. 110 11101 = 200.35.1.221/27

Устройство #30: 11001000.00100011.00000001. 110 11110 = 200.35.1.222/27

Широковещательный адрес для подсети 200.35.1.192/27 равен: 11001000.00100011.00000001. 110 11111 = 200.35.1.223/27