Broadcast что это в ip

Broadcast что это в ip

Нужны новые клиенты? Тогда Вам рекомендуем посмотреть этот раздел нашего сайта
_____

ПРЯМОЙ ШИРОКОВЕЩАТЕЛЬНЫЙ АДРЕС (Directed Broadcast Address)

Для того чтобы отправить данные ко всем устройствам в сети, используется широковещательный адрес (broadcast address). Широковещательные IP адреса заканчиваются двоичными единицами во всей хостовой части адреса.

Для приведенной сети в примере (172.16.0.0), в которой последние 16 бит составляют поле хоста или хостовую часть адреса, широковещательным адресом, по которому будет производиться рассылка широковещательных пакетов всем устройствам в этой сети, является 172.16.255.255.

Прямой широковещательный адрес может быть маршрутизирован. Однако, эта возможность по умолчанию отключена на маршрутизаторах Cisco.

ЛОКАЛЬНЫЙ ШИРОКОВЕЩАТЕЛЬНЫЙ АДРЕС (Local Broadcast Address)

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

ЛОКАЛЬНЫЙ АДРЕС ОБРАТНОЙ СВЯЗИ (Local Loopback Address)

Локальный адрес обратной связи используется для отправки системой сообщений самой себе для тестирования. Характерным примером такого адреса является 127.0.0.1.

ИДЕНТИФИКАТОР СЕТИ (Network ID)

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

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

Идентификатор сети позволяет маршрутизатору пересылать пакеты в соответствующий сегмент сети. Идентификатор хоста помогает маршрутизатору доставлять фреймы второго уровня, инкапсулируя в пакет к определенному хосту в сети. В результате, IP адрес отображается в правильный MAC адрес, который необходим для процессов на уровне 2 на маршрутизаторе для адресации фрейма.

ИДЕНТИФИКАТОР ХОСТА (Host ID)

Каждый класс сети позволяет использовать фиксированное число адресов хостов. В сетях класса А, первый октет предназначен для адреса сети, оставляя последние три октета для использования в адресах хостов. Первый адрес хоста в каждой сети (все нули) зарезервирован как адрес сети, а последний адрес в сети (все единицы) зарезервирован для широковещательной рассылки.

Максимальное число хостов в сети класса А – 224-2 (исключая зарезервированные адрес сети и адрес широковещательной рассылки), что равно 16,777,214.

В сети класса В, первые два октета предназначены для адреса сети, оставляя последние два октета для использования в адресах хостов. Максимальное число хостов в сети класса В-2’6-2=65,534.

В сети класса С, первые три октета предназначены для адреса сети, оставляя последний октет для использования в адресах хостов. Максимальное число хостов в сети класса С -28-2=254.

Типы передачи данных

Multicast (мультикаст) – процесс отправки пакета от одного хоста к некоторой ограниченной группе хостов.

Broadcast (бродкаст) – процесс отправки пакета от одного хоста ко всем хостам в сети.
Эти 3 типа передачи данных используются для различных целей, давайте рассмотрим более подробно.

Unicast

Тип передачи данных Unicast (индивидуальный) используется для обычной передачи данных от хоста к хосту. Способ Unicast работает в клиент-серверных и пиринговых (peer-to-peer, от равного к равному) сетях.

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

Multicast и broadcast пакеты, в отличие от unicast пакетов, имеют свои собственные специальные (зарезервированные) IP адреса для использования их в заголовке пакетов в качестве пункта назначения. Из-за этого, broadcast пакеты в основном ограничены пределами локальной сети. Multicast трафик также может быть ограничен границами локальной сети, но с другой стороны также может и маршрутизироваться между сетями.

В IP сетях unicast адрес является адресом, то есть адресом конечного устройства (например, компьютера). Для типа передачи данных unicast, адреса хостов назначаются двум конечным устройствам и используются (эти адреса) как IP адрес источника и IP адрес получателя.

В течение процесса инкапсуляции передающий хост размещает свой IP адрес в заголовок unicast пакета в виде адреса источника, а ИП адрес принимающего хоста размещается в заголовке в виде адреса получателя. Используя эти два IP адреса, пакеты unicast могут передаваться через всю сеть (т.е. через все подсети).

Multicast

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

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

Multicast клиенты

Хосты, которые хотят получить определенные multicast данные, называются multicast клиентами. Multicast клиенты используют сервисы инициированные (начатые) клиентскими программами для рассылки multicast данных группам.

Каждая multicast группа представляет собой один multicast IP адрес назначения. Когда хост рассылает данные для multicast группы, хост помещает multicast IP адрес в заголовок пакета (в раздел пункта назначения).

Для multicast групп выделен специальный блок IP адресов, от 224.0.0.0 до 239.255.255.255.

Broadcast (Широковещание)

Из-за того, что тип передачи broadcast используется для отправки пакетов ко всем хостам в сети, пакеты использую специальный broadcast IP адрес. Когда хост получает пакет, в заголовке которого в качестве адреса получателя указан broadcast адрес, он обрабатывает пакет так, как будто это unicast пакет.

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

• создание карты принадлежности адресов верхнего уровня к нижним (например, какой IP адрес на конкретном устройстве со своим MAC адресом)
• запрос адреса (в качестве примера можно взять протокол ARP)
• протоколы маршрутизации обмениваются информацией о маршрутах (RIP, EIGRP, OSPF)

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

