Что такое broadcast address
Широковещательный адрес
Широковещательный адрес — условный (не присвоенный никакому устройству в сети) адрес, который используется для передачи широковещательных пакетов в компьютерных сетях.
Содержание
Виды широковещательных адресов
В зависимости от уровня модели OSI различают несколько видов широковещательных адресов.
На уровне L2 используется широковещательный MAC-адрес FF:FF:FF:FF:FF:FF для передачи служебных датаграмм (например, ARP-запросов). Датаграммы, отправленные на такой адрес, принимаются всеми сетевыми устройствами локальной сети.
Классы широковещательных адресов в IP сетях
Различают такие применения широковещательных адресов:
Адрес в локальном сегменте IP сети Используется для передачи широковещательных пакетов всем устройствам в локальном сегменте сети. Все устройства в сети должны интерпретировать широковещательный адрес как свой собственный. Такое использование позволяет, в частности, находить шлюзы без статически заданных таблиц, а также сервера имён, времени и т. п. Адрес в удалённом сегменте IP сети Иногда используется для передачи широковещательных пакетов за пределы локального сегмента сети, например для поиска последней версии базы данных имён хостов, мониторинга серверов времени. Работает аналогично адресу в локальном сегменте IP сети, пакет маршрутизируется как обычный, пока не попадает на шлюз, подключённый к подсети, в которой адрес получателя является широковещательным. Широковещательный адрес на весь Интернет Использование такого адреса, естественно, крайне нежелательно.
Широковещательные адреса и безопасность сети
К использованию передачи пакетов на широковещательные адреса (англ. broadcasting ) следует относиться с предельной осторожностью. Некорректное использование может привести к нарушению работоспособности как отдельного сегмента, так и сети в целом (см. широковещательный шторм).
Исходя из соображений безопасности и обеспечения максимальной пропускной способности сети, на шлюзах может быть установлен запрет транзита пакетов на широковещательные адреса.
Что такое broadcast address
Эта страница поможет вам с навигацией по статьям о компьютерных сетях.
Что такое Сеть
Что такое Хост
К хосту можно обратиться по сети.
Хост может посылать запросы к одному или нескольким хостам в сети.
Что такое Протокол
В основе обмена данными по сети лежит передача электрических импульсов. Их можно преобразовать в числа. Например высокое напряжение принять за 1 а низкое за 0.
Можно договориться о том какие наборы из единиц и нулей нужно посылать для успешного обмена информацией.
Это будет называться протоколом. Протолов может быть много и они могут вкладываться друг в друга. Примеры TCP, IP, UPD
Пример протокола
В этом параграфе вы можете познакомиться с моей попыткой объяснить что такое протоколы тем у кого совсем не получается это представить.
Пусть есть хосты А и Б.
Они договорились, что для начала работы один должен послать другому
и получить обратно
А с каждым новым сообщением увеличивать счётчик на 1
Перед реальными данными нужно всегда вставлять
Которые пока никак не используются.
При успешном получении обратно отправляется только увеличенный счётчик
Когда все данные отправлены нужно послать
Данные можно передавать по 8 бит за сообщение.
Пример обмена данными по этому протоколу
Допустим А хочет отправить Б следующие данные:
Так как данных на 16 бит, их нужно разбить на два сообщения по 8 бит.
Б получает предложение к обмену данными, он готов принимать и отправляет обратно 11110001
А получает сигнал готовности к приёму от Б и отправляет реальные данные 11111111, поставив перед этим 10101010 00000000
Б получает 10101010 00000000 11111111 и отправляет обратно 10101011
А получает подтверждение приёма данных от Б и отправляет вторую порцию данных 10101100 00000000 00000000
Б получает 10101100 00000000 00000000 и отпрвляет обратно 10101101
А получает подтверждение приёма второй порции данных и отправляет сообщение об окончании обмена данными 00001111
Б понимает, что данные кончились и приступает к их обработке.
Этот пример просто показывает принцип работы протоколов, в реальности они горазно сложнее. Нужно включать в себя проверку доставки пакетов, проверку очерёдности и многое другое.
Один протокол может быть вложен в другой.
Допустим, в нашем примере появляются новые правила назовём их П1 и П2.
П1: если перед данными приходит не
То данные будут не 8 бит а 16 и перед ними будет ещё 8 бит информации в которой зашифровано какая именно программа их должна обрабатывать
Данных будет по 32 бита без каких-либо других изменений
Очевидно, что обрабатывать данные для П1 и П2 нужно по разному. Хотя оба они основаны на нашем изначальном протоколе.
Этот пример слишком примитивен, но можно вообразить себе, что П1 и П2 это новые протоколы только более высокого уровня.
Пример IP адреса 8.8.8.8
С помощью маски можно увеличить размер Host Portion за счёт Network Portion.
Без маски IP не самодостаточен (пример)
| 203 | 0 | 113 | 10 |
| 11001011 | 00000000 | 01110001 | 00001010 |
| 8 бит | 8 бит | 8 бит | 8 бит |
До 1995-го года использовалсь Classful Addressing
После 1995-го Classless Addressing
Subnet Mask
| IP в десятичном виде | 203 | 0 | 113 | 10 |
|---|---|---|---|---|
| IP в двоичном виде | 11001011 | 00000000 | 01110001 | 00001010 |
| Маска в двоичном виде | 11111111 | 11111111 | 11111111 | 00000000 |
| Маска в десятичном виде | 255 | 255 | 255 | 0 |
Маска также разбита на октеты. В таблице удобно расположены бинарный IP адрес и бинарная маска.
В большой локальной сети не хочется тратить 24 бита на сетевую части и оставлять всего 8 бит на хосты.
Чтобы увеличить число уникальных адресов для хостов нужна другая маска. Например
В маске 255.0.0.0 всё наоборот: 8 бит под сетевую часть и 24 бита под хост
Пример IP адреса с такой маской
| IP в десятичном виде | 10 | . | 0 | . | 0 | . | 10 |
|---|---|---|---|---|---|---|---|
| IP в двоичном виде | 00001010 | . | 00000000 | . | 00000000 | . | 00001010 |
| Маска в двоичном виде | 11111111 | . | 00000000 | . | 00000000 | . | 00000000 |
| Маска в десятичном виде | 255 | . | 0 | . | 0 | . | 0 |
Не обязательно разграничивать Host Portion и Network Portion по границе октета
| IP в десятичном виде | 10 | . | 0 | . | 0 | . | 10 |
|---|---|---|---|---|---|---|---|
| IP в двоичном виде | 00001010 | . | 00000000 | . | 00000000 | . | 00001010 |
| Маска в двоичном виде | 11111111 | . | 11111111 | . | 11110000 | . | 00000000 |
| Маска в десятичном виде | 255 | . | 255 | . | 240 | . | 0 |
IP из предыдущего примера 10.0.0.10 может быть у хоста в сети как с маской 255.0.0.0 так и с маской 255.255.240.0
Разберёмся где проявится разница.
Рассмотрим два IP адреса 10.0.15.10 и 10.0.16.10.
| 10.0.15.10 dec | 10 | . | 0 | . | 15 | . | 10 |
|---|---|---|---|---|---|---|---|
| 10.0.15.10 bin | 00001010 | . | 00000000 | . | 00001111 | . | 00001010 |
| 10.0.16.10 dec | 10 | . | 0 | . | 16 | . | 10 |
| 10.0.16.10 bin | 00001010 | . | 00000000 | . | 00010000 | . | 00001010 |
| Маска в двоичном виде | 11111111 | . | 00000000 | . | 00000000 | . | 00000000 |
| Маска в десятичном виде | 255 | . | 0 | . | 0 | . | 0 |
Сетевая часть адреса занимает только первый октет и выделена жирным шрифтом, поэтому легко понять, что 10.0.15.10 и 10.0.16.10 это два соседних хоста в одной подсети.
Рассмотрим те же адреса но с маской 255.255.240.0
| 10.0.15.10 dec | 10 | . | 0 | . | 15 | . | 10 |
|---|---|---|---|---|---|---|---|
| 10.0.15.10 bin | 00001010 | . | 00000000 | . | 00001111 | . | 00001010 |
| 10.0.16.10 dec | 10 | . | 0 | . | 16 | . | 10 |
| 10.0.16.10 bin | 00001010 | . | 00000000 | . | 00010000 | . | 00001010 |
| Маска в двоичном виде | 11111111 | . | 11111111 | . | 11110000 | . | 00000000 |
| Маска в десятичном виде | 255 | . | 255 | . | 240 | . | 0 |
Обратите внимание на третий октет. Особенно на записи в двоичном виде.
Ни один из положительных битов адреса 10.0.15.10 не попал в сетевую часть. (нет жирных единиц)
Таким образом у 10.0.15.10 адрес хоста остался прежним, но заметно выросла сетевая часть IP адреса.
У 10.0.16.10 единица в третьем октете попала в сетевую часть. От адреса хоста осталось только 1010 а подсеть теперь не такая как у 10.0.15.10
Таким образом теперь 10.0.16.10 и 10.0.15.10 это не соседние хосты одной подсети а разные хосты в разных подсетях.
Classful Addressing
| Класс | Диапазон IP адресов | |
|---|---|---|
| A | 0.0.0.0 | 127.255.255.255 |
| B | 128.0.0.0 | 191.255.255.255 |
| C | 192.0.0.0 | 223.255.255.255 |
| D | 224.0.0.0 | 239.255.255.255 |
| E | 240.0.0.0 | 255.255.255.255 |
Класс A: первые 8 бит это всегда сетевая часть
Класс B: первые 16 бит это всегда сетевая часть
Класс C: первые 24 бита это всегда сетевая часть
Класс D: все 32 бита это всегда сетевая часть
Типы IP адресов
По тому, какое значение принимает Host Portion можно разделить адреса на три типа
Network Address
У сетевого адреса все биты в Host Portion равны 0
| 255.255.255.0 dec | 255 | . | 255 | . | 255 | . | 0 |
|---|---|---|---|---|---|---|---|
| 255.255.255.0 bin | 11111111 | . | 11111111 | . | 11111111 | . | 00000000 |
Broadcast Address
У широковещательного адреса все биты в Host Portion равны 1
| 255.255.255.255 dec | 255 | . | 255 | . | 255 | . | 255 |
|---|---|---|---|---|---|---|---|
| 255.255.255.255 bin | 11111111 | . | 11111111 | . | 11111111 | . | 11111111 |
В чём отличие поясню на примере: почтальону поручили отнести письмо в офис TopBicycle на улице Партнёрская и выдали инструкцию
Доставить до компании Компания;Сайт;Тип;Адрес TopBicycle;www.TopBicycle.ru;Улица Партнёрская
На следующий день почтальону поручили отнести оповещение о ремонте на улице во все дома и офисы на улице Партнёрская.
Оповещения одинаковые для всех компаний.
Доставить до всех адресатов Компания;Сайт;Тип;Адрес URN.SU;https://www.urn.su;IT;Улица Партнёрская HeiHei.ru;https://heihei.ru;TravelУлица Партнёрская TopBicycle.ru;https://topbicycle.ru;BicyclesУлица Партнёрская Авиасейлз;https://aviasales.ru;Travel;Улица Партнёрская Booking.com;https://booking.com;Hotels;Улица Партнёрская Hotellook;https://Hotellook.com;Hotels;Улица Партнёрская Велодрайв;https://velodrive.ru;Bicycles;Улица Партнёрская Xiaomi;https://mi-shop.com;Android;Улица Партнёрская Samsung;https://www.samsungstore.ru;Android;Улица Партнёрская ;https://.ru;Books;Улица Партнёрская GeekBrains;https://gb.ru;Education;Улица Партнёрская Нетология;https://netology.ru;Education;Улица Партнёрская SkillBox;https://SkillBox.ru;Education;Улица Партнёрская Pluralsight;https://Pluralsight.com;Education;Улица Партнёрская СовКомСтрахование;https://sovcomins.ru;Insurance;Улица Партнёрская Полис 812;https://polis812.ru;Insurance;Улица Партнёрская Vivo;https://ru.vivo.com/;Android;Улица Партнёрская Beget;https://beget.com;Hosting;Улица Партнёрская Reg.ru;https://Reg.ru.ru;Hosting;Улица Партнёрская OLDI;https://oldi.ru;Laptops;Улица Партнёрская
Host Address
У адреса хоста может быть любая комбинация бит в Host Portion кроме двух: только нули и только единицы.
Сетевой адрес в десятичной записи может оканчиваться не на 0
Рассмотрим адрес 10.128.224.64 с маской 255.255.255.224.
Проверить являтеся ли адрес сетевым означает проверить содержит ли Host Portion только единицы или нет.
Одного IP адреса для этого недостаточно, нужно рассмотреть его вместе с маской чтобы понять чему равна Host Portion
| IP в десятичном виде | 10 | . | 128 | . | 224 | . | 64 |
|---|---|---|---|---|---|---|---|
| Маска в десятичном виде | 255 | . | 255 | . | 255 | . | 224 |
| IP в двоичном виде | 00001010 | . | 10000000 | . | 11100000 | . | 01000000 |
| Маска в двоичном виде | 11111111 | . | 11111111 | . | 11111111 | . | 11100000 |
CIDR Notation
Рассмотрим маску 255.255.255.0
Первый 24 бита это единицы. Чтобы не писать постоянно 255.255.255 можно писать
Формат следующий сперва слеш, затем длина Network Portion
Private
Существует три диапазона адресов, которые не используются в публичном интернете.
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
| Начало | Конец | Маска |
|---|---|---|
| 10.0.0.0 | 10.255.255.255 | /8 |
| 172.16.0.0 | 172.31.255.255 | /12 |
| 192.168.0.0 | 192.168.255.255 | /16 |
Адрес 127.0.0.1 зарезервирован под Loopback Address
Это означает адрес вашего же компьютера. Можно сказать домашний адрес.
В IPv6 он выглядит как ::1
Subnetting Networks
Рассмотрим IP адрес 10.0.0.0/8
Диапазон хост-адресов (не включая концы):
N 00001010 00000000 00000000 00000000
B 00001010 11111111 11111111 11111111
M 11111111 00000000 00000000 00000000
Курс по основам компьютерных сетей на базе оборудования Cisco. Этот курс поможет вам подготовиться к экзаменам CCENT/CCNA, так как за его основу взят курс Cisco ICND1.
4.8 Виды трафика в IP сетях: unicast, broadcast, multicast, anycast. Loopback адреса и интерфейсы
Привет, посетитель сайта 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-адреса.
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 адреса
Рисунок 4.8.3 Broadcast взаимодействие между узлами компьютерной сети
Как определить, что 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, так как в этом случае они находятся в одной подсети. По этой причине у нас здесь не две канальных среды, а три:
Теперь давайте сделаем широковещательную рассылку в зеленой канальной среде и посмотрим, что из этого выйдет. Для этого откроем командную строку компьютера 192.168.1.2 и выполним команду ping на IP-адрес 192.168.1.255, который в данном случае является широковещательным, естественно, делать это нужно в режиме симуляции Cisco Packet Tracer.
Рисунок 4.8.5 Пример широковещательного запроса в канальной среде
Рисунок 4.8.6 Так выглядит широковещательный запрос в Wireshark
Узел-отправитель берет свой 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 кадре нет поля для передачи маски подсети.
Давайте теперь посмотрим на всё это в 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.
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-адрес. Пусть наш сервер транслирует три канала:
Нужно учесть и то, что для трансляции одного канала требуется полоса пропускания определенной ширины, то есть на трансляцию одного канала тратится кусочек существующей полосы пропускания, пусть у нас каждый канал забирает 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-адрес из указанного диапазона и получить ответ от машины в том случае, если сетевые библиотеки вашего ПК будут работать нормально.