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

Была ли эта статья полезной?

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

Эта статья не относится напрямую к операционой системе линукс, но тем не менее эта ось создавалась изначально как сетевая ОС и понимание этой информации лишним не будет.

В терминологии сетей TCP/IP маской подсети или маской сети называется битовая маска, определяющая, какая часть IP-адреса узла сети относится к адресу сети.

с помощью маски подсети можно определить, что один диапазон IP-адресов будет в одной подсети, а другой диапазон соответственно в другой подсети.

У маски подсети существует три наиболее часто используемые формы записи:
1. десятичный вид ( 255.255.255.192 );
2. двоичный вид( 11111111.11111111.11111111.11000000 ).
3. /ХХ (/26) — колличество единиц в двоичном представлении маски подсети.

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

Адреса хостов в подсети.
Это набор IP-адресов, которые могут быть выданы хостам (устройствам, подключенным к ip-сети). Чтобы подсчитать количество адресов, нужно от общего количества адресов подсети отнять два адреса(адрес сети и широковещательный). При обмене пакетами между хостами в одной подсети маршрутизатор и шлюз не нужны.

Широковещательный адрес (Broadcast).
Это адрес который не присвоен ни одному хосту в подсети. Данный адрес используется для отправки широковещательных пакетов, которые предназначены каждому хосту подсети.

Пример 1.
Найдем адрес сети, зная IP-адрес (192.168.1.2) и маску подсети (255.255.255.0). Для этого необходимо применить к ним операцию поразрядной конъюнкции (логическое И).
Для этого переводим в двоичную систему счисления.
IP-адрес: 11000000 10101000 00000001 00000010 (192.168.1.2)
Маска подсети: 11111111 11111111 11111111 00000000 (255.255.255.0)
Адрес сети: 11000000 10101000 00000001 00000000 (192.168.1.0)

Пример 2, обратный, найдем адреса хостов и широковещательный адрес
подсети 192.168.111.64/26 .
/26 = 11111111.11111111.11111111.11000000 = 255.255.255.192
192.168.111.64 = 11000000.10101000.01101111.01000000
По маске видим что наша сеть будет иметь диапазон ip-адресов
от: 11000000.10101000.01101111.01000000 = 192.168.111.64
до: 11000000.10101000.01101111.01111111 = 192.168.111.127

Где последний адрес будет широковещательный (broadcast).
Адреса хостов нашей сети:
min(в большинстве случаев является шлюзом*
(gateway)): 11000000.10101000.01101111.01000001 = 192.168.111.65
max: 11000000.10101000.01101111.01111110 = 192.168.111.126
т.е. всего хостов в сети — 62.

Пример 3. Новым сотрудникам техподдержки ПетерСтар посвящается 😉
Наиболее популярная маска подсети для юридических клиентов /30 .

маска: 11111111.11111111.11111111.11111100 = 255.255.255.252
IP-адрес: 01010100.11001100.10100110.01001100 = 84.204.166.76

По маске видим что наша сеть будет иметь диапазон ip-адресов
от 01010100.11001100.10100110.01001100 = 84.204.166.76
до 01010100.11001100.10100110.01001111 = 84.204.166.79

Адреса хостов подсети:

min(шлюз*
(gateway)): 01010100.11001100.10100110.01001101 = 84.204.166.77
модемкомп(если bridge)
: 01010100.11001100.10100110.01001110 = 84.204.166.78
broadcast : 01010100.11001100.10100110.01001111 = 84.204.166.79

*Сетевой шлюз — аппаратный маршрутизатор (англ. gateway) или программное обеспечение для сопряжения компьютерных сетей, использующих разные протоколы (например, локальной и глобальной). Сетевые шлюзы могут быть аппаратным решением, программным обеспечением или тем и другим вместе, но обычно это программное обеспечение, установленное на роутер или компьютер.

Subnetting. Разбиение сети на подсети, суммироваеие, нахождение адреса сети и широковещательного адреса.

При подготовке к CCIE RS Written есть тема, которая посвящена маскам подсети, и прочему.
Я напишу небольшую заметку о том как разбивать сети на подсети, как суммировать их, как найти адреса сети и широковещательных адресов и так далее.

Нахождение адреса сети, широковещательного адреса, первого и последнего допустимых адресов, которые могут быть назначены хостам.

Допустим нам дан некий IP адрес, с маской подсети, например 152.21.121.37 /26, нам необходимо найти адрес сети и широковещательный адрес, а так же первый и последний адреса которые можно присвоить хосту.

Алгоритм действий такой:

Префикс 26 нам говорит о том, что с последнего октета, под сеть выделено 2 бита, и на хосты у нас осталось 6 бит (64 хоста).

Представим этот префикс в двоичном виде и далее переведем последний октет в IP адресе в двоичную систему (нет смысла переводить весь IP адрес в бинарку)

/26 — 1 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 . 1 1 0 0 0 0 0 0
x.x.x.37 — x x x x x x x x . x x x x x x x x . x x x x x x x x . 0 0 1 0 0 1 0 1

Теперь можем определить адрес сети.
Для этого проведем линию по нашему префиксу. Теперь это будет выглядеть так.

/26 — 1 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 . 1 1 | 0 0 0 0 0 0
x.x.x.37 — x x x x x x x x . x x x x x x x x . x x x x x x x x . 0 0 | 1 0 0 1 0 1

И выпишем значения которые могут быть минимальным (все биты равны нулю) и максимальное (когда все биты равны единицы) в хостовой части.
это соответственно — 0 0 0 0 0 0 — что в 10-ной системе равно «0» и 1 1 1 1 1 1 что в 10-ой системе равно 63

Значит адрес нашей сети равен: 152.21.121.0.
Широковещательный адрес: 152.21.121.63
Соответственно первый IP адрес, который можно назначить хосту: 152.21.121.1
Последний IP адрес, который можно назначить хосту: 152.21.121.62

Нахождение IP адреса по номеру подсети и номеру хоста.
Не представляю особо где может понадобиться, но тем не менее

Дана сеть, скажем 49.0.0.0, которая поделена маской /25 на множество подсетей.
Необходимо найти IP адрес, если известно что он принадлежит 429 подсети и имеет номер 41.

49.0.0.0 согласно классификации сетей принадлежит классу А, следовательно префикс такой сети равен /8, Запишем его в бинарном виде.

8/ — 1 1 1 1 1 1 1 1 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0

Представим префикс /25 так же в бинарном виде:

/25 — 1 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 . 1 0 0 0 0 0 0 0

Так как разрешено использовать для подсети все единицы и нули, то из требуемой подсети 429 вычитаем 1. Получаем 428, это число нам нужно представить в бинарном ввиде, на том месте где у нас «единички» в подсети.

428 — 0 0 0 0 0 0 0 0 . 0 0 0 0 0 0 0 0 . 1 1 0 1 0 1 1 0 . 0 0 0 0 0 0 0 0

Представим в бинарном виде 41 (номер нашего искомого хоста в нужной подсети).

41 — 0 0 1 0 1 0 0 0

Что у нас получилось?

49.0.1 1 0 1 0 1 1 0 . 0 0 1 0 1 0 0 1

Переведем весь адрес в десятичный вид:

Суммирование сетей очень важно уметь делать, ибо применяется в маршрутизации повсеместно, а именно там, где нам нужно объединить кучу сетей, в одну, тоесть иными словами «суммировать».
Давайте также разберемся на примере.

Дано:
Сети адреса которых:

* 140.176.2.128 / 25
* 140.176.3.0 / 25
* 140.176.3.192 / 26
* 140.176.3.128 / 26
* 140.176.2.0 / 25

Необходимо заменить все эти подсети — одной, которая будет объеденять все вышеуказанные, с наименьшей потерей адресов. Можно конечно не сильно присматриваясь сделать так: 140.176.0.0 /16 , да, это будет работать, но это грубое суммирование и не корректное.

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

В данном примере 140.176. является статичной, поэтому ее трогать не будем, будем переводить последние два октета:

2.128 / 25 — 0 0 0 0 0 0 1 0 . 1 0 0 0 0 0 0 0
3.0 / 25 — 0 0 0 0 0 0 1 1 . 0 0 0 0 0 0 0 0
3.192 / 26 — 0 0 0 0 0 0 1 1 . 1 1 0 0 0 0 0 0
3.128 / 26 — 0 0 0 0 0 0 1 1 . 1 0 0 0 0 0 0 0
2.0 / 25 — 0 0 0 0 0 0 1 0 . 0 0 0 0 0 0 0 0

Далее нам необходимо найти неизменяемые не в одной подсети значения, я отметил их жирным.
Таким образом получается что префикс новой сумированной сети будет: /23

Полностью суммированная сеть будет выглядеть так: 140.176.2.0/23

Разбиение сети на подсети.

Например, есть у нас сеть класса С, 192.168.0.0 / 24
Нам необходимо разбить эту сеть на две одинаковые подсети.
Разбиение осуществляется путем заимствования бита из поля, которое предназначено для хоста, в поле которое предназначено для маски.
Наша основная сеть имеет префикс 24 бита, мы добавляем к нему 1, и получаем новый префикс /25
Так как мы взяли всего один бит, следовательно и сетей у нас может быть только две (бит может принимать значение 1 или 0).
В каждой такой сети есть 128 адреса (2 в 7 степени (32 — 25 = 7 ) ).