Подобным образом, когда хосту необходимо отправить информацию всем хостам в сети, он создаёт широковещательный пакет с его информацией и передаёт его в сеть.

В отличие от unicast передачи, где пакеты могут быть маршрутизированы через всю сеть, broadcast пакеты, как правило, ограничиваются локальной сетью. Это ограничение зависит от настройки маршрутизатора, который ограничивает сеть и следит за типом широковещания (broadcast).

Существует два типа broadcast передачи данных: направленное широковещание и ограниченное широковещание.

Направленный broadcast (направленное широковещание)

Направленный broadcast отправляется всем хостам какой-то конкретной сети. Этот тип широковещания удобно использовать для отправки broadcast трафика всем хостам за пределами локальной сети.

Например, хост хочет отправить пакет всем хостам в сети 172.16.5.0/24, но сам хост находится в другой сети. В данном случае хост-отправитель вложит в заголовок пакета в качестве адреса пункта назначения broadcast адрес 172.16.5.255. Хотя маршрутизаторы должны ограничивать (не передавать) направленный широковещательный трафик, их можно настроить на разрешение передачи broadcast трафика.

Ограниченный broadcast (ограниченное широковещание)

Ограниченный broadcast используется для передачи данных всем хостам в локальной сети. В такие пакеты в качестве пункта назначения вставляется IP адрес 255.255.255.255. Маршрутизаторы такой широковещательный трафик не передают. Пакеты, переданные ограниченным broadcast будут распространяться только в локальной сети. По этой причине локальные сети IP также называют широковещательным доменом (broadcast domain). Маршрутизаторы образуют границу для широковещательного домена. Без границы пакеты бы распространялись по всей сети, каждому хосту, уменьшая быстродействие сетевых устройств и забивая пропускную способность каналов связи.

Приведу пример ограниченного broadcast: хост находится внутри сети 172.16.5.0/24 и хочет передать пакет всем хостам в его сети. Используя в качестве пункта назначения IP адрес 255.255.255.255, он отправляет широковещательный пакет. Этот пакет примут и обработают все хосты только в этой локальной сети (172.16.5.0/24).

Как использовать broadcast?

Не могу понять как например отправить какой-то текст на broadcast своего роутера, как он вобше устроен.

Я пытался через telnet, netcat, ни там ни там не получилось, так-же заметил что порт надо, порт любой? Или я вобше совсем что-то не так делаю и понимаю? Может оно вобше на другом уровне работает где нету понятия порт.

Так-же хотелось бы знать как принимать все что идет по broadcast-у.

P.S: Я просто юзерь и хочу посмотреть как оно работает, прошу не судить строго). Спасибо.)

• Вопрос задан более трёх лет назад
• 9637 просмотров

7 комментариев

Простой 7 комментариев

Saboteur @saboteur_kiev Куратор тега Компьютерные сети

1. Как именно вы пытались это делать? У вас только слова — ни логов, ни примеров команд.
2. Какие устройства подключены к роутеру, как вы проверяли что ничего не работает?

Типа Программист @MegaCraZy6 Автор вопроса

Saboteur, ну пытался сделать так чтоб слушать широковещательный канал.
У меня адреса роутера 192.168.0.1, вот я и решил что тот канал на 192.168.0.255
netcat 192.168.0.255 1500

Типа Программист @MegaCraZy6 Автор вопроса
Saboteur, В итоге получил это (UNKNOWN) [192.168.0.255] 1500 (?) : Network is unreachable

Типа Программист @MegaCraZy6 Автор вопроса

Saboteur, Подключено две виртуальных машины на Линуксе, компьютер мой, и мобилка на крайняк,

Там адреса устройств 192.168.0.100, 192.168.0.101 и так далее

Saboteur @saboteur_kiev Куратор тега Компьютерные сети

попробуйте netcat с опцией -b
Отправить:
echo «Hi!» | nc -b -u 192.168.0.255 4000
Слушать:
nc -l 0.0.0.0 4000

Типа Программист @MegaCraZy6 Автор вопроса

Saboteur, В консоли того кто оправляет ничего, так-же как и в консоли того кто принимает, но ошибки нету, когда что-то ввожу в какую либо из консолей.. ничего не происходит.

П.С: сначала исполнял команду чтоб слушать.

Так-же забавно решил немного поиграться с коммандами а именно:

Отправить:
echo «Hi!» | nc -b -u 192.168.0.255 4000

Слушать:
netcat -u -l 0.0.0.0 -p 4000

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

Invalid connection to [192.168.0.105] from (UNKNOWN) [192.168.0.100] 54512

192.168.0.105 — Listener
192.168.0.100 — Sender

Вот такое вот я нашел, не понимаю почему не работае совсем никак если что на всех виртуальных машинах, и на физическом ПК стоит Debian

Saboteur @saboteur_kiev Куратор тега Компьютерные сети

похоже баг в самом nc вашей версии debian

Решения вопроса 2

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

Если интересно, какие широковещательные пакеты ходят в сети — просто посмотрите через Wireshark то, что пересылается на этот адрес.

Ответ написан более трёх лет назад
Нравится 1 1 комментарий

Типа Программист @MegaCraZy6 Автор вопроса
Нуу например просто чтоб знать как и что.

