как выглядит широковещательный адрес
Широковещательный адрес
Широковещательный адрес — условный (не присвоенный никакому устройству в сети) адрес, который используется для передачи широковещательных пакетов в компьютерных сетях.
Содержание
Виды широковещательных адресов
В зависимости от уровня модели OSI различают несколько видов широковещательных адресов.
На уровне L2 используется широковещательный MAC-адрес FF:FF:FF:FF:FF:FF для передачи служебных датаграмм (например, ARP-запросов). Датаграммы, отправленные на такой адрес, принимаются всеми сетевыми устройствами локальной сети.
Классы широковещательных адресов в IP сетях
Различают такие применения широковещательных адресов:
Адрес в локальном сегменте IP сети Используется для передачи широковещательных пакетов всем устройствам в локальном сегменте сети. Все устройства в сети должны интерпретировать широковещательный адрес как свой собственный. Такое использование позволяет, в частности, находить шлюзы без статически заданных таблиц, а также сервера имён, времени и т. п. Адрес в удалённом сегменте IP сети Иногда используется для передачи широковещательных пакетов за пределы локального сегмента сети, например для поиска последней версии базы данных имён хостов, мониторинга серверов времени. Работает аналогично адресу в локальном сегменте IP сети, пакет маршрутизируется как обычный, пока не попадает на шлюз, подключённый к подсети, в которой адрес получателя является широковещательным. Широковещательный адрес на весь Интернет Использование такого адреса, естественно, крайне нежелательно.
Широковещательные адреса и безопасность сети
К использованию передачи пакетов на широковещательные адреса (англ. broadcasting ) следует относиться с предельной осторожностью. Некорректное использование может привести к нарушению работоспособности как отдельного сегмента, так и сети в целом (см. широковещательный шторм).
Исходя из соображений безопасности и обеспечения максимальной пропускной способности сети, на шлюзах может быть установлен запрет транзита пакетов на широковещательные адреса.
Примечания
Литература
Смотреть что такое «Широковещательный адрес» в других словарях:
широковещательный адрес — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN broadcast address … Справочник технического переводчика
широковещательный адрес ЛВС — Адрес, выделенный для обозначения совокупности всех станций в среде ВОС. [Е.С.Алексеев, А.А.Мячев. Англо русский толковый словарь по системотехнике ЭВМ. Москва 1993] Тематики информационные технологии в целом EN LAN broadcast address … Справочник технического переводчика
Широковещательный шторм — (англ. Broadcast storm) лавина (всплеск) широковещательных пакетов (на втором уровне модели OSI кадров). Размножение широковещательных сообщений активным сетевым оборудованием приводит к экспоненциальному росту их числа и… … Википедия
широковещательный домен — Логическая область сети, в которой возможна прямая передача данных от одного устройства к другому без помощи маршрутизаторов. Обычно коммутатор со всеми подключёнными к нему компьютерами представляет собой единый широковещательный домен. Если… … Справочник технического переводчика
Широковещательный канал — Схема широковещательной передачи Широковещательный канал, широковещание (англ. broadcasting) метод передачи данных в компьютерных и социальных сетях … Википедия
Адрес (информатика) — У этого термина существуют и другие значения, см. Адрес. Адрес символ или группа символов, которые идентифицируют регистр, отдельные части памяти или некоторые другие источники данных либо место назначения информации.[1][2] Содержание … Википедия
IP-адрес — (айпи адрес, сокращение от англ. Internet Protocol Address) сетевой адрес узла в компьютерной сети, построенной по протоколу IP. В сети Интернет требуется глобальная уникальность адреса; в случае работы в локальной сети требуется… … Википедия
Сетевой адрес — Для термина «Адрес» см. другие значения. Сетевой адрес идентификатор устройства, работающего в компьютерной сети. В локальных сетях, не имеющих сложной иерархии, все партнёры доступны друг другу и достаточно сетевого адреса в виде одного… … Википедия
Ifconfig — команда UNIX и UNIX‐подобных операционных систем. Содержание 1 Синтаксис 2 Описание 3 Семейство протоколов … Википедия
ifconfig — (сокр. interface configuration) команда UNIX и UNIX‐подобных операционных систем. Содержание 1 Синтаксис 2 Описание 3 Семейство протоколов … Википедия
Всё об IP адресах и о том, как с ними работать
Доброго времени суток, уважаемые читатели Хабра!
Не так давно я написал свою первую статью на Хабр. В моей статье была одна неприятная шероховатость, которую моментально обнаружили, понимающие в сетевом администрировании, пользователи. Шероховатость заключается в том, что я указал неверные IP адреса в лабораторной работе. Сделал это я умышленно, так как посчитал что неопытному пользователю будет легче понять тему VLAN на более простом примере IP, но, как было, совершенно справедливо, замечено пользователями, нельзя выкладывать материал с ключевой ошибкой.
В самой статье я не стал править эту ошибку, так как убрав её будет бессмысленна вся наша дискуссия в 2 дня, но решил исправить её в отдельной статье с указание проблем и пояснением всей темы.
Для начала, стоит сказать о том, что такое IP адрес.
IP-адрес — уникальный сетевой адрес узла в компьютерной сети, построенной на основе стека протоколов TCP/IP (TCP/IP – это набор интернет-протоколов, о котором мы поговорим в дальнейших статьях). IP-адрес представляет собой серию из 32 двоичных бит (единиц и нулей). Так как человек невосприимчив к большому однородному ряду чисел, такому как этот 11100010101000100010101110011110 (здесь, к слову, 32 бита информации, так как 32 числа в двоичной системе), было решено разделить ряд на четыре 8-битных байта и получилась следующая последовательность: 11100010.10100010.00101011.10011110. Это не сильно облегчило жизнь и было решение перевести данную последовательность в, привычную нам, последовательность из четырёх чисел в десятичной системе, то есть 226.162.43.158. 4 разряда также называются октетами. Данный IP адрес определяется протоколом IPv4. По такой схеме адресации можно создать более 4 миллиардов IP-адресов.
Максимальным возможным числом в любом октете будет 255 (так как в двоичной системе это 8 единиц), а минимальным – 0.
Далее давайте разберёмся с тем, что называется классом IP (именно в этом моменте в лабораторной работе была неточность).
IP-адреса делятся на 5 классов (A, B, C, D, E). A, B и C — это классы коммерческой адресации. D – для многоадресных рассылок, а класс E – для экспериментов.
Класс А: 1.0.0.0 — 126.0.0.0, маска 255.0.0.0
Класс В: 128.0.0.0 — 191.255.0.0, маска 255.255.0.0
Класс С: 192.0.0.0 — 223.255.255.0, маска 255.255.255.0
Класс D: 224.0.0.0 — 239.255.255.255, маска 255.255.255.255
Класс Е: 240.0.0.0 — 247.255.255.255, маска 255.255.255.255
Теперь о «цвете» IP. IP бывают белые и серые (или публичные и частные). Публичным IP адресом называется IP адрес, который используется для выхода в Интернет. Адреса, используемые в локальных сетях, относят к частным. Частные IP не маршрутизируются в Интернете.
Публичные адреса назначаются публичным веб-серверам для того, чтобы человек смог попасть на этот сервер, вне зависимости от его местоположения, то есть через Интернет. Например, игровые сервера являются публичными, как и сервера Хабра и многих других веб-ресурсов.
Большое отличие частных и публичных IP адресов заключается в том, что используя частный IP адрес мы можем назначить компьютеру любой номер (главное, чтобы не было совпадающих номеров), а с публичными адресами всё не так просто. Выдача публичных адресов контролируется различными организациями.
Допустим, Вы молодой сетевой инженер и хотите дать доступ к своему серверу всем пользователям Интернета. Для этого Вам нужно получить публичный IP адрес. Чтобы его получить Вы обращаетесь к своему интернет провайдеру, и он выдаёт Вам публичный IP адрес, но из рукава он его взять не может, поэтому он обращается к локальному Интернет регистратору (LIR – Local Internet Registry), который выдаёт пачку IP адресов Вашему провайдеру, а провайдер из этой пачки выдаёт Вам один адрес. Локальный Интернет регистратор не может выдать пачку адресов из неоткуда, поэтому он обращается к региональному Интернет регистратору (RIR – Regional Internet Registry). В свою очередь региональный Интернет регистратор обращается к международной некоммерческой организации IANA (Internet Assigned Numbers Authority). Контролирует действие организации IANA компания ICANN (Internet Corporation for Assigned Names and Numbers). Такой сложный процесс необходим для того, чтобы не было путаницы в публичных IP адресах.
Поскольку мы занимаемся созданием локальных вычислительных сетей (LAN — Local Area Network), мы будем пользоваться именно частными IP адресами. Для работы с ними необходимо понимать какие адреса частные, а какие нет. В таблице ниже приведены частные IP адреса, которыми мы и будем пользоваться при построении сетей.
Из вышесказанного делаем вывод, что пользоваться при создании локальной сеть следует адресами из диапазона в таблице. При использовании любых других адресов сетей, как например, 20.*.*.* или 30.*.*.* (для примера взял именно эти адреса, так как они использовались в лабе), будут большие проблемы с настройкой реальной сети.
Из таблицы частных IP адресов вы можете увидеть третий столбец, в котором написана маска подсети. Маска подсети — битовая маска, определяющая, какая часть IP-адреса узла сети относится к адресу сети, а какая — к адресу самого узла в этой сети.
У всех IP адресов есть две части сеть и узел.
Сеть – это та часть IP, которая не меняется во всей сети и все адреса устройств начинаются именно с номера сети.
Узел – это изменяющаяся часть IP. Каждое устройство имеет свой уникальный адрес в сети, он называется узлом.
Маску принято записывать двумя способами: префиксным и десятичным. Например, маска частной подсети A выглядит в десятичной записи как 255.0.0.0, но не всегда удобно пользоваться десятичной записью при составлении схемы сети. Легче записать маску как префикс, то есть /8.
Так как маска формируется добавлением слева единицы с первого октета и никак иначе, но для распознания маски нам достаточно знать количество выставленных единиц.
Таблица масок подсети
Высчитаем сколько устройств (в IP адресах — узлов) может быть в сети, где у одного компьютера адрес 172.16.13.98 /24.
172.16.13.0 – адрес сети
172.16.13.1 – адрес первого устройства в сети
172.16.13.254 – адрес последнего устройства в сети
172.16.13.255 – широковещательный IP адрес
172.16.14.0 – адрес следующей сети
Итого 254 устройства в сети
Теперь вычислим сколько устройств может быть в сети, где у одного компьютера адрес 172.16.13.98 /16.
172.16.0.0 – адрес сети
172.16.0.1 – адрес первого устройства в сети
172.16.255.254 – адрес последнего устройства в сети
172.16.255.255 – широковещательный IP адрес
172.17.0.0 – адрес следующей сети
Итого 65534 устройства в сети
В первом случае у нас получилось 254 устройства, во втором 65534, а мы заменили только номер маски.
Посмотреть различные варианты работы с масками вы можете в любом калькуляторе IP. Я рекомендую этот.
До того, как была придумана технология масок подсетей (VLSM – Variable Langhe Subnet Mask), использовались классовые сети, о которых мы говорили ранее.
Теперь стоит сказать о таких IP адресах, которые задействованы под определённые нужды.
Адрес 127.0.0.0 – 127.255.255.255 (loopback – петля на себя). Данная сеть нужна для диагностики.
169.254.0.0 – 169.254.255.255 (APIPA – Automatic Private IP Addressing). Механизм «придумывания» IP адреса. Служба APIPA генерирует IP адреса для начала работы с сетью.
Теперь, когда я объяснил тему IP, становиться ясно почему сеть, представленная в лабе, не будет работать без проблем. Этого стоит избежать, поэтому исправьте ошибки исходя из информации в этой статье.
Как вычислить сетевой и широковещательный адрес
wikiHow работает по принципу вики, а это значит, что многие наши статьи написаны несколькими авторами. При создании этой статьи над ее редактированием и улучшением работали авторы-волонтеры.
Количество просмотров этой статьи: 68 083.
Если вы собираетесь настраивать сеть, то вам нужно знать, как распределять ее. Для этого необходимо знать сетевой и широковещательный адреса сети. Следуйте шагам ниже, чтобы узнать, как вычислить эти адреса, если у вас есть IP-адрес и маска подсети.
Общее число битов Tb = 8 Число битов используемое для подсетей n = 3(так как маска подсети равна 224, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 3)
Значение последнего бита, используемого для маски подсети = Δ = 2 m = 2 5 = 32
Общее число битов = Tb = 8 Число битов используемое для подсетей = n = 2 (так как маска подсети равна 192, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 2).
Значение последнего бита, используемого для маски подсети = Δ = 2 m = 2 6 = 64
Число битов, используемое для подсетей для маски 240 = n1 = 4
(так как маска подсети равна 240, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 4)
Число битов, используемое для подсетей для маски 0 = n1 = 0
(так как маска подсети равна 0, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 0)
Число подсетей для маски 240 = 2 n1 = 2 4 = 16
Число подсетей для маски 0 = 2 n2 = 2 0 = 1
Значение последнего бита, используемого для маски подсети для маски 240 = Δ1 = 2 m1 = 2 4 = 16
Значение последнего бита, используемого для маски подсети для маски 0 = Δ2 = 2 m2 = 2 8 = 256
Для маски подсети 240, адреса будут разделены по 16, а для маски 0 их будет 256. Используя значения Δ1 и Δ2, получим 16 подсетей ниже
IP-адрес 100.5.150.34 относится к подсети 100.5.144.0 – 100.5.159.255, поэтому 100.5.144.0 — адрес сети, а — 100.5.159.255 широковещательный адрес.
| Маска подсети | 0 | 128 | 192 | 224 | 240 | 248 | 252 | 254 | 255 |
| Число битов, используемых для подсетей (n) | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
Число битов, используемое для подсетей для маски 128 = n1 = 1
(так как маска подсети равна 128, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 1)
Число битов, используемое для подсетей для маски 0 = n2 = n3 = 0
(так как маска подсети равна 0, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 0)
Число подсетей для маски 128 = 2 n1 = 2 1 = 2
Число подсетей для маски 0 = 2 n2 = 2 n3 = 2 0 = 1
Для маски подсети 128, адреса будут разделены по 128, а для маски 0 их будет 256. Используя значения Δ1 и Δ2, получим 2 подсети ниже
IP-адрес 200.222.5.100 относится к подсети 200.128.0.0 – 200.255.255.255, и поэтому 200.128.0.0 — адрес подсети, а 200.255.255.255 — широковещательный адрес.
Полезные советы для расчета сетевой IP адресации
Очень часто при настройке сети дома или в офисе возникают вопросы, связанные с расчетом сетевой адресации: как разделить выделенную сеть на подсети, какого объема сети отвести для каждого отдела, какие адреса попадают в данную сеть, какая маска у этой сети.
Быстрый расчет IP сетей
В сегодняшней статье мы постараемся отметить основные моменты для быстрого расчета IPv4 сетей. Хоть сейчас и идет постепенный переход на IPv6, все же IPv4 адресация еще долго будет в тренде и умение быстро рассчитывать IPv4 сети многим может пригодиться. Данная статья написана и оформлена совместно с моим коллегой и преподавателем сетевой академии CISCO — Кузьминым Евгением.
Все мы привыкли к отображению IP адреса в виде четырех десятичных чисел, разделенных точками (также их называют октетами, так как они формируются из 8 бит). Все мы знаем, что компьютер для расчетов использует двоичную систему счисления, поэтому для компьютера сетевой адрес, например 192.168.1.1, имеет вид:
11000000 10101000 00000001 00000001
Маска подсети в двоичном виде выглядит как последовательность единиц, а затем нулей и указывает на то, сколько первых битов IP-адреса будут относится к адресу сети (у всех компьютеров в одной сети они будут одинаковые), а остальные биты будут относится к адресу каждого узла (у всех компьютеров в одной сети они будут разные). Есть специальные адреса: адрес сети — адрес, у которого узловая часть состоит из одних нулей, и широковещательный адрес — это адрес, у которого узловая часть состоит из одних единиц. Например, маска вида 255.255.255.0 в двоичном виде выглядит:
11111111 11111111 111111111 00000000
и указывает на то, что первые 24 бита относятся к адресу сети, а последние восемь к адресу конкретного узла в этой сети. Маска сети также может быть записана, как просто число, указывающее количество первых битов, относящихся к адресу сети. В данном случае — 24.
Со стандартными маскам все легко, они имеют вид; 255.0.0.0, 255.255.0.0 и 255.255.255.0 и четко отделяют узловую часть от сетевой по границе каждого октета. Поэтому, для формировани адреса сети, октеты, у которых маска 255, мы не изменяем. а октеты у которых маска 0, превращаем в 0 (для широковещательного адреса в 255). Напимер, для адреса 192.168.25.128 с маской 255.255.0.0, адрес сети будет 192.168.0.0, а широковещательный – 192.168.255.255.
Но когда нужно разделить сети на более мелкие подсети или объединить несколько сетей в одну общую могут возникнуть сложности. Основное — это запомнить, что каждое десятичное число в адресе состоит из 8 двоичных битов, и нужно знать десятичное значение каждого бита, которое является степенью двойки.
Пример 1
Есть IP адрес 192.168.1.37/28, необходимо определить адрес сети и широковещательный адрес.
Пример 2
Есть IP адрес 192.168.1.37/255.255.255.240, необходимо определить адрес сети.
Получаем адрес сети 192.168.1.32
Пример 3
Записать маску вида 255.255.255.240 в маску вида “/x”.
Значит 255.255.255.240 = /28
Пример 4
Записать маску вида /28 в маску вида XXX.XXX.XXX.XXX
Значит маска: 255.255.255.240.
Заключение
Как я уже говорил эта статья была написана и опубликована совместно c моим коллегой Евгением Кузьминым. В будущем мы планируем продолжить писать совместные статьи связанные с сетевыми технологиями и настройкой сетевого оборудования (маршрутизаторы, коммутаторы)
Если вам нужно что-то настроить или получить консультацию по медиасерверам и системам, можете обращаться ко мне и нашей команде через форму контактов.
Как выглядит широковещательный адрес
Для того чтобы понять принцип широковещательной и групповой адресации, необходимо отметить, что на каждом хосте происходит фильтрация, каждый раз когда фрейм проходит по кабелю. На рисунке 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. Сейчас мы опишем их более подробно.
Ограниченный широковещательный запрос
Датаграмма, направляющаяся на ограниченный широковещательный адрес, никогда (ни при каких условиях) не будет перенаправлена маршрутизатором. Она может существовать только на локальном кабеле.
Но тут возникает вопрос, на который практически невозможно дать ответ: если хост имеет несколько интерфейсов и процесс посылает датаграмму с ограниченным широковещательным адресом, должна ли датаграмма быть отправлена на каждый подсоединенный интерфейс, который поддерживает широковещательную адресацию? Если нет, то приложение, которое хочет разослать широковещательный запрос на все интерфейсы, должно само определить все интерфейсы хоста, которые поддерживают широковещательную адресацию, и послать копию на каждый интерфейс.
Большинство 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 адрес 255.255.255.255 в таблице маршрутизации, в конце концов находят маршрут по умолчанию и посылают персональный пакет на маршрутизатор по умолчанию. Естественно, такой пакет уничтожается.
В подобном случае необходимо использовать широковещательные запросы, направленные в подсеть. И действительно, в разделе «ICMP запрос и отклик маски адреса» главы 6 мы посылали датаграммы на IP адрес 140.252.13.63 для нижнего Ethernet в нашей тестовой сети и получали отклики от всех хостов Ethernet. Широковещательный адрес, направленный в подсеть, соответствует каждому интерфейсу, именно этот адрес используется командой ifconfig (глава 3, раздел «Команда ifconfig»). Если мы пошлем ping на этот адрес, результат будет таким, как мы хотели:
sun % ping 140.252.13.63
PING 140.252.13.63: 56 data bytes
64 bytes from sun (140.252.13.33): icmp_seq=0. time=4. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=0. time=172. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=0. time=192. ms
64 bytes from sun (140.252.13.33): icmp_seq=1. time=1. ms
64 bytes from bsdi (140.252.13.35): icmp_seq=1. time=52. ms
64 bytes from svr4 (140.252.13.34): icmp_seq=1. time=90. ms
Мы упоминали в разделе «ICMP запрос и отклик маски адреса» главы 6, что этот тип широковещательных запросов означает обращение ко всем хостам локальной сети, включая отправителя. Из примера видно, что мы получили отклик от отправляющего хоста sun и от всех остальных хостов, находящихся на кабеле.
В этом примере показан ARP кэш перед и после того, как был запущен ping на широковещательный адрес. Это сделано для того, чтобы показать взаимосвязь между рассылкой широковещательных запросов и состоянием ARP. ARP кэш пуст перед запуском ping, и заполнен по окончании. (В кэше находится по одной записи на каждый хост, находящийся на кабеле и ответивший на эхо запрос.) Как заполнился кэш, раз мы сказали, что Ethernet фрейм посылается на широковещательный адрес канального уровня 0xffffffff? Отправка этих фреймов хостом sun не требует ARP.
Если мы посмотрим работу ping с использованием tcpdump, то увидим, что получатели широковещательных фреймов генерируют ARP запрос на sun, перед тем как отправить отклик. Причем, надо отметить, что каждый отклик персональный. Мы говорили в разделе «Примеры ARP» главы 4, что получатель ARP запроса (sun в данном примере) обычно добавляет IP адрес и аппаратный адрес запрашивающего в свой ARP кэш, и отправляет ARP отклик. Это делается из предположения, что если запрашивающий послал нам пакет, мы, возможно, в будущем захотим послать что-нибудь и ему.
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 перенаправляет широковещательные запросы, направленные в подсеть. Перенаправление направленных широковещательных запросов означает, что маршрутизатор воспринимает входящие датаграммы как персональные, определяет, что адрес назначения это направленный широковещательный адрес одного из его интерфейсов, и затем перенаправляет датаграммы в соответствующую сеть, используя широковещательный адрес канального уровня.
slip % ping 140.252.13.63
PING 140.252.13.63 (140.252.13.63): 56 data bytes
64 bytes from 140.252.13.35: icmp_seq=0 ttl=255 time=190 ms
64 bytes from 140.252.13.33: icmp_seq=0 ttl=254 time=280 ms (DUP!)
64 bytes from 140.252.13.34: icmp_seq=0 ttl=254 time=360 ms (DUP!)
64 bytes from 140.252.13.35: icmp_seq=1 ttl=255 time=190 ms
64 bytes from 140.252.13.33: icmp_seq=1 ttl=254 time=270 ms (DUP!)
64 bytes from 140.252.13.34: icmp_seq=1 ttl=254 time=360 ms (DUP!)
Мы видим, что это работает. Также мы видим, что программа ping в BSD проверяет отслеживает повторные номера последовательности и помечает их как DUP!. Это обычно означает, что пакет был каким-либо образом продублирован, однако здесь именно это и должно было произойти, так как запросы были отправлены на широковещательный адрес.
Этот тест можно запустить с более удаленного хоста (от той сети, к которой направляется широковещательный запрос). Мы запустили ping с хоста vangogh.cs.berkeley.edu (который находится на расстоянии 14 пересылок от нашей сети), и это также будет работать, если маршрутизатор sun сконфигурирован таким образом, чтобы перенаправлять направленные широковещательные запросы. В данном случае IP датаграммы (переносящие ICMP эхо запросы) перенаправляются каждым маршрутизатором, встречающимся им на пути, как обычные датаграммы. Никто из них не знает, что в действительности это направленные широковещательные запросы. И последний маршрутизатор, netb, думает, что пакеты предназначены хосту с идентификатором равным 63, и перенаправляет их на sun. В этом месте sun определяет, что IP адрес назначения в действительности это широковещательный адрес подключенного интерфейса, и передает датаграммы в виде широковещательных запросов канального уровня для этой сети.
Рассылка широковещательных запросов это характеристика, которую необходимо использовать с очень большой осторожностью. В большинстве случаев групповая адресация IP предоставляет лучшее решение практически всех проблем.
Рассылка групповых сообщений
В этом разделе мы рассмотрим групповые адреса, а в следующей главе рассмотрим протоколы, которые используют групповую адресацию хостов и маршрутизаторов (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.
Некоторые адреса групп назначаются как заранее известные адреса от IANA (Internet Assigned Numbers Authority). В этом случае группа считается постоянной группой хостов (permanent host group). Заранее известные групповые адреса приведены в последних RFC назначенных номеров ( Assigned Numbers RFC). Обратите внимание на то, что постоянным в данном случае является групповой адрес, а не членство в группе.
Преобразование групповых адресов в адреса 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 датаграмму. Несколько процессов на одном хосте могут принадлежать к одной группе.
Широковещательные запросы в сетях FDDI и Token Ring
Сети FDDI используют ту же схему преобразования между IP адресами класса D и 48-битными FDDI адресами [ Katz 1990]. Сети Token ring обычно используют отличную систему сопоставления из-за ограничений, которые накладываются на большинство управляющих устройств Token ring [ Pusateri 1993].
Широковещательная рассылка используется при отправке пакетов всем хостам в сети (обычно это локально подключенная сеть), а групповые сообщения используются для отправки пакетов определенному количеству хостов в сети. В этих концепциях используются различные типы фильтрации, которая осуществляется, когда принятый фрейм проходит по стеку протоколов. Каждый уровень может отбросить принятый пакет по различным причинам.
Проблемы возникают, когда делается попытка послать широковещательный запрос через маршрутизаторы, чаще всего из-за того, что маршрутизатор не знает маску подсети в сети назначения. Результат зависит от того, какого типа широковещательный адрес, от параметров конфигурации и так далее.
IP адреса класса D называются групповыми адресами. Они преобразовываются в адреса Ethernet путем помещения их 23 младших битов в фиксированный Ethernet адрес. Подобное сопоставление не является уникальным, поэтому требуется дополнительная фильтрация одним из протоколов.
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