Итак у нас получилось две подсети с адресами:

192.168.0.0 — 192.168.0.127 /25 (Доступные адреса для хостов: 192.168.0.1 — 192.168.0.126)
192.168.0.128 — 192.168.0.255/25 (Доступные адреса для хостов: 192.168.0.129 — 192.168.0.254)

Это был очень простой пример.

Так же каждую такую сеть вы можете еще разбить на несколько подсетей, не обязательно поровну, но и на различное количество хостов в каждой подсети.
Например, мы хотим разбить сеть 192.168.0.128/25 на одну сеть которая бы имела не менее 30 адресов, и другую сеть, которая имела бы не менее 60 адресов.

Находим необходимые префиксы наших новых сетей.
30 адресов, ищим ближайшее значение степени двойки, 2^5 = 32. Это то, что нужно.
Тоесть для этой сети нам достаточно сети пяти бит. (32 -5 = 27), итак префикс нашей новой подсети будет /27

Для второй сети, 60 адресов, ближайшая степень двойки — 64, 2^6 = 64.
Тоесть для новой сети нам необходимо 6 бит (32-6 = 26), префикс будет /26

Ну и запишем что у нас получилось:

1. 192.168.0.128 — 192.168.0.159/27
2. 192.168.0.160 — 192.168.0.123/26

Когда перед нами стоят такие задачи, то нужно начинать разбиение сети с наибольшего количества, адресов, и так по убыванию (в моем примере наоборот).

Определение принадлежности адресов IPv4-сети

Может кто разбирается в этих IPv4, и сможет растолковать мне как это все работает..А то я ничего понять не могу, как найти эти адреса. Нужен только ход рассуждений, и понятное разъяснение решения данной задачи.

Маска сети для IPv4 адресации – это 4-х байтное число, которое делит IP адрес на адрес сети (первая часть) и адрес узла (вторая часть). Для части IP адреса, соответствующей адресу сети в маске сети содержатся двоичные единицы, а для части IP адреса, соответствующей адресу узла в маске сети содержаться двоичные нули. IP адрес, в котором в части адреса узла содержаться только двоичные нули – служебный адрес сети. IP адрес, в котором в части адреса узла содержаться только двоичные единицы – адрес ограниченного широковещания. Эти два адреса нельзя использоваться для адресации узлов.

Сеть с IPv4 адресацией задана одним из адресов, принадлежащих этой сети (192.168.3.17) и маской сети (255.255.192.0) . Определите, какие из перечисленных ниже адресов могут быть назначены устройствам в этой сети.

1. 192.168.3.255

2. 192.168.65.3

3. 192.168.33.0

4. 192.168.192.0

5. 192.168.63.255

Ох не мучили вас в институте или не мучают.
Ну что ж смотри, мой юный падаван, дан хост с адресом 192.168.3.17 , и маска 255.255.192.0 , сказали еще что хост принадлежит сети.
Давай для начала переведем в человеко-формат.
Делаем вот что, все рассчитывают в двоичной системе а мы с тобой сделаем хак и через десятичную рассчитаем.
Берем с лева первый октет который не равен 255 , это октет номер 3 он равен 192 .
Именно он нам интересен.
256-192 = 64 , 64 это шаг, который поможет найти адрес сети.
Он еще не раз встретится в решении. Берем адрес который нам дали в задаче 192.168.3.17 , и смотрим на 3-ий октет, так как именно он нам интересен.
Берем число 64, и 3-ий октет — это 3. Так как 3 < 64, то, ахтунг, адрес сети будет 192.168.0.0 .
Если бы нам дали хост 192.168.73.17 , то адрес сети был бы 192.168.64.0 , а если 192.168.128.17 то 192.168.128.0 .
Понимаешь к чему я?
То есть, с шагом в 64 мы смотрим если число <= 64 то ставим 64 , если больше то 64+64=128 и тоже самое с 128 .
Если больше 128 , то 128+64=192 и т.д.
Круто знаем адрес сети 192.168.0.0 .
Далее найдем broadcast-широковещательный адрес .
Это уже проще.
К 3 октету адреса сети прибавляем шаг, он у нас 64 .
Получаем 192.168.64.0 , дальше нужно просто от 64 отнять константу, она равна 1 , а последний октет заменить на 255 .
Получим 192.168.63.255 .
Это широковещательный адрес.
Все!
Получили диапазон от 192.168.0.0 до 192.168.63.255 .
Теперь смотрим какие адреса в него попадают, 192.168.3.255,192.168.33.0 .
Вообще конечно такие адреса фактически могут и не работать но касательно задачи это скорее всего будет правильным ответом.

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

Начнем, или уже продолжим, с самого популярного, заезженного и больного. Это IP-адреса. На протяжении 4-х статей это понятие встречалось по несколько раз, и скорее всего вы уже либо сами поняли для чего они, либо нагуглили и почитали о них. Но я обязан вам это рассказать, так как без ясного понимания двигаться дальше будет тяжело.

Итак IP-адрес — это адрес, используемый узлом на сетевом уровне. Он имеет иерархическую структуру. Что это значит? Это значит, что каждая цифра в его написании несет определенный смысл. Объясню на очень хорошем примере. Примером будет номер обычного телефона — +74951234567. Первой цифрой идет +7. Это говорит о том, что номер принадлежит зоне РФ. Далее следует 495. Это код Москвы. И последние 7 цифр я взял случайными. Эти цифры закреплены за районной зоной. Как видите здесь наблюдается четкая иерархия. То есть по номеру можно понять какой стране, зоне он принадлежит. IP адреса придерживаются аналогично строгой иерархии. Контролирует их организация IANA(англ. Internet Assigned Numbers Authority). Если на русском, то это «Администрация адресного пространства Интернет». Заметьте, что слово «Интернет» с большой буквы. Мало кто придает этому значение, поэтому объясню разницу. В англоязычной литературе термин «internet» используется для описания нескольких подключённых друг к другу сетей. А термин «Internet» для описания глобальной сети. Так что примите это к сведению.

Несмотря на то, что тема статьи больше теоретическая, нежели практическая, я настоятельно рекомендую отнестись к ней со всей серьезностью, так как от нее зависит понимание дальнейших тем, а особенно маршрутизации. Не для кого, я думаю, не секрет, что мы привыкли воспринимать числовую информацию в десятичном формате (в числах от 0-9). Однако все современные компьютеры воспринимают информацию в двоичном (0 и 1). Не важно при помощи тока или света передается информация. Вся она будет воспринята устройством как есть сигнал (1) или нет (0). Всего 2 значения. Поэтому был придуман алгоритм перевода из двоичной системы в десятичную, и обратно. Начну с простого и расскажу, как выглядят IP адреса в десятичном формате. Вся эта статья посвящена IP адресам версии 4. О версии 6 будет отдельная статья. В предыдущих статьях, лабах, да и вообще в жизни, вы видели что-то вроде этого «193.233.44.12». Это и есть IP адрес в десятичной записи. Состоит он из 4-х чисел, называемых октетами и разделенных между собой точками. Каждое такое число (октет) может принимать значение от 0 до 255. То есть одно из 256 значений. Длина каждого октета равна 8 битам, а суммарная длина IPv4 = 32 битам. Теперь интересный вопрос. Каким образом этот адрес воспримет компьютер, и как будет с ним работать?

Можно конечно набить это в калькулятор, коих навалом в Интернете, и он переведет его в двоичный формат, но я считаю, что переводить вручную должен уметь каждый. Особенно это касается тех, кто планирует сдавать экзамен. У вас не будет под рукой ничего, кроме бумаги и маркера, и полагаться придется только на свои навыки. Поэтому показываю, как это делать вручную. Строится таблица.

Вместо «x» записывается либо 1, либо 0. Таблица разделена на 8 колонок, каждая из которых несет в себе 1 бит (8 колонок = 8 бит = 1 октет). Расположены они по старшинству слева направо. То есть первый (левый) бит — самый старший и имеет номер 128, а последний (правый) — самый младший и имеет номер 1. Теперь объясню, откуда эти числа взялись. Так как система двоичная, и длина октета равна 8-ми битам, то каждое число получается возведением числа 2 в степень от 0 до 7. И каждая из полученных цифр записывается в таблицу от большего к меньшему. То есть слева направо. От 2 в 7-ой степени до 2 в 0-ой степени. Приведу таблицу степеней 2-ки.

Думаю теперь понятно, каким образом строится таблица. Давайте теперь разберем адрес «193.233.44.12» и посмотрим, как он выглядит в двоичном формате. Разберем каждый октет отдельно. Возьмем число 193 и посмотрим, из каких табличных комбинаций оно получается. 128 + 64 + 1 = 193.

Те числа, которые участвовали в формировании комбинации получают 1, а все остальные получают 0.

Берем первый октет 233. 128 + 64 + 32 + 8 + 1.

Для 44 — это 32 + 8 + 4.

И напоследок 12. 8 + 4.