Broadcast — это вид передачи данных. Почитайте, что такое unicast, multicast — возможно тогда вы сообразите, что такое тип(метод или т.п.) передачи данных и как работает. Хотите запустить broadcast пакет — вросто включите на вашей сетевой карте получение адреса автоматически, и ваша сетевая сама отправит пакет на broadcast адрес в поисках DHCP-сервера. Т.е. broadcast — это просто отправка пакета, с абсолютно любым содержимым в качестве данных (обработка содержимого, это уже вопрос более высокого уровня, и на отправку влиять никак не будет) на широковещательный адрес сети — это последний допустимый адрес, который может быть в вашей сети. Коммутатор, просто видит, что адрес широковещательный, и распуливает этот пакет абсолютно во все дурки, в какие может — разбираться с тем, чей пакет будет уже устройство, которое не может передать пакет никуда дальше, конечный узел, к примеру комп или принтер. Устройство смотрит, что внутри, и решает ему это или нет. В случае DHCP-запроса, DHCP-сервер видит, что это его искали и отвечает. Если DHCP-сервера нет то все просто видят, что пакет не к ним, и они отбрасывают пакет. Что бы «увидеть», что и как, как и писали выше — ставите wireshark, включаете на сетевой автоматический адрес, и смотрите на пакет (не знаю правда, чем это вам поможет)) ).

Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Ответы на вопрос 0
Ваш ответ на вопрос

Войдите, чтобы написать ответ

• Компьютерные сети
• +2 ещё

Как подключиться к Windscribe с российского wifi?

• 1 подписчик
• 18 часов назад
• 59 просмотров

Курс по основам компьютерных сетей на базе оборудования Cisco. Этот курс поможет вам подготовиться к экзаменам CCENT/CCNA, так как за его основу взят курс Cisco ICND1.

4.8 Виды трафика в IP сетях: unicast, broadcast, multicast, anycast. Loopback адреса и интерфейсы

• 22.09.2018
• Cisco CCNA (ICND1 и ICND2), Компьютерные сети
• 2 комментария

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей и протокол сетевого уровня IP, а если быть более точным, то его версию IPv4. IP-адреса бывают разные и делятся не только на частные и публичные, серые и белые. В этой теме мы разберемся с видами IP-адресов и поговорим о видах трафика в IP сетях и как это все связано с IP-адресами, ведь логично предположить что для каждого вида взаимодействия используются свои IP-адреса, в IPv4 всего можно выделить три полноценных вида взаимодействия и одно костыльное. К полноценным относятся: unicast (одноадресная рассылка), multicast (многоадресная рассылка), broadcast (широковещательная рассылка). К неполноценному в IPv4 относится anycast взаимодействие (доставка ближайшему узлу из группы). А в качестве бонуса мы еще рассмотрим loopback адреса и интерфейсы.

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

4.8.1 Введение

Последняя исключительно теоретическая тема, касающаяся протокола IPv4, следующие темы будут сопровождаться небольшой практикой. Здесь нам нужно будет рассмотреть виды взаимодействия в IP сетях и соответствующие IP-адреса: unicast (одноадресная рассылка), multicast (многоадресная рассылка), broadcast (широковещательная рассылка), anycast взаимодействие (доставка ближайшему узлу из группы).

4.8.2 Виды трафика в IP

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

1. Одноадресная рассылка или unicast IP-адреса. Обычно самую большую долю трафика в компьютерной занимает одноадресная рассылка. Практически для любого взаимодействия между двумя конечными узлами используется unicast.
2. Широковещательная рассылка и broadcast IP-адреса. Суть взаимодействия понятна из названия. Если unicast можно описать как взаимодействия точка-точка, то broadcast, как точка-многоточка. Сразу стоит обратить внимание на то, что широковещательный трафик ограничен канальной средой узла, в котором он находится.
3. Многоадресная рассылка или multicast IP-адреса. Multicast адреса используется, когда нужно передать какую-то информацию не всем узлам канальной среды, а какой-то определенной группе, при этом узлы группы могут находиться в разных канальных средах. Представим, что у нас есть жилой дом на несколько подъездов и у этого дома есть доска объявлений, на которой управляющая компания информирует жильцов своего дома. Если в объявление будет написано: «всем жильцам дома», то это будет похоже на broadcast, если написано «жильцам третьего этажа» или «жильцам второго подъезда», то это будет похоже на multicast.
4. Anycast взаимодействие очень хорошо прописано и реализовано в IPv6, а вот в IPv4, решая задачи маленькой сети, вы, скорее всего, не столкнетесь с anycast. Anycast взаимодействие можно описать так: твой запрос может обработать любой из этих десяти узлов, но тебе нужно обратиться к ближайшему. Классический пример anycast взаимодействия: в Интернете есть корневые DNS-сервера, каждый корневой сервер имеет свою копию в различных точка планеты, если вы находитесь в Омске, то вам нет смысла обращаться к корневому серверу в Лондоне, поскольку такая же копия есть в Новосибирске.

Loopback интерфейсы и loopback адреса – это не отдельный вид трафик, зачем я его сюда добавил? Да просто потому что могу, а почему бы и нет, создавать отдельную тему, чтобы рассказать про loopback просто не вижу смысла. Если говорить про loopback интерфейс, то это интерфейс, которого нет физически, но есть в голове у узла или маршрутизатора, этот интерфейс будет доступен другим физическим устройствам до тех пор, пока жив хотя бы один физический интерфейс узла, на котором создан loopback. Про loopback IP-адреса мы уже говорили, когда разбирались с видами IP-адресов.

