как определить броадкаст адрес

Как определить броадкаст адрес

Чтобы в любой локалке работало.

← →
Hub ( 2002-05-06 01:37 ) [1]

В общем, чтобы небыл привязан к конкретной сети(например к 192.168.10.255), а вычислялся сам.

← →
BAHO ( 2002-05-06 03:35 ) [2]

Тоже хотел бы ето узнать.

← →
Malder ( 2002-05-06 12:38 ) [3]

← →
Anatoly Podgoretsky ( 2002-05-06 12:59 ) [4]

Malder © (06.05.02 12:38)
Так это неверно в корне

Пакет через UDP слать? Если да, то воспользуйтесь TSockAddrIn

← →
Malder ( 2002-05-06 23:09 ) [6]

← →
Anatoly Podgoretsky ( 2002-05-06 23:32 ) [7]

Пусть адрес 192.168.1.1 маска 255.255.255.252 broadcast 192.168.1.3

← →
Malder ( 2002-05-06 23:41 ) [8]

← →
Doom ( 2002-05-06 23:42 ) [9]

Malder © (06.05.02 23:41)
Ты видимо плохо представляешь работу сетей

← →
Malder ( 2002-05-07 00:01 ) [11]

Anatoly Podgoretsky, видимо да. Но пока не вижу ничего неправильного в свих словах.

← →
Anatoly Podgoretsky ( 2002-05-07 00:09 ) [12]

Оно правильно только для сетей класса С и абсолютно неверно для А, В и подсетей

← →
Malder ( 2002-05-07 01:11 ) [13]

← →
Anatoly Podgoretsky ( 2002-05-07 12:05 ) [14]

Броадкаст для класса A = x.255.255.255
Броадкаст для класса B = x.x.255.255
Броадкаст для всех классов = 255.255.255.255

Так как-же узнать маску сети? Я смотрел в хелпе по сокетам, не нашел! Хоть где копать подскажите!

← →
Malder ( 2002-05-08 00:17 ) [16]

← →
Vogul ( 2002-05-08 16:12 ) [17]

Источник

Метод быстрого вычисления адреса IPv4 сети по маске

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

Итак, мы имеем произвольный IP адрес – 192.170.175.83/13 и наша 1 задача вычислить адрес сети, для этого мы посмотрим на второй октет, так как именно он содержит как сетевую так и хостовую часть. На хостовую часть во втором октете отводится 3 бита, что дает нам 8 (2^3) изменяемых хостовых адресов в данном октете, т.е. каждая подсеть в данном октете будет содержать 8 изменяемых адресов. Теперь мы разделим представленное в третьем октете число на количество изменяемых адресов – 170/8 = 21.25, в результате деления мы получили номер искомой подсети – 21 (дробная часть нас ясное дело не интересует). Зная номер подсети, и количество изменяемых адресов в ней мы можем вычислить ее адрес, для этого 21 * 8 = 168. Итого – адрес сети будет 192.168.0.0.

Задача №2 – вычислить широковещательный адрес, для этого мы к 168 прибавим количество изменяющихся адресов и вычтем единицу: 168 + 8 – 1 = 175, следовательно, широковещательный адрес данной подсети 192.175.255.255.

И по поводу последних двух октетов в моем примере – если маска в октете нулевая, то в адресе сети он всегда будет равен 0, и широковещательный адрес всегда будет равен 255.

PS: Если данный метод ранее кому то встречался – просьба дать ссылку.

Источник

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

wikiHow работает по принципу вики, а это значит, что многие наши статьи написаны несколькими авторами. При создании этой статьи над ее редактированием и улучшением работали авторы-волонтеры.

Количество просмотров этой статьи: 68 083.

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

Общее число битов T_b = 8 Число битов используемое для подсетей n = 3(так как маска подсети равна 224, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 3)

Значение последнего бита, используемого для маски подсети = Δ = 2 m = 2 5 = 32

Общее число битов = T_b = 8 Число битов используемое для подсетей = n = 2 (так как маска подсети равна 192, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 2).

Значение последнего бита, используемого для маски подсети = Δ = 2 m = 2 6 = 64

Число битов, используемое для подсетей для маски 240 = n₁ = 4
(так как маска подсети равна 240, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 4)

Число битов, используемое для подсетей для маски 0 = n₁ = 0
(так как маска подсети равна 0, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 0)

Число подсетей для маски 240 = 2 n₁ = 2 4 = 16
Число подсетей для маски 0 = 2 n₂ = 2 0 = 1

Значение последнего бита, используемого для маски подсети для маски 240 = Δ₁ = 2 m₁ = 2 4 = 16
Значение последнего бита, используемого для маски подсети для маски 0 = Δ₂ = 2 m₂ = 2 8 = 256

Для маски подсети 240, адреса будут разделены по 16, а для маски 0 их будет 256. Используя значения Δ₁ и Δ₂, получим 16 подсетей ниже

IP-адрес 100.5.150.34 относится к подсети 100.5.144.0 – 100.5.159.255, поэтому 100.5.144.0 — адрес сети, а — 100.5.159.255 широковещательный адрес.

Число битов, используемое для подсетей для маски 128 = n₁ = 1
(так как маска подсети равна 128, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 1)

Число битов, используемое для подсетей для маски 0 = n₂ = n₃ = 0
(так как маска подсети равна 0, а соответствующее «число битов используемое для подсетей» из таблицы сверху равно 0)

Число подсетей для маски 128 = 2 n₁ = 2 1 = 2
Число подсетей для маски 0 = 2 n₂ = 2 n₃ = 2 0 = 1

Для маски подсети 128, адреса будут разделены по 128, а для маски 0 их будет 256. Используя значения Δ₁ и Δ₂, получим 2 подсети ниже

IP-адрес 200.222.5.100 относится к подсети 200.128.0.0 – 200.255.255.255, и поэтому 200.128.0.0 — адрес подсети, а 200.255.255.255 — широковещательный адрес.

Источник

Курс по основам компьютерных сетей на базе оборудования 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-адреса, было бы желание.

Детальную информацию о зарезервированных 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-адрес из указанного диапазона и получить ответ от машины в том случае, если сетевые библиотеки вашего ПК будут работать нормально.

Источник