Получается длинная битовая последовательность 11000001.11101001.00101100.00001100. Именно с данным видом работают сетевые устройства. Битовая последовательность обратима. Вы можете так же вставить каждый октет (по 8 символов) в таблицу и получить десятичную запись. Я представлю совершенно случайную последовательность и приведу ее к десятичному виду. Пусть это будет 11010101.10110100.11000001.00000011. Строю таблицу и заношу в нее первый блок.

Получаю 128 + 64 + 16 + 4 + 1 = 213.

Вычисляю второй блок.

Считаю 128 + 32 + 16 + 4 = 180.

Третий блок.

128 + 64 + 1 = 193.

И напоследок четвертый.

2 + 1 = 3

Собираем результаты вычислений и получаем адрес 213.180.193.3. Ничего тяжелого, чистая арифметика. Если тяжело и прям невыносимо трудно, то попрактикуйтесь. Сначала может показаться страшным, так как многие закончили учебу лет 10 назад и многое позабыли. Но уверяю, что как только набьете руку, считать будет гораздо легче. Ну а для закрепления дам вам несколько примеров для самостоятельного расчета (под спойлером будут ответы, но открывайте их только когда прорешаете сами).

Задача №1

1) 10.124.56.220
2) 113.72.101.11
3) 173.143.32.194
4) 200.69.139.217
5) 88.212.236.76
6) 01011101.10111011.01001000.00110000
7) 01001000.10100011.00000100.10100001
00001111.11011001.11101000.11110101
9) 01000101.00010100.00111011.01010000
10) 00101011.11110011.10000010.00111101

Теперь IP-адреса не должны быть чем-то страшным, и можно углубиться в их изучение.
Выше мы говорили о структуре телефонных номеров и их иерархии. И вот на заре рождения Интернета в том представлении, в каком мы его привыкли видеть, возник вопрос. Вопрос заключался в том, что IP-адреса нужно как-то сгруппировать и контролировать выдачу. Решением было разделить все пространство IP-адресов на классы. Это решение получило название классовая адресация (от англ. Classful). Она уже давно устарела, но практически в любой книге на нее отводятся целые главы и разделы. Cisco тоже не забывает про это и в своих учебных материалах рассказывает про нее. Поэтому я пробегусь по этой теме и покажу, чем она блистала с 1981 по 1995 год.

Пространство было поделено на 5 классов. Каждому классу был назначен блок адресов.

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

В чем суть. Первый октет, то есть 8 бит, остаются за адресом сети, а 3 последних октета (то есть оставшиеся 24 бита) назначаются хостам. Вот для того, чтобы показать, какой кусок относится к сети, а какой к хостам, используется маска. По структуре записи она аналогична записи IP-адреса. Отличие маски от IP-адресов в том, что 0 и 1 не могут чередоваться. Сначала идут 1, а потом 0. Таким образом, там где есть единица, значит это участок сети. Чуть ниже, после разбора классов, я покажу, как с ней работать. Сейчас главное знать, что маска класса A — 255.0.0.0. В таблице еще упомянут какой-то первый бит и для класса A он равен 0. Этот бит как раз нужен для того, чтобы сетевое устройство понимало, к какому классу оно принадлежит. Он же еще задает начальный и конечный диапазон адресов. Если в двоичном виде записать на всех октетах единицы, кроме первого бита в первом октете (там всегда 0), то получится 127.255.255.255, что является границей класса A. Например, возьмем адрес 44.58.63.132. Мы знаем, что у класса A первый октет отдается под адрес сети. То есть «44» — это адрес сети, а «58.63.132» — это адрес хоста.

Поговорим про класс B

Этому классу был дан блок поменьше. И адреса из этого блока предназначались для сетей средних масштабов. 2 октета отданы под адрес сети, и 2 — под адрес хостов. Маска у B класса — 255.255.0.0. Первые биты строго 10. А остальные меняются. Перейдем к примеру: 172.16.105.32. Два первых октета под адрес сети — «172.16». А 3-ий и 4-ый под адрес хоста — «105.32».

Класс C

Этот класс обделили адресами и дали ему самый маленький блок. Он был предназначен для мелких сетей. Зато этот класс отдавал целых 3 октета под адрес сети и только 1 октет — под хосты. Маска у него — 255.255.255.0. Первые биты 110. На примере это выглядит так — 192.168.1.5. Адрес сети «192.168.1», а адрес хоста «5».

Классы D и E. Я неcпроста объединил их в один. Адреса из этих блоков зарезервированы и не могут назначаться сетям и хостам. Класс D предназначен для многоадресной рассылки. Аналогию можно привести с телевидением. Телеканал вещает группе лиц свой эфир. И те, кто подключены, могут смотреть телепередачи. То есть в распоряжение администраторов могут попасть только 3 первых класса.

Напомню, что первые биты у класса D — это 1110. Пример адреса — 224.0.0.5.

А первые биты у класса E — это 1111. Поэтому, если вдруг увидите адрес вида 240.0.0.1, смело говорите, что это адрес E класса.

Про классы обмолвились. Теперь озвучу вопрос, который мне недавно задали. Так зачем тогда маски? У нас итак хосты понимают в каком они классе. Но суть вот в чем. Например, у вас есть маленький офис, и вам нужен блок IP-адресов. Никто не будет вам выдавать все адреса класса C. А дадут только его кусок. Например 192.168.1.0 с маской 255.255.255.0. Так вот эта маска и будет определять вашу границу. Мы уже говорили, что октет варьируется в значении от 0 до 255. Вот этот 4 октет полностью в вашем распоряжении. За исключением первого адреса и последнего, то есть 0 и 255 в данном случае. Первый адрес — это адрес сети (в данном случае 192.168.1.0), а последний адрес — широковещательный адрес (192.168.1.255). Напомню, что широковещательный адрес используется в том случае, когда надо передать информацию всем узлам в сети. Поэтому есть правило. Если вам надо узнать номер сети, то все биты относящиеся к хосту обращаете в 0, а если широковещательный, то все биты — в 1. Поэтому, если из 256 адресов забирается 2 адреса, то на назначение хостам остается 254 адреса (256 — 2). На собеседованиях и экзаменах часто любят спрашивать: «Количество IP-адресов в сети?» и «Сколько доступных IP-адресов в сети для назначения хостам?». Два разных вопроса, которые могут поставить в тупик. Ответом на первый будет — все адреса, включая адрес сети и широковещательный адрес, а на второй вопрос — все адреса, кроме адреса сети и широковещательного адреса.

Теперь углубимся в изучении маски.

Я записал адрес класса C 192.168.1.1 с маской 255.255.255.0 в десятичном и двоичном формате. Обратите внимание на то, как выглядит IP-адрес и маска в двоичном формате. Если в IP-адресе 0 и 1 чередуются, то в маске сначала идут 1, а потом 0. Эти биты фиксируют адрес сети и задают размер. По таблице выше можно сделать вывод, что в двоичном виде маска представлена последовательностью 24 единиц подряд. Это говорит о том, что целых 3 октета выделено под сеть, а 4 октет свободен под адресацию для хостов. Здесь ничего необычного. Это стандартная маска класса C.

Но вот в чем загвоздка. Например, в вашем офисе 100 компьютеров, и расширяться вы не планируете. Зачем плодить сеть из 250+ адресов, которые вам не нужны?! На помощь приходит разделение на подсети. Это очень удобная вещь. Объясню принцип на примере того же класса C. Как бы вы не хотели, но трогать 3 октета нельзя. Они фиксированы. Но вот 4 октет свободен под хосты, поэтому его можно трогать. Заимствуя биты из хостового куска, вы дробите сеть на n-ое количество подсетей и, соответственно, уменьшаете в ней количество адресов для хостов.

Попробуем это воплотить в реальность. Меняю маску. Заимствую первый бит из хостовой части(то есть 1-ый бит 4-ого октета выставляю в единицу). Получается следующая маска.

Данная маска делит сеть на 2 части. Если до дробления у сети было 256 адресов(от 0 до 255), то после дробления у каждого куска будет по 128 адресов(от 0 до 127 и от 128 до 255).
Теперь посмотрю, что изменится в целом с адресами.

Красным цветом я показал те биты, которые зафиксированы и не могут изменяться. То есть маска ей задает границу. Соответственно биты помеченные черным цветом определены для адресации хостов. Теперь вычислю эту границу. Чтобы определить начало, надо все свободные биты(помеченные черным цветом) обратить в ноль, а для определения конца обратить в единицы. Приступаю.

То есть в четвертом октете меняются все биты, кроме первого. Он жестко фиксирован в рамках этой сети.

Теперь посмотрим на вторую половину сети и вычислим ее адреса. Деление у нас производилось заимствованием первого бита в 4-ом октете, значит он является делителем. Первая половина сети получалась, когда этот бит принимал значение 0, а значит вторая сеть образуется, когда этот бит примет значение 1. Обращаю этот бит в 1 и посмотрю на границы.

Приведу в десятичный вид.

Соответственно .128 и .255 назначать хостам нельзя. Значит в доступности 128-2=126 адресов.
Вот таким образом можно при помощи маски управлять размером сети. Каждый заимствованный бит делит сеть на 2 части. Если откусить 1 бит от хостовой части, то поделим на 2 части (по 128 адресов), 2 бита = 4 части (по 64 адреса), 3 бита = 8 (по 32 адреса) и так далее.