4.8.3 Одноадресная рассылка и unicast адреса

Начнем с самого просто и стандартного вида взаимодействия в компьютерной сети. Unicast или одноадресная рассылка используется для взаимодействия между двумя узлами сети. Графически unicast взаимодействие показано на Рисунке 4.8.1.

Рисунок 4.8.1 Unicast взаимодействие между двумя узлами компьютерной сети

То есть компьютер источник (красный), формируя IP-пакет в качестве IP-адреса назначения, указывает адрес конкретного узла, к которому хочет обратиться (зеленый), все остальные узлы компьютерной сети не должны получить этот пакет, поскольку им он не предназначен. Когда зеленый узел решит ответить красному, то он также в качестве IP-адреса назначения запишет unicast IP-адрес красного узла.

Вы легко можете убедиться в том, что unicast означает, что пакет пойдет одному конкретному адресату, если соберете схему, как показано на Рисунке 4.8.2, а затем выполните команду Ping от одного узла до другого в режиме симуляции.

Рисунок 4.8.2 Демонстрация использования unicast IP-адресов в Cisco Packet Tracer

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

4.8.4 Широковещательная рассылка и broadcast адреса

Тут сразу стоит напомнить о сетевых коммутаторах и их CAM таблицах, в которых ведется сопоставление портов коммутатора и мак-адресов, которые «светятся» за этими портами. У коммутаторов есть механизм unknown unicast flooding и это понятие не стоит путать с broadcast, как понятно из названия, unicast flooding реализуется при помощи unicast рассылок во все порты, в свою очередь broadcast означает отправить пакет все участникам канальной среды или подсети, проще говоря, broadcast ограничивается портом маршрутизатора. Схематично broadcast взаимодействие показано на Рисунке 4.8.3.

Рисунок 4.8.3 Broadcast взаимодействие между узлами компьютерной сети

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

Второй момент связан с неэкономным использованием времени и других ресурсов компьютерной сети. Представим себе такую ситуацию: у нас есть узел с настройками 192.168.12.45/24, этот узел хочет отправить пакет своему соседу с IP-адресом 192.168.12.230/24. Чтобы это сделать нашему узлу нужен MAC-адрес, при помощи broadcast он сформировал бы один пакет и направил бы его в сеть всем соседям по канальной среде, а сосед с IP-адресом 192.168.12.230 получил бы такой пакет и прислал бы нашему узлу информацию о своем мак-адресе. Если бы у нас не было механизма broadcast, то нашему узлу пришлось бы обращаться к каждому узлу в канальной среде по отдельности с вопросом: извините, а не у вас ли IP-адрес 192.168.12.230? Таким образом мы бы получили вместо одного пакета несколько сотен пакетов.

Как определить, что IP-адрес является широковещательным в подсети? Да мы уже про это говорили, когда разбирались с CIDR и VLSM. Вы же помните, что IP-адрес состоит из номера сети и номера узла. У широковещательного IP-адреса в номере узла будут все единицы в двоичной системе счисления. Например, возьмем нашу сеть 192.168.1.0/24, иначе маску можно записать 255.255.255.0, а это означает, что под номер узла выделен последний октет IP-адреса, то есть восемь бит, из этого следует, что широковещательным адресом в такой сети будет: 192.168.1.255, если перевести 255 в двоичную систему счисления, то получим: 11111111. Если ничего непонятно, то настоятельно рекомендую сперва ознакомиться с темами «Классовые сети» и «Маски подсети переменной длины» в том порядка, как я их указал.

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

Рисунок 4.8.4 Три канальных среды в компьютерной сети

У нас здесь три канальных среды. Не забываем о правиле, связанном с маршрутизаторами: каждый интерфейс маршрутизатора должен «смотреть» в свою канальную среду, то есть вы не сможете сделать так, чтобы первый порт маршрутизатора имел префикс 192.168.2.23/24, а второй порт имел такой префикс: 192.168.2.12/24, так как в этом случае они находятся в одной подсети. По этой причине у нас здесь не две канальных среды, а три:

1. Первая канальная среда отмечена синим и в ней ровно два участника: левый маршрутизатор с IP-адресом и маской 10.10.10.1/30 и второй: 10.10.10.2/30.
2. Вторая канальная среда отмечена зеленым и в ней у нас пять участников: четыре компьютера и основной шлюз, которым выступает интерфейс маршрутизатора, который «смотрит» в подсеть 192.168.1.0/24.
3. Третья канальная среда имеет трех участников: два ноутбука и интерфейс второго маршрутизатора.

Теперь давайте сделаем широковещательную рассылку в зеленой канальной среде и посмотрим, что из этого выйдет. Для этого откроем командную строку компьютера 192.168.1.2 и выполним команду ping на IP-адрес 192.168.1.255, который в данном случае является широковещательным, естественно, делать это нужно в режиме симуляции Cisco Packet Tracer.

Рисунок 4.8.5 Пример широковещательного запроса в канальной среде

Cisco Packet Tracer некорректно указывает IP-адрес назначения в широковещательном IP-пакете, в данном случае написано, что это 255.255.255.255, когда на самом деле должно быть: 192.168.1.255, а вот с широковещательным мак-адресом никаких проблем, он действительно: FF-FF-FF-FF-FF-FF. В этом можно убедиться, повторив ping на реальном ПК и запустив Wireshark, моя локальная подсеть 192.168.0.0/24, вот что показывает Wireshark при пинге IP-адреса 192.168.0.255.

