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

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

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

Оглавление первой части: «Основы взаимодействия в компьютерных сетях».

Оглавление четвертой части: «Сетевой уровень: протокол IP и его версия IPv4».

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-адреса, было бы желание.

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

[php]
C:\Users\Dell>ping 127.0.0.1

Обмен пакетами с 127.0.0.1 по с 32 байтами данных:
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<1мс TTL=128

Статистика Ping для 127.0.0.1:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

C:\Users\Dell>ping 127.255.255.254

Обмен пакетами с 127.255.255.254 по с 32 байтами данных:
Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128
Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128
Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128
Ответ от 127.255.255.254: число байт=32 время<1мс TTL=128

Статистика Ping для 127.255.255.254:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

[/php]

Когда вы пингуете IP-адреса из диапазона 127.0.0.0/8, вы пингуете сами себя, в Windows такой адрес иногда называют localhost, так как он используется для реализации взаимодействия клиент-сервер в рамках одной машины. Так, например, вы можете установить на свою машину MySQL сервер и делать SQL запросы локально при помощи адреса из диапазона 127.0.0.0/8 и TCP порта 3306, который слушает MySQL по умолчанию. Таким образом получается, что и клиент, и сервер используют один IP-адрес, но разные порты.

Различные веб-сервера типа Денвера или AMPPS в Windows используют адрес из диапазона 127.0.0.0/8. То есть на конечных узлах loopback адреса и loopback интерфейсы используются для того, чтобы была возможность обратиться самому к себе. Если говорить про транзитные узлы, то там зачастую IP-адреса из диапазона 127.0.0.0/8 недоступны, то есть там по умолчанию вообще не созданы loopback интерфейсы, их создает администратор вручную, но при этом он может задать loopback интерфейсу тот IP-адрес, который ему хочется, стоит заметить, что в маршрутизаторах у loopback интерфейсов несколько иной функционал, нежели на конечных узлах.

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

4.8.8 Выводы

Самыми интересными для нас на данном этапе будут multicast и broadcast IP-адреса, а также loopback интерфейсы, именно с этим всем мы будем работать. Anycast мы оставим до знакомства с IPv6, а multicast вообще больше трогать не будем, возможно, в блоге появится отдельная серия публикаций про multicast, но это далеком идущие планы.