Если вы рассчитали количество бит, отдаваемые под хосты, то количество доступных IP-адресов можно вычислить по формуле

В книге У. Одома по подготовке к CCNA R&S приведена хорошая формула для расчета битов, отдаваемых на подсеть и хосты:

N + S + H = 32, где N — кол-во битов сети (класс A — 8 бит, B — 16 бит, C — 24 бита), S — кол-во заимствованных битов на подсеть (это то, что мы делали выше, когда заимствовали 1 бит из хостовой части), H — кол-во бит отводимых хостам.

Внесу ясность и объясню, как и где применять эти формулы.

Возьмем пример:

Нам выдали сеть 172.16.0.0 и попросили создать 120 подсетей со 180 хостами и записать маску. Приступим.

В качестве шпаргалки, и для быстроты вычисления, я ниже подготовил таблицу степеней двойки.

Двигаемся дальше. Первое главное условие, при использовании классовой адресации — это то, что должна использоваться одна маска для всех подсетей. То есть, если у вас для одной подсети маска 255.255.255.0, то для другой подсети она не может быть 255.255.255.128.

Теперь смотрим на выданную сеть. Путем логических размышлений понимаем, что это адрес класса B. А значит его N (кол-во битов сети) = 16. Ок. Значит на хосты выделено тоже 16 бит. Вспоминаем условия задачи. Нужно создать 120 подсетей. «Откусывать» биты от сетевой части запрещено, значит кусаем от хостовой части.

Теперь нужно взять такое кол-во бит, чтобы хватило для 120 подсетей, однако оставляло достаточное кол-во под биты для хоста. Смотрим на таблицу выше. Если взять 7 бит, то получим 128. 128>120, следовательно попадаем под условие. Если возьмем 6 бит, то получим 64. 64<128, поэтому не попадаем под условие и отбрасываем этот вариант.

Ок. Выяснили, что S надо выделить не меньше 7 бит. Теперь посмотрим, что осталось под хосты.
Если N + S + H = 32 => H = 32 — (N + S) => H = 32 — (16 + 7) = 9. Смотрим на таблицу выше (или возводим 2 в 9 степень в уме) и получаем число 512. Отнимаем 2 (адрес сети и широковещательный адрес) и получаем 510 адресов. Нам нужно 180, а значит под условие мы попадаем причем с большим запасом. В таких случаях вам предоставляется право выбора. Сделать больше подсетей или хостов на подсеть. Объясняю, что это значит. У нас есть 9 бит на хосты. Если мы возьмем 8 бит, то получим число 256. 256 — 2 = 254 адреса. Этот вариант нам тоже подходит. Возьмем 7 бит. Получаем 128. Даже не отнимая 2 адреса, становится понятно, что это меньше 180 => данный вариант отбрасывается сразу. Итого получаем, что минимальное количество для подсети — 7 бит, а для хостов — 8 бит. Поэтому свободный бит можно отдать либо на подсеть, либо на хосты. Маска получается сложением N и S. В нашем случае получаем, если под подсеть отдаем 7 бит, то получаем 23. В десятичном виде маска будет выглядеть 255.255.254.0. А если отдадим под подсеть 8 бит, то получим 24 (или в десятичном виде 255.255.255.0). Иногда бывает, что под задачу существует всего одна маска. Ну и, конечно, могут быть случаи, когда маска не попадает не под какие условия. В этих случаях нужно брать сеть другого класса или доказывать заказчику, что это невозможно.

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

Задача №2

1) Записать маску для проекта: сеть 172.16.0.0. 250 подсетей и 220 хостов.
2) Записать маску для проекта: сеть 10.0.0.0. 2000 подсетей и 1500 хостов.
3) Записать маску для проекта: сеть 192.168.0.0. 4 подсети и 60 хостов.

На этом разговор про классовые сети начну закруглять и подведу итоги. Классовая адресация — это зарождение сегодняшнего интернета, и именно с нее все началось. Поэтому плюсов у нее много, и за это создателям спасибо. Но, как вы могли заметить, у нее было жесткая привязка к одной маске. За счет этого IP-адреса использовались не экономно и расточительно. А в связи с бурным ростом Интернета адресов стало не хватать, и срочно нужно было вносить изменения.

Поняли ведущие умы, что использовать классовые сети не удобно и нужно от них отказываться. Это привело к созданию бесклассовой адресации и маскам переменной длины, о чем мы ниже поговорим. Но перед этим пару слов о видах IP-адресов. Несмотря на то, что переход от классовой адресации к бесклассовой предполагал экономию IP-адресов, на деле эта проблема все равно решалась не полностью. Все упиралось в саму технологию IPv4. Объясню почему. Выше я говорил, что длина IP адреса равна 32 бита. Каждый бит может принимать значение 0 или 1, то есть два значения. Соответственно, чтобы вычислить все комбинации, надо возвести 2 в 32-ую степень. Получаем 4294967296 адресов. Если вычесть отсюда зарезервированные для специальных нужд и прочего, то останется примерно 4.2 млрд. адресов, когда на Земле проживает около 7.3 млрд. человек. Поэтому ведущие умы быстро просекли эту фишку и начали искать решение. Они решили выделить некое адресное пространство, которое будет использоваться только в пределах локальной сети и не будет использоваться в Интернете. Это разделило адреса на 2 лагеря: белые или публичные (англ. public) и серые или частные (англ. private).

Привожу диапазон адресов, которые выделены под локальные сети:

1) 10.0.0.0 — 10.255.255.255 с маской 255.0.0.0 (или кратко 10/8).
2) 172.16.0.0 — 172.31.255.255 с маской 255.240.0.0 (или кратко 172.16/12).
3) 192.168.0.0 — 192.168.255.255 (или кратко 192.168/16).

Если честно, я мало где видел применение адресации 172.16.X.X. Обычно в корпоративной среде всегда используется 10.X.X.X, а в домах/квартирах и мелких офисах 192.168.X.X.

Теперь прошу обратить внимание на очень важную вещь, которую многие путают. Не путайте классовую адресацию и диапазон частных адресов. Очень много людей наступают на эти грабли и свято верят, что диапазон частных адресов 10.0.0.0 — 10.255.255.255 — это диапазон A класса.
Разобрались, что такое частные адреса или private адреса. Но это еще не все. Есть еще список зарезервированных адресов, которые не могут светиться в Интернете. По ним написана целая документация на IETF. Привожу ссылку, где можете прочитать оригинал. Я кратко опишу часто встречающиеся.

1) 0.0.0.0/8 — диапазон адресов, используемый хостами для самоидентификации. Обычно это можно увидеть, когда хост пытается получить IP-адрес от DHCP сервера. Так как изначально у него нету IP-адреса, то в поле источника он вставляет адрес из данного диапазона.

2) 127.0.0.0/8 — loopback или localhost адреса. Это IP-адреса, используемые компьютером, чтобы обратиться к самому себе. Очень полезно для проверки работы TCP/IP. Дело в том, что независимо от наличия соединения с Интернетом или локальной сетью, адреса из этого пула должны всегда пинговаться. Если этого не происходит, значит система накрылась или накрывается медным тазом.

3) 169.254.0.0/16 — link-local address или локальные адреса. Автоматически используются хостами при отсутствии DHCP-сервера или его недоступности. Это позволяет быстро организовать локальную сеть и проверить работу узлов. Однако данный пул адресов не маршрутизируется. Следовательно, выйти в Интернет с них не получится.

4) 224.0.0.0/4 — блок адресов, зарезервированный под многоадресную рассылку или multicast. Для тех, кто хочет побольше узнать про multicast, оставляю ссылку.

Бесклассовая адресация (англ. Classless Inter-Domain Routing или CIDR). Описана была в стандарте RFC1519 в 1993 году. Она отказалась от классовых рамок и фиксированной маски. Адреса делятся только на публичные и зарезервированные, о которых написано выше. Если в классовой адресации маска нарезалась единой для всех подсетей, то в бесклассовой — у каждой подсети может быть своя маска. На теории все хорошо и красиво, но нет ничего лучше, чем практика. Поэтому перехожу к ней и объясню, как можно делить на подсети с разным количеством хостов.

В качестве шпаргалки приведу список всех возможных масок.

Представим ситуацию. Вам выдали сеть 192.168.1.0/24 и поставили следующие условия:

1) Подсеть на 10 адресов для гостей.
2) Подсеть на 42 адреса для сотрудников.
3) Подсеть на 2 адреса для соединения 2 маршрутизаторов.
4) Подсеть на 26 адресов для филиала.

Ок. Данная маска показывает, что в нашем распоряжении находятся 256 адресов. По условию эту сеть надо каким-то образом разделить на 4 подсети. Давайте попробуем. 256 очень хорошо делится на 4, давая в ответе 64. Значит один большой блок в 256 адресов можно поделить на 4 равных блока по 64 адреса в каждом. И все было бы прекрасно, но это порождает большое число пустых адресов. Для сотрудников, которым нужно 42 адреса, ладно, может в дальнейшем компания еще наймет. Но вот подсеть для маршрутизаторов, которая требует всего 2 адреса, оставит 60 пустых адресов. Да, вы можете сказать, что это private адреса, и кому дело до них. А теперь представьте, что это публичные адреса, которые маршрутизируются в Интернете. Их и так мало, а тут мы еще будем их отбрасывать. Это не дело, тем более, когда мы можем гибко управлять адресным пространством. Поэтому возвращаемся к примеру и нарежем подсети так, как нам нужно.