Рисунок 4.8.6 Так выглядит широковещательный запрос в Wireshark

Здесь я выделил красным цветом IP и MAC-адреса источника и назначения. Мак-адрес при широковещательном запроса у нас: FF:FF:FF:FF:FF:FF, а вот широковещательный IP-адрес выглядит так: 192.168.0.255. Стоит сразу заметить, что тип запроса (каким он будет: широковещательным или одноадресным?) определяется узлом отправителем. Делается это при помощи маски подсети, которая задана узлу отправителю и IP-адресу назначения, то есть тому адресу, на который будет отправлен пакет.

Узел-отправитель берет свой IP-адрес, прикладывает его к маске подсети, которая ему задана, таким образом он узнает в какой подсети он находится, затем он берет IP-адрес назначения и прикладывает его к своей маске и сравнивает с результатами первой операции, давайте это посмотрим более детально. Для примера возьмем сеть 10.10.10.0/24. У нашего узла IP-адрес 10.10.10.12, а отправить он хочет пакет на адрес 10.10.10.255, то есть сделать широковещательный запрос.

Сначала узел сравнит свой адрес и маску, что понять в какой сети он находится.

Таблица 4.8.1 Узел сравнивает свой IP-адрес с маской подсети

Сделав это вычисление, он понимает, что номер его сети 10.10.10.0, а это значит, что все узлы, у которых первых три октета совпадают и равны 10, а в последнем значения меняются от 1 до 255 находятся в одной канальной среде с этим узлом. Затем наш узел возьмет IP-адрес назначения и сравнит его со своей маской.

Таблица 4.8.2 Узел сравнивает свой IP-адрес назначения с маской подсети

Компьютер видит, что номер сети в IP-адресе назначения совпадает с номером сети, в которой он находится (первых три октета), а вот номер узла не совсем обычный, в нем прописаны все единицы, а это значит, что запрос широковещательный и его нужно направить всем узлам в канальной среде! Но как это сделать? Проблема заключается в том, что маска подсети по сети не передается: ни в IP-пакете, ни тем более в Ethernet кадре нет поля для передачи маски подсети.

Как транзитные узлы поймут, что пакет/кадр являются широковещательными? Да очень просто! Помните, мы говорили, что широковещательные запросы в модели TCP/IP не выйдут за пределы канальной среды, это значит, что такие пакеты не маршрутизируются и их можно доставить от источника до отправителя, используя только мак-адреса. Теперь всё становится на свои места. Если узел отправитель видит широковещательный кадр, он в поле мак-адрес назначения Ethernet кадра подставляет широковещательный мак-адрес FF:FF:FF:FF:FF:FF. Мы же помним, что когда коммутаторы коммутируют, они не смотрят на IP-адреса, более того, простенькие коммутаторы даже не умеют этого делать, но когда коммутатор получит Ethernet кадр с адресом назначения FF:FF:FF:FF:FF:FF, он поймет, что этот кадр широковещательный и его надо разослать всем участникам канальной среды, в которой находится узел-отправитель (обратите внимание: не во все свои порты, а всем участникам канальной среды, все дело в том, что есть технология VLAN, которая позволяет разделять канальные среды на канальном уровне).

Давайте теперь посмотрим на всё это в Cisco Packet Tracer. Напомню, что наш узел сформировал широковещательное сообщение и готовится отправить его в сторону коммутатора. Пропустим тот момент, когда сообщение только пришло на коммутатор и сразу посмотрим на то, что коммутатор направит широковещательное сообщение всем участникам канальной среды.

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

Если будете повторять эту схему самостоятельно, то обратите внимание, что на роутере один пакет будет перечеркнут красным крестиком, в сущности, это будет означать, что широковещательное сообщение не уйдет дальше порта маршрутизатора, который смотрит в зеленую канальную среду. Теперь давайте посмотрим, как узлы получатели будут отвечать на широковещательный запрос.

Рисунок 4.8.8 Как отвечают узлы на широковещательный запрос

Как видим, узлы отвечают на широковещательный запрос юникастом, а зачем им отвечать при помощи broadcast, если запрос делал один конкретный узел, значит и отвечать нужно одному конкретному узлу, а не всем подряд. На рисунке показано, что сообщения на коммутаторе выстроились в очередь и ждут своей участи.

Рисунок 4.8.9 Как отвечают узлы на широковещательный запрос

По мере поступления сообщений от коммутатора к узлу, мы будем видеть изменения на экране эмулятора терминала, на рисунке выше показано, что узел 192.168.1.2 получил ответ от 192.168.1.3, но еще не получил ответа от трех других. В итоге мы должны будем увидеть, что на один широковещательный запрос, который был сформирован на узле 192.168.1.2, мы получим четыре одноадресных ответа. От всех участников нашей канальной среды.

Рисунок 4.8.10 Как отвечают узлы на широковещательный запрос

Наш узел должен будет еще три раза сделать ICMP-запросы к своим соседям, это стандартное поведение утилиты Ping, но смотреть на них нам уже не интересно. Поэтому остановимся на этом. Я отмечал, что широковещательный запрос ограничен портом маршрутизатора и это хорошо, дело всё в том, что сети, построенные на Ethernet, имеют проблему, называемую широковещательным штормом. Хорошо, что это не глобальная проблема и она ограничивается портом роутера.
Давайте лучше посмотрим на пример широковещательного запроса в коммутируемой сети, такой пример с технической точки зрения вреден, но он хорошо демонстрирует опасность широковещательных штормов, обратите внимание на Рисунок 4.8.11.

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

Здесь я даже не стал выделять границы канальных сред, поскольку их по сути и нет, представим, что два коммутатора на схеме являются неуправляемыми и они ничего не знают о технологии VLAN, а также допустим, что эти коммутаторы очень и очень мощные и способны прокоммутировать любой объем трафика, ну совершенно любой, им это не важно. А вот каналы от коммутаторов до узлов ограничены полосой пропусканию 100 Мбит/c. Теперь давайте выполним ping с узла 10.10.10.1 на широковещательный адрес его сети, то есть 10.10.10.255. Момент номер один: первый коммутатор, к которому подключен наш узел источник, разослал полученный пакет всем узла, находящимся в канальной среде вместе с нашим узлом источником, в том числе и на соседний коммутатор.

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

Вот тут вы можете сказать: но как так, Кирилл, ты же говорил, что подсеть и канальная среда – это одно и то же, а пакеты из подсети 10.10.10.0/24 направлены в подсеть 20.20.20.0/24 и даже в подсеть 30.30.30.0/24! И да, получается, что ранее я говорил не совсем правду, хотя нет, я говорил всю правду, поскольку постоянно повторял, что коммутаторы не умеют работать с IP-адресами, у них есть другой механизм по разделению на канальные среды – VLAN, но о нем позже.

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

Обратите внимание: на широковещательный запрос ответили только компьютеры, потому что только они находятся в одной подсети с узлом 10.10.10.1. Ноутбуки откинули широковещательный запрос от этого узла и этих кадров мы уже не видим на рисунке выше, а сервера в данный момент откидывают кадры (они помечаются красным крестиком на рисунке). Два сообщения, которые мы видим на первом коммутаторе были сформированы и направлены узлами 10.10.10.2 и 10.10.10.3. Все остальные участники нашей сети сравнили свои IP-адреса и маски с теми адресами, которые были указаны в IP-пакете и поняли, что этот пакет не для них и им отвечать на него не нужно.

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

Теперь о проблеме широковещательного шторма. Помним про условия: коммутатор может обработать любой объем трафика, а полоса пропускания всех каналов конечная и равна 100 Мбит/c. А теперь представим, что наш узел 10.10.10.1 сошел с ума и начал бомбардировать нашу маленькую сеточку бесконечным количеством широковещательных запросов и в конце концов дошло до того, что он начал утилизировать всю полосу 100 Мбит/c своими широковещательными запросами, что произойдет? А произойдет то, что каналы до всех узлов нашей сети будут забиты на 100% и ничего в них передаваться не будет, кроме широковещательных запросов этого узла.

Как работает broadcast? Коммутатор получает кадр, копирует его и рассылает всем участникам канальной среды. То есть все линки до ноутбуков будут забиты широковещательным трафиком, все линки до стационарных ПК будут забиты этим бесполезным трафиком и линк между двумя коммутаторами будет использоваться только под Broadcast.

Ну хорошо, скажите вы, ты нам потом расскажешь про VLAN, мы увидим, что если на коммутаторах используется VLAN, то широковещательный трафик не выйдет за пределы этого самого VLAN, а это значит, что, если сойдет с ума узел из подсети 10.10.10.0/24, то от широковещательного шторма пострадают только узлы из его подсети и никто более. Хорошо. Давайте смотреть. Только теперь давайте всё по-честному. Производительность коммутаторов не бесконечна, более того, центральный процессор коммутатора – это его самое слабое место. Когда в сети Ethernet случается широковещательный шторм или петля, то проблемы начинаются не из-за того, что «забиты» каналы, а из-за того, что коммутаторам доступа банально не хватает процессорной мощности или объема CAM таблиц, в которых ведется сопоставление порт — мак-адрес. Теперь представляем, что в одной подсети у нас не три узла, а двести узлов и делаем выводы.

4.8.5 Многоадресная рассылка и multicast адреса

Тема многоадресной рассылки или multicast трафика – это отдельный мир в IP сетях, детальное знакомство с которым не входит в программу нашего курса по компьютерным сетям для начинающих, но нам важно знать, что такой трафик бывает и нам важно понимать базовый принцип работы узлов компьютерной сети при многоадресной рассылке. Схематично она показана на Рисунке 4.8.14.

4.8.14 Multicast взаимодействие между двумя узлами компьютерной сети

В самом начале я уже приводил пример с объявлением у дома, повторять его не буду. Многоадресная рассылка, как и широковещательная, характеризуется взаимодействием точка-многоточка, но здесь есть существенное «но». Участники в таком взаимодействие могут находиться в разных канальных средах. IP-адреса multicast мы уже называли (далее повторим), но тут стоит сказать, что для реализации многоадресной рассылки можно использовать и обычные IP-адреса, было бы желание.