Итак, какие подсети должны быть нарезаны, чтобы вместились все адреса, заданные по условию?!

1) Для 10 хостов, наименьшей подсетью будет блок из 16 адресов.
2) Для 42 хостов, наименьшей подсетью будет блок из 64 адресов.
3) Для 2 хостов, наименьшей подсетью будет блок из 4 адресов.
4) Для 26 хостов, наименьшей подсетью будет блок из 32 адресов.

Я понимаю, что не все могут с первого раза в это вникнуть, и в этом нет ничего страшного. Все люди разные и по-разному воспринимают информацию. Для полноты эффекта покажу деление на картинке.

Вот у нас блок, состоящий из 256 адресов.

После деления на 4 части получается следующая картинка.

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

Как видите, в свободном доступе осталось куча адресов, которые мы в дальнейшем сможем использовать. Можно посчитать точную цифру. 256 — (64 + 32 + 16 + 4) = 140 адресов.

Вот столько адресов мы сэкономили. Двигаемся дальше и ответим на следующие вопросы:

— Какими будут сетевые и широковещательные адреса?
— Какие адреса можно будет назначить хостам?
— Как буду выглядеть маски?

Механизм деления на подсети с разной маской получил название VLSM (от англ. Variable Length Subnet Mask) или маска подсети переменной длины. Дам важный совет! Начинайте адресацию с самой большой подсети. Иначе вы можете попасть на то, что адреса начнут перекрываться. Поэтому сначала планируйте сеть на бумаге. Нарисуйте ее, изобразите в виде фигур, просчитайте вручную или на калькуляторе и только потом переходите настройке в боевых условиях.

Итак, самая большая подсеть состоит из 64 адресов. С нее и начнем. Первый пул адресов будет следующий:

Адрес подсети — 192.168.1.0.
Широковещательный адрес — 192.168.1.63.
Пул адресов для назначения хостам от 192.168.1.1 до 192.168.1.62.
Теперь выбор маски. Тут все просто. Отнимаем от целой сети нужный кусок и полученное число записываем в октет маски. То есть 256 — 64 = 192 => маска 255.255.255.192 или /26.

Дальше идет подсеть поменьше. Состоит она из 32 адресов. Если первая заканчивалась на .63, то эта будет начинаться с .64:

Адрес подсети — 192.168.1.64.
Широковещательный адрес — 192.168.1.95.
Пул адресов для назначения хостам будет от 192.168.1.65 до 192.168.1.94.
Маска: 256 — 32 = 224 => 255.255.255.224 или /27.

3-я подсеть, которая предназначена для филиала, начнет старт с .96:

Адрес подсети — 192.168.1.96.
Широковещательный адрес — 192.168.1.111.
Пул адресов для назначения хостам будет от 192.168.1.97 до 192.168.1.110.
Маска: 256 — 16 = 240 => 255.255.255.240 или /28.

Ну и для последней подсети, которая уйдет под интерфейсы, соединяющие роутеры, будет начинаться с .112:

Адрес подсети — 192.168.1.112.
Широковещательный адрес — 192.168.1.115.
Разрешенными адресами будут 192.168.1.113 и 192.168.1.114.
Маска: 256 — 4 = 252 => 255.255.255.252 или /30.

Замечу, что адрес 192.168.1.115 является последним используемым адресом. Начиная с 192.168.1.116 и до .255 свободны.

Вот таким образом, при помощи VLSM или масок переменной длины, мы экономно создали 4 подсети с нужным количеством адресов в каждой. Думаю это стоит закрепить задачкой для самостоятельного решения.

Задача №3

Разделите сеть 192.168.1.0/24 на 3 разные подсети. Найдите и запишите в каждой подсети ее адреса, широковещательный адрес, пул разрешенных к выдаче адресов и маску. Указываю требуемые размеры подсетей:

1) Подсеть на 120 адресов.
2) Подсеть на 12 адресов.
3) Подсеть на 5 адресов.

Теперь, когда вы знаете, как делить сети на подсети, самое время научиться собирать подсети в одну общую подсеть. Иначе это называется суммированием или summarization. Суммирование чаще всего используется в маршрутизации. Когда у вас в таблице маршрутизатора несколько соседних подсетей, маршрутизация которых проходит через один и тот же интерфейс или адрес. Скорее всего этот процесс лучше объяснять при разборе маршрутизации, но учитывая то, что тема маршрутизации и так большая, то я объясню процесс суммирования в этой статье. Тем более, что суммирование это сплошная математика, а в этой статье мы ею и занимаемся. Ну что же, приступлю.

Представим, что у меня компания состоящая из главного здания и корпусов. Я работаю в главном здании, а в корпусах коллеги. Хоть у меня и главное здание, но в нем всего 4 подсети:

— 192.168.0.0/24
— 192.168.1.0/24
— 192.168.2.0/24
— 192.168.3.0/24

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

Посмотрите внимательно на таблицу. Как видите, у 4 подсетей первые 22 бита одинаковые. Соответственно, если я возьму 192.168.0.0 с маской /22 или 255.255.252.0, то покрою свои 4 подсети. Но обратите внимание на 5 подсеть, которую я специально ввел. Это подсеть 192.168.4.0. 22-ой бит у нее отличается от предыдущих 4-х, а значит выше выбранное не покроет эту подсеть.
Ок. Теперь я отправлю коллегам суммированную подсеть, и, если они все правильно пропишут, то маршрутизация до моих подсетей будет работать без проблем.

Возьмем тот же пример и немного изменим условия. Нас попросили прислать суммарный маршрут для подсетей 192.168.0.0 и 192.168.1.0. Я не поленюсь и создам еще одну таблицу.

Обратите внимание, что у 2 первых подсетей одинаковые не 22 бита, а 23 бита. Это значит, что их можно просуммировать еще компактнее. В принципе работать будет и так, и так. Но как говорилось в одной рекламе: «Если нет разницы — зачем платить больше?». Поэтому старайтесь суммировать, не задевая при этом соседние подсети.

Таким образом, переводя подсети в двоичный формат и находя одинаковые биты, можно их суммировать.

Вообще суммирование полезно применять, когда надо объединить несколько подсетей, расположенных вблизи друг с другом. Это позволит сэкономить ресурсы маршрутизаторов. Однако это не всегда возможно. Просуммировать, например, подсеть 192.168.1.0 и 192.168.15.0, не захватив при этом соседние подсети, невозможно. Поэтому перед суммированием стоит подумать над ее целесообразностью. Поэтому повторюсь еще раз, что начинать какую-либо революцию надо на бумажке. Ну и для закрепления материала оставлю небольшую задачу.

Задача №4

Даны 4 подсети:

1) 10.3.128.0
2) 10.3.129.0
3) 10.3.130.0
4) 10.3.131.0

Просуммируйте подсети и найдите маску, которая сможет покрыть их, не задевая при этом соседние подсети.

Пришло время закругляться. Статья получилась не очень длинной. Я бы даже сказал наоборот. Но все, что требует знать Cisco про IPv4, мы рассмотрели. Самое главное, что требуется от вас — это научиться работать с адресами и масками и уметь конвертировать их из десятичной в двоичную и обратно. Ну и, конечно, правильно делить на подсети и распределять адресное пространство. Спасибо, что дочитали. А если еще и задачки все сами прорешали, то цены вам нет) А если еще не прорешали, то приятного времяпровождения.

Глава 12 Широковещательная и

групповая адресация

Введение

В главе 1 мы упомянули, что

существуют три типа IP адресов: персональный

(unicast), широковещательный (broadcast) и групповой (multicast) . В этой главе мы

обсудим широковещательные и групповые адреса

более подробно.

Широковещательные и групповые запросы

применимы только к UDP, подобные типы запросов

позволяют приложению послать одно сообщение

нескольким получателям. TCP — протокол,

ориентированный на соединение, с его помощью

устанавливается соединение между двумя хостами

(по указанному IP адресу) с использованием одного

процесса на каждом хосте (который

идентифицируется по номеру порта).

Представьте себе несколько хостов в Ethernet

сети. Каждый Ethernet фрейм содержит Ethernet адрес

источника и назначения (48 бит). И обычно каждый

фрейм предназначается одному получателю. Адрес

назначения, указывающий на один интерфейс, —

называется персональным (unicast). Остальные хосты,

присутствующие на кабеле, не участвуют в общении

между двумя хостами (если не учитывать то, что все

хосты находятся все-таки на одном кабеле).

Однако иногда возникает необходимость

послать фрейм всем хостам, находящимся на кабеле,

— это называется широковещательной рассылкой

(broadcast). Мы видели это, когда рассматривали ARP и RARP.

Групповая адресация логически находится между

персональной и широковещательной: фрейм должен

быть доставлен определенному количеству хостов,

которые принадлежат к группе.

Для того чтобы понять принцип

широковещательной и групповой адресации,

необходимо отметить, что на каждом хосте