Подсеть	Пояснение
224.0.0.0/24	Local Network Control Block. IP-адреса из этой подсети вам лучше не использовать для своих нужд, поскольку они заняты для нужд различных протоколов, которые могут работать в вашей сети. Так, например, IP-адреса из этой подсети используют роутеры при обмене служебной информацией в протоколах OSPF или EIGRP. В RFC 3171 сказано, что узел, отправляющий пакет на адрес из данной подсети в поле TTL должен выставлять значение 1.
С 224.0.1.0 по 238.255.255.255	Это multicast IP-адреса, для которых разрешена глобальная маршрутизация, можно сравнить с публичными IP-адреса, но только для multicast трафика.
239.0.0.0/8	Эти multicast адреса может использовать кто угодно в своих локальных сетях для организации многоадресного вещания, то есть, если мы провайдер и хотим предложить своим абонентам услугу IPTV, то для этих целей у нас есть вот эта подсеть.

Детальную информацию о зарезервированных multicast адресах можно получить из RFC 5771, при необходимости вы сможете найти этот документ. Нам бы просто разобраться с механизмом. Давайте начнем. Представим, что у нас есть сеть, как показано на Рисунке ниже.

4.8.15 Схема для демонстрации Multicast взаимодействия

Схема с виду ужасная, но в реальной жизни будет хуже, поверьте. Здесь пока не указаны никакие IP-адреса, здесь просто показаны канальные среды. Вообще, мы не будем ничего настраивать, но следует заметить: для работы multicast в реальной сети, вам сперва нужно настроить unicast взаимодействие между узлами, а уже поверх unicast разворачивать свою multicast сеть. Теперь давайте представим, что мы провайдера, который хочет предоставлять своим абонентам услугу IPTV. Для этого нам нужен источник, пусть это будет сервер. У этого сервера, как минимум, должно быть два порта: один порт получает картинку от какой-нибудь спутниковой антенны, а второй порт раздает эту картинку в нашу IP-сеть. Первый порт на рисунке не показан, да и сейчас он нам не интересен.

А вот второй порт нам интересен. Он транслирует каналы в нашу сеть, второй порт обычно называют источником. Сейчас всё огрубим и будем говорить, что порт просто транслирует каналы в сеть. За каждым ТВ каналом, который в сеть транслируется, закрепляется multicast IP-адрес. Пусть наш сервер транслирует три канала:

1. Первый канал, за ним закреплен IP-адрес 239.0.1.1.
2. У второго канала будет адрес 239.0.2.1.
3. Третьему каналу провайдер назначил адрес 239.0.3.1.

Нужно учесть и то, что для трансляции одного канала требуется полоса пропускания определенной ширины, то есть на трансляцию одного канала тратится кусочек существующей полосы пропускания, пусть у нас каждый канал забирает 4 Мбит/c. Итак, у нас есть три мультикаст группы, для каждой из которых требуется по 4 Мбит/c. Представим, что все наши конечные узлы купили у провайдера услугу IPTV, но не все и не всегда что-то смотрят. Допустим компьютеры PC8, PC11 и PC17 (зеленая группа) сейчас смотрят первый канал, значит они являются подписчиками первой multicast группы или иначе – они состоят в первой группу. Ко второй группе (смотреть второй канал) у нас будут относиться PC10 и PC12 (красная группа). А третий канал у нас будут смотреть PC14 и PC15 (желтая группа).

4.8.16 Схема для демонстрации Multicast взаимодействия

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

Представим, что в нашей сети еще никто ничего не смотрит, а это значит, что сервер еще ничего не транслирует в сторону своего первого маршрутизатора. Когда пользователь PC8 осознает, что он хочет смотреть первый канал, он открывает IPTV-плеер и выбирает в нем первый канал, в этот момент компьютер осознает, что нужно послать запрос серверу о том, что он хочет быть подписчиком группы 239.0.1.1. При этом unicast связь между сервером и компьютером PC8 уже должна быть, иначе как дойдет запрос до сервера о том, что кто-то чего-то хочет смотреть.

Тогда сервер начинает транслировать первый канал в сторону маршрутизатора, пусть это будет называться потоком, но сервер не просто транслирует поток 239.0.1.1, но еще и сообщает маршрутизатору, что этот поток нужно перенаправить в сторону узла PC8 с unicast IP-адресом PC8.

Что будет, когда пользователь PC17 захочет посмотреть первый канал? Правильно, он пошлет запрос серверу о том, что хочет быть подписчиком multicast группы 239.0.1.1. При этом сервер понимает, что этот поток он уже транслирует на маршрутизатор и он просто дает указание маршрутизатору: друг, смотри, первый поток, который я тебе отдаю, нужно транслировать не только на unicast адрес PC8, но еще и на unicast адрес PC17. Маршрутизатор скажет, окей, я получаю от тебя первый поток, но теперь буду направлять его не только влево, но и вправо. При этом обратите внимание: у нас появилось два подписчика, но объем трафика между сервером и первым маршрутизатором не возрос.

Теперь у нас включается PC11 и говорит серверу: я хочу смотреть первый канал. Сервер понимает, что он уже транслирует первый канал, поэтому он говорит первому маршрутизатору: я отдаю тебе первый канал, теперь его хочет смотреть еще и узел с unicast адресом PC11. Первый маршрутизатор понимает, что он получает поток первого канала, более того, он понимает, что он уже направил этот поток в сторону PC11, поэтому он просто дает указание левому маршрутизатору: смотри, я отдаю тебе поток первого канала, но теперь тебе его нужно транслировать не только на PC8, но и на PC11. Левый маршрутизатор говорит: окей, я тебя понял, буду отдавать поток первого канала не только вверх, но и вниз.

Давайте теперь посчитаем занятую полосу пропускания. У нас есть три подписчика, которые смотрят один канал, на который требуется 4 Мбит/c. Если бы это был unicast трафик, то между сервером и первым роутером была бы утилизирована полоса в 12 Мбит/c, между левым и первым роутерами утилизировалось бы 8 Мбит/c, а между правым и первым 4 Мбит/c. Посчитать не трудно. Но у нас multicast трафик, он подразумевает, что источник просто транслирует канал, а транзитные узлы его просто копируют в те порты, откуда стучатся подписчики, то есть получатели, поэтому один канал вне зависимости от количества подписчиков в нашем случае всегда будет занимать полосу 4 Мбит/с и не битом больше.

Если вы знакомы с делителями телевизионного сигнала, который передается по коаксиальным проводам, то здесь принцип похожий: у нас есть один источник и есть транзитные узлы, которые выполняют роль делителей сигнала. Но если говорить про настоящие делители, то это пассивные устройства и деление происходит с потерями, то есть при прохождении через делитель сигнал неизбежно будет затухать. Маршрутизаторы устройства активные и они не просто делят сигнал, а создают его копию.
Не стоит воспринимать данный раздел как подробное описание работы multicast в IP-сетях. Это скорее грубый и поверхностный взгляд с большими неточностями. Так, например, клиенты не запрашивают каналы у сервера, ведь сервер просто вещает потоки, а клиенты обращаются к ближайшему маршрутизатору при помощи протокола IGMP, если между ближайшим маршрутизатором к клиенту и сервером есть еще L3 устройства, то взаимодействие между ними происходит по протоколу PIM.

4.8.6 Anycast взаимодействие или доставка ближайшему узлу из группы

Anycast трафик практически не используется в IPv4, по факту здесь этот механизм и не реализован. Но в IPv6 это упущение учли и описали как должны действовать устройства при взаимодействии anycast. Здесь мы не будем касаться IPv6, а поговорим про частный случай реализации anycast в сетях IPv4. Схематично взаимодействие anycast показано на Рисунке 4.8.17.

4.8.16 Anycast взаимодействие между узлами компьютерной сети

Вы часто можете встретить такую фразу: anycast взаимодействие означает, что узел будет посылать запрос ближайшему узлу из группы. Читая определение можно вспомнить, что группы есть в multicast и сделать вывод о том, что сообщение должно быть послано ближайшему узлу из multicast группы, но это будет неверное понимание сути anycast.
Давайте сперва разберемся, что понимается под группой? В данном случае под группой будет правильнее понимать узлы, которые оказывают одинаковые услуги. Например, в IPv4 anycast взаимодействие реализовано с корневыми DNS-серверами. Зачем реализовано такое взаимодействие? Да всё просто, чтобы уменьшить нагрузку на корневые DNS-сервера.

В мире всего существует тринадцать корневых DNS-серверов. Доменные имена этих DNS-серверов имеют вид letter.root-servers.net, где вместо letter нужно подставить букву от a до m. Если не ошибаюсь, то все корневые сервера находятся на территории США, представьте, что бы было, если бы компьютер из России делал каждый раз запрос к серверу из США, чтобы узнать IP-адрес домена? Всем было бы плохо. Поэтому каждый из тринадцати оригинальных DNS-серверов имеет свои точные копии в различных точках нашей планеты, чтобы заходя на сайт васька-пупкин.рф, вы не делали запрос к серверу из США, а обращались к копии этого сервера где-нибудь в России.

Для примера возьмем корневой DNS сервер К. Его копии находятся в: Амстердаме, Лондоне, Токио, Дели, Майами, Рейкьявике, Новосибирске, Хельсинки и еще нескольких других городах. Все копии DNS-серверов полностью идентичны, в том числе у них одинаковые IP-адреса, в частности у сервера К вот такой IPv4 адрес: 193.0.14.129. Но как так, спросите вы, ведь ты говорил, что IP-адрес должен быть уникальным в пределах той сети, в которой он находится. Да, должен, но всегда, есть исключения из общих правил.

Благодаря тому, что есть anycast взаимодействие, DNS-запросы из Якутии скорее всего пойдут в Новосибирск, а из Ливерпуля в Лондон. То есть в данном конкретном примере anycast взаимодействия группа узлов в различных городах имеет одинаковый IP-адрес: 193.0.14.129, этот адрес их как раз-таки и объединяет в группу. И получается, что обычные узлы, выполняя DNS-запросы, даже не подозревают, что это anycast, никаких механизмов чтобы это понять у узлов нет.

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

4.8.7 Loopback интерфейсы и loopback адреса

Loopback интерфейс и loopback IP-адрес – это виртуальный интерфейс, который всегда доступен, если доступно само устройство и его сетевые библиотеки работают корректно. Иногда вы можете встретить словосочетание петлевой интерфейс/адрес, циклический и даже кольцевой, всё это про loopback. В протоколе IPv4 выделена целая сеть 127.0.0.0/8 для программной реализации loopback интерфейсов на конечных узлах. Так, например, если у вас есть компьютер под управлением Windows, вы можете попробовать пропинговать любой IP-адрес из указанного диапазона и получить ответ от машины в том случае, если сетевые библиотеки вашего ПК будут работать нормально.