происходит фильтрация, каждый раз когда фрейм

проходит по кабелю. На рисунке 12.1 показано как

это происходит.

Во-первых, сетевая плата просматривает

каждый фрейм, который передается по кабелю, и

определяет, необходимо ли принять этот фрейм и

доставить его в драйвер устройства. Обычно

сетевая плата принимает только те фреймы, адрес

назначения которых совпадает с аппаратным

адресом интерфейса или с широковещательным

адресом. В дополнение, большинство интерфейсов

могут находиться в смешанном режиме, когда она

принимает копию каждого фрейма. Этот режим

используется, например, программой tcpdump.

Рисунок 12.1 Фильтрация, которая

осуществляется стеком протоколов, когда

принимается фрейм.

В настоящее время большинство интерфейсов

могут быть сконфигурированы таким образом, чтобы

принимать фреймы, IP адрес которых является

групповым адресом или групповым адресом

какой-либо подгруппы. В групповом адресе Ethernet

младший бит старшего байта установлен в единицу.

В шестнадцатиричном представлении этот бит

выглядит следующим образом: 01:00:00:00:00:00. (Мы можем

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

ff:ff:ff:ff:ff:ff это особый случай группового адреса

Ethernet.)

Когда сетевая плата получает фрейм, она

передает его в драйвер устройства. (Сетевая плата

может отбросить фрейм только в том случае, если

не сошлась контрольная сумма Ethernet.)

Дополнительная фильтрация осуществляется

драйвером устройства. Во-первых, тип фрейма

должен принадлежать соответствующему протоколу

(IP, ARP и так далее). Во-вторых, может быть

осуществлена дополнительная групповая

фильтрация, чтобы проверить, принадлежит ли хост

к адресуемой группе.

Затем драйвер устройства передает фрейм

следующему уровню, например, IP, если фрейм

является IP датаграммой. IP также осуществляет

фильтрацию, основанную на проверке IP адресов

источника и назначения, и, в свою очередь,

передает датаграмму следующему уровню (например

TCP или UDP, если все в порядке).

Каждый раз когда UDP получает датаграмму от

IP, он осуществляет фильтрацию, основанную на

номере порта назначения, а иногда и на номере

порта источника. Если указанный порт не

обслуживается в текущий момент каким-либо

процессом, датаграмма отбрасывается, и

генерируется ICMP сообщение о

недоступности порта. (TCP осуществляет подобную

фильтрацию, основанную на своих номерах портов.) Если в UDP датаграмме обнаружена ошибка

контрольной суммы, UDP молча ее отбрасывает.

Проблема широковещательных запросов

заключается в том, что хосты, которые совсем не

заинтересованы в получении этих запросов, должны

их обрабатывать. Представьте себе приложение,

которое должно обрабатывать широковещательные

запросы UDP. Если на кабеле находится 50 хостов, но

только из них 20 участвуют в работе этого

приложения, в каждый момент времени один из 20

посылает широковещательный запрос UDP, при этом

остальные 30 хостов должны обработать этот

запрос, который проходит весь путь по стеку

протоколов до UDP уровня, прежде чем датаграмма

будет отброшена. UDP датаграмма отбрасывается

этими 30-ю хостами, потому что порта назначения не

обслуживается каким-либо процессом.

Основная задача групповых запросов —

уменьшить загрузку хостов, не учавствующих в

работе определенного приложения. Хост может

принадлежать к одной или нескольким группам.

Если это возможно, сетевая плата сообщает, к

какой группе принадлежит хост, после чего

сетевой платой принимаются только фреймы

определенной группы.

Широковещательные запросы

На рисунке 3.9 показаны

четыре различные формы широковещательных

адресов IP. Сейчас мы опишем их более подробно.

Ограниченный широковещательный запрос

Ограниченный

широковещательный адрес (limited broadcast address) — это

адрес 255.255.255.255. Он может быть использован в

качестве адреса назначения для IP датаграмм в

процессе конфигурации хоста, когда хост может не

знать собственной маски подсети и даже своего IP

адреса.

Датаграмма, направляющаяся на ограниченный

широковещательный адрес, никогда (ни при каких

условиях) не будет перенаправлена

маршрутизатором. Она может существовать только

на локальном кабеле.

Но тут возникает вопрос, на

который практически невозможно дать ответ: если

хост имеет несколько интерфейсов и процесс

посылает датаграмму с ограниченным

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

быть отправлена на каждый подсоединенный

интерфейс, который поддерживает

широковещательную адресацию? Если нет, то

приложение, которое хочет разослать

широковещательный запрос на все интерфейсы,

должно само определить все интерфейсы хоста,

которые поддерживают широковещательную

адресацию, и послать копию на каждый интерфейс.

Большинство BSD систем воспринимают 255.255.255.255

как адрес широковещательного адреса первого

интерфейса, который был сконфигурирован, и не

позволяют послать датаграмму на все

подключенные интерфейсы, поддерживающие

широковещательную адресацию. И действительно,

два приложения, которые посылают UDP датаграммы на

каждый интерфейс, это routed (глава 10,

раздел «Демоны маршрутизации в

Unix») и rwhod (сервер BSD клиента rwho). Оба этих приложения проходят через

похожую процедуру запуска, чтобы определить все

интерфейсы хоста и те, которые поддерживают

широковещательную адресацию. Широковещательный

адрес сети, соответствующий этому интерфейсу

затем используется как адрес назначения для

датаграмм, которые посылаются в этот интерфейс.

Требования к хостам Host Requirements RFC не определяют, должен ли

хост, имеющий несколько интерфейсов, посылать

ограниченный broadcast на все свои интерфейсы.

Широковещательный запрос в сеть

В широковещательном адресе сети (net-directed

broadcast) идентификатор хоста устанавливается во

все единичные биты. Широковещательный адрес для

сети класса А, имеет вид netid.255.255.255, где netid это

идентификатор сети класса А.

Маршрутизаторы должны перенаправлять

широковещательные запросы, направляемые в сеть,

однако должна присутствовать опция, позволяющая

отключить это перенаправление.

Широковещательный запрос в подсеть

Широковещательный адрес подсети (subnet-directed

broadcast address) имеет идентификатор хоста,

установленный в единицы, однако определенный

идентификатор подсети. Для того, чтобы

классифицировать адрес как широковещательный

адрес подсети, необходимо знать маску подсети.

Например, если маршрутизатор получил датаграмму,

с адресом назначения 128.1.2.255, можно считать, что

это широковещательный запрос, направленный в

подсеть, если сеть класса В 128.1 имеет маску

подсети 255.255.255.0, однако это не широковещательный

запрос, если маска подсети 255.255.254.0 (0xfffffe00).

Широковещательный запрос,

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

Широковещательный адрес всех подсетей

(all-subnets-directed broadcast address), также требует знания

маски подсети в сети назначения. Только в этом

случае можно определить различие между

широковещательным адресом всех подсетей и

широковещательным адресом сети. И идентификатор

подсети, и идентификатор хоста, в данном случае,

устанавливаются в единицы. Например, если маска

подсети назначения 255.255.255.0, то IP адрес 128.1.255.255 это

широковещательный запрос, направленный во все

подсети. Однако, если сеть не разбита на подсети,

это широковещательный запрос, направляемый в

сеть.

В настоящее время такой тип

широковещательных запросов считается

устаревшим [Almquist 1993]. В настоящее время

используются групповые запросы, а не

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

подсети.

[Almquist 1993]

отмечает, что в RFC 922 требуется, чтобы

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

подсети, посылались во все подсети, однако не все

маршрутизаторы это поддерживают. И это хорошо,

так как неверно сконфигурированый хост, без

собственной маски подсети, будет посылать эти

«локальные» широковещательные запросы во

все подсети. Например, если хост с IP адресом 128.1.2.3

не имеет установленной маски подсети, его

широковещательный адрес по умолчанию

устанавливается в 128.1.255.255. Однако, если маска

подсети должна быть определена как 255.255.255.0, то

широковещательные запросы от неправильно

сконфигурированного хоста появятся во всех

подсетях.

Первая широкораспространенная

реализация TCP/IP, в системе 4.2BSD (1983 год),

использовала для широковещательных адресов

идентификатор хоста, установленного во все нули.

Один из самых ранних примеров обращения к

широковещательным IP адресам это IEN 212 [Gurwitz

and Hinden 1982], и именно здесь было определено

использовать широковещательные IP адреса с

идентификаторами хостов, установленными во все

единицы. (IEN это Internet Experiment Notes,

непосредственный предшественник RFC.) В RFC 894 [Hornig 1984] говорится, что 4.2BSD использует

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

RFC 906 [Finlayson 1984] замечается, что тогда

не существовало стандарта Internet для

широковещательных адресов. При редакции RFC была

сделана сноска на RFC 906, где говорилось об

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

адреса, однако очень рекомендовалось

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

идентификаторами хоста, установленными во все

единицы. К тому же, Berkeley начал использовать все

единичные биты для широковещательного адреса,

начиная с 4.3BSD (1986 год), однако

некоторые операционные системы (и что интересно,

даже SunOS 4.x) продолжали

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

адреса до начала 90-х.

Примеры широковещательных запросов

Как рассылаются широковещательные запросы

и что делают маршрутизаторы и хосты с этими

запросами? К сожалению, на этот вопрос очень

сложно ответить, потому что это зависит от типа

широковещательного адреса, приложения,

реализации TCP/IP и возможной конфигурации.

Во-первых, приложение должно поддерживать

широковещательные запросы. Если мы запустим

sun % ping 255.255.255.255

/usr/etc/ping: unknown host 255.255.255.255

то есть постараемся послать запрос на

локальный кабель, это не сработает. Однако

проблема здесь заключена в самом приложении (ping).

Большинство приложений, которые воспринимают

как цифровые IP адреса (в десятичном выражении),

так и имена хостов, вызывают функцию inet_addr

(3), чтобы конвертировать строку чисел в 32-битный

двоичный IP адрес, и если это не удалось,

воспринимают строку символов как имя хоста. Эта

библиотечная функция возвращает код ошибки -1

если в строке обнаружен символ, отличный от цифры

или десятичной точки, в случае ограниченного

широковещательного адреса (255.255.255.255) также

выдается код -1. Большинство программ, которые

воспринимают символьную строку как имя хоста,

обрабатывают его с использованием DNS (глава

14) и ограничиваются выводом ошибки, такой как

«неизвестный хост» (unknown host).

Даже если мы исправим эту ошибку в

программе ping, результаты будут все

равно не такими как хотелось бы. Из шести

протестированных систем, только одна

генерировала широковещательные пакеты в

локальный кабель. Большинство ищут IP адрес

255.255.255.255 в таблице маршрутизации, в конце концов

находят маршрут по умолчанию и посылают

персональный пакет на маршрутизатор по

умолчанию. Естественно, такой пакет

уничтожается.

В подобном случае необходимо использовать

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

подсеть. И действительно, в разделе «ICMP запрос и отклик маски

адреса» главы 6 мы посылали датаграммы на IP

адрес 140.252.13.63 для нижнего Ethernet в нашей тестовой

сети и получали отклики от всех хостов Ethernet. Широковещательный адрес, направленный

в подсеть, соответствует каждому интерфейсу,

именно этот адрес используется командой ifconfig (глава 3, раздел «Команда

ifconfig»). Если мы пошлем ping на этот адрес,

результат будет таким, как мы хотели:

IP определяет, что адрес назначения (140.252.13.63)

— это широковещательный адрес, направленный в

подсеть, и посылает датаграммы на

широковещательный адрес канального уровня.

Мы упоминали в разделе «ICMP

запрос и отклик маски адреса» главы 6, что

этот тип широковещательных запросов означает

обращение ко всем хостам локальной сети, включая

отправителя. Из примера видно, что мы получили

отклик от отправляющего хоста sun и от всех

остальных хостов, находящихся на кабеле.

В этом примере показан ARP кэш перед и после

того, как был запущен ping на широковещательный

адрес. Это сделано для того, чтобы показать

взаимосвязь между рассылкой широковещательных

запросов и состоянием ARP. ARP кэш пуст перед

запуском ping, и заполнен по окончании. (В кэше

находится по одной записи на каждый хост,

находящийся на кабеле и ответивший на эхо

запрос.) Как заполнился кэш, раз мы сказали, что

Ethernet фрейм посылается на широковещательный

адрес канального уровня 0xffffffff? Отправка этих

фреймов хостом sun не требует ARP.

Если мы посмотрим работу ping с

использованием tcpdump, то увидим, что

получатели широковещательных фреймов

генерируют ARP запрос на sun, перед тем как

отправить отклик. Причем, надо отметить, что

каждый отклик персональный. Мы говорили в

разделе «Примеры ARP» главы

4, что получатель ARP запроса (sun в данном примере)

обычно добавляет IP адрес и аппаратный адрес

запрашивающего в свой ARP кэш, и отправляет ARP

отклик. Это делается из предположения, что если

запрашивающий послал нам пакет, мы, возможно, в

будущем захотим послать что-нибудь и ему.

Использование ping — это особый случай, потому

что подобный тип программного интерфейса,

(который в большинстве Unix реализаций называется

«символьный сокет» (raw socket)), всегда позволяет

послать датаграмму на широковещательный адрес.

Что если мы воспользуемся приложением, которое

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

например, TFTP? (Мы опишем TFTP более

подробно в главе 15.)

bsdi % tftp

                         запускаем

клиента

tftp> connect 140.252.13.63

         указываем IP адрес

сервера

tftp> get temp.foo

                  и

пытаемся получить файл с сервера

tftp: sendto: Permission denied

tftp> quit

                          прекращение

работы клиента

Здесь мы получаем ошибку мгновенно, при

этом в кабель ничего не посылается. Это

объясняется тем, что сокеты API не

позволяют процессу отправлять UDP датаграммы на

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

специально не заявил, что он планирует

использовать широковещательные запросы. Это

сделано для того, чтобы предотвратить ошибочное

указание широковещательного адреса

пользователем (именно так, как поступили мы в

данном случае), тогда как приложение не

предназначено для рассылки широковещательных

запросов.

Для сокет API, приложение

должно установить опцию сокет SO_BROADCAST

перед отправкой UDP датаграммы на

широковещательный адрес. Однако, не все системы

применяют это ограничение. Некоторые реализации

позволяют любому процессу отправлять UDP

датаграммы широковещательным образом, причем не

требуют от процесса, чтобы он объявлял об этом.

Другие имеют более строгие ограничения и

требуют, чтобы процесс имел привилегии

суперпользователя, чтобы использовать

широковещательную рассылку.

Следующий вопрос заключается в том,

перенаправляются ли широковещательные пакеты.

Некоторые ядра и маршрутизаторы имеют опцию,

которая позволяет включить или выключить эту

характеристику. (См. приложение Е.)

Если мы включим характеристику

перенаправления широковещательных пакетов на

маршрутизаторе bsdi и запустим ping с хоста slip, то

увидим, что bsdi перенаправляет широковещательные

запросы, направленные в подсеть. Перенаправление

направленных широковещательных запросов

означает, что маршрутизатор воспринимает

входящие датаграммы как персональные,

определяет, что адрес назначения это

направленный широковещательный адрес одного из

его интерфейсов, и затем перенаправляет

датаграммы в соответствующую сеть, используя

широковещательный адрес канального уровня.

Мы видим, что это работает. Также мы видим,

что программа ping в BSD проверяет отслеживает

повторные номера последовательности и помечает

их как DUP!. Это обычно означает, что пакет был

каким-либо образом продублирован, однако здесь

именно это и должно было произойти, так как

запросы были отправлены на широковещательный

адрес.

Этот тест можно запустить с более

удаленного хоста (от той сети, к которой

направляется широковещательный запрос). Мы

запустили ping с хоста vangogh.cs.berkeley.edu (который

находится на расстоянии 14 пересылок от нашей

сети), и это также будет работать, если

маршрутизатор sun сконфигурирован таким образом,

чтобы перенаправлять направленные

широковещательные запросы. В данном случае IP

датаграммы (переносящие ICMP эхо

запросы) перенаправляются каждым

маршрутизатором, встречающимся им на пути, как

обычные датаграммы. Никто из них не знает, что в

действительности это направленные

широковещательные запросы. И последний

маршрутизатор, netb, думает, что пакеты

предназначены хосту с идентификатором равным 63,

и перенаправляет их на sun. В этом месте sun

определяет, что IP адрес назначения в

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

подключенного интерфейса, и передает датаграммы

в виде широковещательных запросов канального

уровня для этой сети.

Рассылка широковещательных запросов это

характеристика, которую необходимо использовать

с очень большой осторожностью. В большинстве

случаев групповая адресация IP предоставляет

лучшее решение практически всех проблем.

Рассылка групповых сообщений

Рассылка групповых сообщений IP

предоставляет приложениям два сервиса.

1. Доставка к нескольким пунктам назначения.

   Существует множество приложений, которые

   доставляют информацию нескольким адресатам,

   например, диалоговые конференции,

   распространение почты или новостей. Если

   групповая адресация не используется, эти типы

   сервисов вынуждены использовать TCP (при этом

   осуществляется доставка отдельной копии на

   каждый пункт назначения). Даже при существовании

   групповой формы сообщений, некоторые приложения

   все-таки используют TCP из-за его надежности.

2. Запрос от клиента к серверу. Например,

   бездисковая рабочая станция старается

   определить положение сервера загрузки. В

   настоящее время это осуществляется с

   использованием широковещательных запросов (как

   мы увидим в случае с BOOTP в главе 16),

   однако решение с использованием групповых

   запросов может уменьшить загруженность хостов,

   которые не предоставляют этот сервис.

В этом разделе мы рассмотрим групповые

адреса, а в следующей главе

рассмотрим протоколы, которые используют

групповую адресацию хостов и маршрутизаторов

(IGMP).

Адреса групп

На рисунке 12.2 показан формат IP

адреса класса D.

Рисунок 12.2 Формат IP

адреса класса D.

В отличие от трех других классов IP адресов

(A,B и C), форматы которых приведены на рисунке 1.5, 28 бит, отведенные под

групповой идентификатор, не подвергаются

дальнейшему делению.

Групповой адрес (multicast group address)

состоит из четырех старших бит, установленных в

1110, и идентификатора группы. В десятичном виде

групповые адреса находятся в диапазоне от 224.0.0.0

до 239.255.255.255.

Некоторое количество хостов,

просматривающих определенный групповой IP адрес,

называется группой хостов (host group).

Группа хостов может объединять хосты в разных

сетях. Членство в группе динамическое — хост

может вступать в группу и выходить из группы по

собственному желанию. Не существует ограничений

на количество хостов в группе, и хост не должен

принадлежать к группе, чтобы послать сообщение в

эту группу.

Некоторые адреса групп назначаются как

заранее известные адреса от IANA (Internet

Assigned Numbers Authority). В этом случае группа считается постоянной группой хостов (permanent host

group). Заранее известные групповые адреса

приведены в последних RFC назначенных номеров (Assigned Numbers RFC). Обратите внимание на то,

что постоянным в данном случае является

групповой адрес, а не членство в группе.

Например, 224.0.0.1 означает «все системы в

этой подсети», а 224.0.0.2 означает «все

маршрутизаторы в этой подсети». Групповой

адрес 224.0.1.1 предназначен для сетевого протокола

времени (NTP — Network Time Protocol), 224.0.0.9 для RIP-2 (глава 10, раздел «RIP

Version 2») и 224.0.1.2 для SGI (Silicon Graphics) dogfight

приложений.

Преобразование групповых адресов в

адреса Ethernet

IANA владеет блоком Ethernet адресов, которые в

шестнадцатиричном представлении выглядят как

00:00:5e. Это старшие 24 бита Ethernet адреса, означающие,

что блок включает адреса в диапазоне от 00:00:5e:00:00:00

до 00:00:5e:ff:ff:ff. IANA отвела половину этого блока для

групповых адресов. Установлено правило, что

первый байт Ethernet адреса равный 01 указывает на

групповой адрес. Это означает, что Ethernet адреса,

соответствующие групповым адресам IP, должны

находиться в диапазоне от 01:00:5e:00:00:00 до 01:00:5e:7f:ff:ff.

Приведенные здесь

выражения используют стандартную

последовательность битов для Internet, для сетей CSMA/CD или Token bus, а именно такую, как биты

располагаются в памяти. Это как раз то, с чем

сталкивается большинство программистов и

системных администраторов. IEEE

документация использует порядок бит, который

используется при передаче. Assigned Numbers RFC

предоставляет дополнительные подробности о

различиях между этими представлениями.

Подобное расположение позволяет 23 битам в

Ethernet адресе соответствовать идентификатору

группы IP. В процессе преобразования адресов 23

младших бита идентификатора группы помещаются в

23 бита Ethernet адреса. (См. рисунок 12.3.)

Старшие 5 бит в идентификаторе группы

игнорируются, так как они не уникальны. Каждому

Ethernet адресу соответствует 32 различных

идентификатора группы. Например, групповой адрес

224.128.64.32 (в шестнадцатиричном представлении

e0.80.40.20) и 224.0.64.32 (в шестнадцатиричном

представлении e0.00.40.20) оба будут трансформированы

в Ethernet адрес 01:00:5e:00:40:20.

Так как подобное сопоставление не

уникально, предполагается, что драйвер

устройства или IP модуль на рисунке 12.1 должен

осуществить фильтрацию, так как сетевая плата

может получить групповой фрейм, который хосту не

предназначен. Если сетевая плата не осуществляет

адекватную фильтрацию групповых фреймов,

драйвер устройства, вполне возможно, должен

будет получать все групповые фреймы и сам

осуществлять фильтрацию.

Рисунок 12.3 Соответствие между IP

адресами класса D и групповыми адресами Ethernet.

Существует два

варианта реализации групповой адресации в

сетевых платах, использующиеся в локальных

сетях. Одни осуществляют групповую фильтрацию,

основанную на значении аппаратного группового

адреса, что означает, что некоторые

нежелательные фреймы могут пройти. В другом

случае имеется небольшое фиксированное

количество групповых адресов, принимаемых

платой, при этом, если хосту необходимо принять

больше групповых адресов, чем поддерживается,

интерфейс должен быть помещен в режим «разных

групп» (multicast promiscuous). Однако, оба типа

интерфейсов все еще требуют, чтобы драйвер

устройства осуществлял проверку на предмет того,

необходимо ли дальше обрабатывать принятый

фрейм. Даже если интерфейс осуществляет

идеальную групповую фильтрацию (основанную на

48-битном аппаратном адресе) фильтрация все еще

необходима, так как сопоставление IP

адресов класса D и 48-битных аппаратных адресов

осуществляется не один к одному. Однако, если

абстрагироваться от несовершенства

преобразования адресов и аппаратной фильтрации,

групповая адресация все же лучше, чем

широковещательная.

Осуществить групповой запрос в

единственную физическую сеть довольно просто.

Отправляющий процесс указывает IP адрес

назначения, который является групповым адресом,

драйвер устройства конвертирует это в

соответствующий Ethernet адрес и отправляет.

Принимающие процессы должены указать своим IP

модулям, что они хочет получать датаграммы,

предназначенные определенному групповому

адресу, и драйвера устройств должен каким-либо

образом получать эти групповые фреймы. Все это

называется «вступлением в группу». (Причина,

по которой мы использовали выражение

«принимающие процессы» во множественном

числе, объясняется тем, что обычно существует

несколько получателей, которым предназначено

групповое сообщение, либо на одном, либо на

разных хостах.) Когда групповая датаграмма

получена хостом, копия доставляется всем

процессам, которые принадлежат к группе. Это

отличается от UDP, где единственный процесс

получает входящую персональную UDP датаграмму.

Несколько процессов на одном хосте могут

принадлежать к одной группе.

Однако сложности растут как снежный ком,

когда группа распространяется на несколько

сетей, и групповые пакеты должны проходить через

маршрутизаторы. Маршрутизаторам необходимо

знать, принадлежат ли какие-либо хосты в данной

физической сети к определенной группе. Для

определения этого, существует протокол,

называемый протоколом группового управления

Internet (IGMP — Internet Group Management Protocol). Этому протоколу

полностью посвящена следующая

глава.

Широковещательные запросы в сетях FDDI и Token Ring

Сети FDDI используют ту же схему

преобразования между IP адресами класса D и

48-битными FDDI адресами [Katz 1990]. Сети Token ring обычно используют отличную

систему сопоставления из-за ограничений, которые

накладываются на большинство управляющих

устройств Token ring [Pusateri 1993].

Краткие выводы

Широковещательная рассылка используется

при отправке пакетов всем хостам в сети (обычно

это локально подключенная сеть), а групповые

сообщения используются для отправки пакетов

определенному количеству хостов в сети. В этих

концепциях используются различные типы

фильтрации, которая осуществляется, когда

принятый фрейм проходит по стеку протоколов.

Каждый уровень может отбросить принятый пакет по

различным причинам.

Существуют четыре типа широковещательных

адресов: ограниченный, широковещательный адрес

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

подсетей. Наиболее распространенный — широковещательный

адрес подсети. Ограниченный широковещательный

адрес обычно используется системой только в

случае загрузки из сети.

Проблемы возникают, когда делается попытка

послать широковещательный запрос через

маршрутизаторы, чаще всего из-за того, что

маршрутизатор не знает маску подсети в сети

назначения. Результат зависит от того, какого

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

конфигурации и так далее.

IP адреса класса D называются

групповыми адресами. Они преобразовываются в

адреса Ethernet путем помещения их 23 младших битов в

фиксированный Ethernet адрес. Подобное

сопоставление не является уникальным, поэтому

требуется дополнительная фильтрация одним из

протоколов.

Упражнения

1. Увеличивается ли сетевой

   траффик (загрузка сети) в случае

   широковещательных запросов?

2. Представьте 50 хостов в Ethernet: 20 запускают TCP/IP, а 30

   используют какое-либо другое семейство

   протоколов. Как широковещательные запросы от

   одного семейства протоколов обрабатываются

   хостами, использующими другое семейство

   протоколов?

3. Вы зашли терминалом на Unix систему, с которой

   раньше никогда не работали, и хотите найти

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

   для всех подключенных интерфейсов, которые

   поддерживают широковещательные сообщения. Как

   это можно сделать?

4. Если Вы запустили ping на

   широковещательный адрес с большим размером

   пакетов, как в примере:

   sun %

   ping 140.252.13.63 1472

   PING 140.252.13.63: 1472 data bytes

   1480 bytes from sun (140.252.13.33): icmp_seq=0. time=6. ms

   1480 bytes from svr4 (140.252.13.34): icmp_seq=0. time=84. ms

   1480 bytes from bsdi (140.252.13.35): icmp_seq=0. time=128. ms

   это работает, однако увеличение

   размера пакета на 1 байт приведет к следующей

   ошибке:

   sun % ping 140.252.13.63 1473

   PING 140.252.13.63: 1473 data bytes

   sendto: Message too long 

   Что произошло?

5. Повторите упражнение 6 главы

   10, представив себе 8 RIP сообщений, направляемых с

   помощью групповой адресации вместо

   широковещательной (представьте, что

   используется RIP Version 2). Что изменится?