Дополнительные протоколы маршрутизации ICMP и IGMP

Протокол обмена управляющими сообщениями ICMP (Internet Control Message Protocol) играет в сети вспомогательную роль, а именно позволяет маршрутизатору сообщить конечному узлу об ошибках, с которыми он столкнулся при передаче какого-либо IP-пакета от данного конечного узла.

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

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

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

Существует несколько типов сообщений ICMP, каждый из которых имеет свой формат, хотя при этом все они начинаются с общих трех полей: 8-битного целого числа, обозначающего тип сообщения (Type), 8-битного поля кода (Code), который конкретизирует назначение сообщения, и 16-битного поля контрольной суммы (Checksum). Кроме того, сообщение ICMP всегда содержит заголовок и первые 64 бита данных пакета IP, который вызвал ошибку. Это делается для того, чтобы узел-отправитель смог более точно проанализировать причину ошибки, так как все протоколы прикладного уровня стека TCP/IP содержат наиболее важную информацию для анализа в первых 64 битах своих сообщений. Поле Тип сообщения может иметь значения, представленные в табл. 2.14 [15].

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

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

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

Таблица 2.14 – Значения поля Тип сообщения

Значение	Тип сообщения
	Эхо-ответ (Echo Replay)
	Узел назначения недостижим (Destination Unreachable)
	Подавление источника (Source Quench)
	Перенаправление маршрута (Redirect)
	Эхо-запрос (Echo Request)
	Истечение времени дейтаграммы (Time Exceeded for a Datagram)
	Проблема с параметром пакета (Parameter Problem on a Datagram)
	Запрос отметки времени (Timestamp Request)
	Ответ отметки времени (Timestamp Replay)
	Запрос маски (Address Mask Request)
	Ответ маски (Address Mask Replay)

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

Когда маршрутизатор не может передать или доставить IP-пакет, он отсылает узлу, отправившему этот пакет, сообщение «Узел назначения недостижим» (тип сообщения – 3). Это сообщение содержит в поле кода значение, уточняющее причину, по которой пакет не был доставлен. Коды причин представлены в табл. 2.15.

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

Таблица 2.15 – Причины недоставки пакета

Код	Тип сообщения
	Сеть недостижима
	Узел недостижим
	Протокол недостижим
	Порт недостижим
	Требуется фрагментация, а бит DF установлен
	Ошибка в маршруте, заданном источником
	Сеть назначения неизвестна
	Узел назначения неизвестен
	Узел-источник изолирован
	Взаимодействие с сетью назначения административно запрещено
	Взаимодействие с узлом назначения административно запрещено

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

Недостижимость протокола и порта означает отсутствие реализации какого-либо протокола прикладного уровня в узле назначения или же отсутствие открытого порта протоколов UDP или TCP в узле назначения.

Ошибка фрагментации возникает тогда, когда отправитель послал в сеть пакет с признаком DF, запрещающим фрагментацию, а маршрутизатор столкнулся с необходимостью передачи этого пакета в сеть со значением MTU меньшим, чем размер пакета.

Маршрутные таблицы у компьютеров обычно являются статическими, так как конфигурируются администратором сети, а у маршрутизаторов – динамическими, формируемыми автоматически с помощью протоколов обмена маршрутной информации. Поэтому с течением времени при изменении топологии сети маршрутные таблицы компьютеров могут устаревать. Кроме того, эти таблицы обычно содержат минимум информации, например только адреса нескольких маршрутизаторов [22].

Для корректировки поведения компьютеров маршрутизатор может использовать сообщение протокола ICMP, называемое Перенаправление маршрута (Redirect). Это сообщение посылается в том случае, когда маршрутизатор видит, что компьютер отправляет пакет некоторой сети назначения нерациональным образом, то есть не тому маршрутизатору локальной сети, от которого начинается более короткий маршрут к сети назначения.

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

В сообщении Перенаправление маршрута маршрутизатор помещает IP-адрес маршрутизатора, которым нужно пользоваться в дальнейшем, и заголовок исходного пакета с первыми 64 битами его поля данных. Из заголовка пакета узел «узнает», для какой сети необходимо пользоваться указанным маршрутизатором.

Итак, протокол ICMP используется для диагностики и мониторинга сети. Помимо утилиты ping, ICMP-сообщения использует также утилита tracert (Приложение А).

Отдельного упоминания заслуживает протокол групповых рассылок IGMP (Internet Group Memebership Protocol), структурной единицей которого является дейтаграмма (как и у протокола UDP), то есть эти протоколы упаковывают в IP-пакет готовые сообщения, а не сегменты [13].

Мультикастингом (multicasting) называется рассылка дейтаграмм группе получателей. Для идентификации групп используются специальные адреса получателя; эти адреса назначаются из класса D в диапазоне 224.0.0.0–239.255.255.255. Дейтаграмма, направленная на групповой адрес, должна быть доставлена всем участникам группы.

Ряд адресов зарезервирован для специальных групп. Вот только некоторые из них:

1) 224.0.0.1 – все узлы в данной сети;

2) 224.0.0.2 – все маршрутизаторы в данной сети;

3) 224.0.0.5 – все OSPF-маршрутизаторы;

4) 224.0.0.6 – выделенные OSPF-маршрутизаторы;

5) 224.0.0.9 – маршрутизаторы RIP-2;

6) 224.0.1.1 – получатели информации по протоколу точного времени NTP.

Все адреса в диапазоне 224.0.0.0–238.255.255.255 предназначены для использования в масштабе Интернета. Адреса вида 239.Х.Х.Х зарезервированы для внутреннего использования в частных сетях.

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

Групповая рассылка, по сравнению с индивидуальной, уменьшает нагрузку на сеть. Предположим, дейтаграмму следует отправить 500 получателям. Используя индивидуальную рассылку, отправитель должен генерировать 500 дейтаграмм, каждая из которых будет отправлена одному узлу. При мультикастинге отправитель создает одну дейтаграмму с групповым адресом назначения; по мере продвижения через сеть дейтаграмма будет дублироваться только на «развилках» маршрутов от отправителя к получателям. В лучшем случае (если таких развилок не будет), например, все получатели находятся в одной сети Ethernet, экономия трафика будет 500-кратной. При этом сохраняются также вычислительные ресурсы промежуточных узлов.

Получателей дейтаграмм с определенным групповым адресом мы будем называть членами данной группы. Отметим, что отправитель групповой дейтаграммы не обязан знать индивидуальные IP-адреса получателей и не должен быть членом группы.

Недостатком групповой рассылки является очевидная невозможность использования на транспортном уровне протокола TCP. Использование же протокола UDP имеет типичные для него негативные последствия: ненадежность доставки, отсутствие средств реагирования на заторы в сети и т. д. Кроме того, в отдельных случаях при изменении маршрутов рассылки групповые дейтаграммы могут не только теряться, но и дублироваться, что должно учитываться приложениями.

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

Основным предположением, которое при этом делается, является то, что маршрутизатор «знает», члены каких групп находятся в непосредственно подсоединенных к нему сетях. Таким образом, прежде чем перейти к вопросам маршрутизации групповых дейтаграмм, требуется разработать механизм регистрации членов групп на маршрутизаторе, к которому подключена их сеть. Этим механизмом является протокол IGMP, предназначенный для регистрации на маршрутизаторе членов групп, находящихся в непосредственно присоединенных к нему сетях. Имея эту информацию, маршрутизатор может сообщать другим маршрутизаторам (с помощью протоколов групповой маршрутизации) о необходимости пересылки ему дейтаграмм для тех или иных групп. Современная версия протокола IGMP – версия 2.

IGMP работает непосредственно над протоколом IP и идентифицируется значением 2 в поле Протокол верхнего уровня заголовка IP-пакета. За IP-заголовком в пакете следует сообщение IGMP, структура которого представлена на рис. 2.15.

8 бит Тип сообщения	8 бит Максимальное время отклика	16 бит Контрольная сумма
32 бита Групповой адрес

Рис. 2.15 – Формат сообщения IGMP

Поле Тип сообщения (Type) однобайтовое, оно является полем данных сообщения IGMP и может иметь следующие значения:

1. Membership Query (Type = 17) – запрос о наличии в сети членов групп (отправляется маршрутизатором). Запросы обо всех имеющихся группах (общие запросы) отправляются по адресу 224.0.0.1 («всем узлам»); запросы о наличии членов определенной группы – частные запросы – отправляются по адресу этой группы;

2. Membership Report (Type = 22) – уведомление о наличии в сети члена группы (отправляется хостом – членом группы – по адресу группы);

3. Leave Group (Type = 23) – уведомление об отсоединении хоста от группы (отправляется отсоединившимся хостом по адресу 224.0.0.2 – «всем маршрутизаторам»).

Поле Максимальное время отклика (Max Response Time) является однобайтовым и задействовано только в сообщениях типа Membership Query.

Поле Контрольная сумма (Checksum) является двухбайтовым и обычно применяется для проверки целостности сообщения.

Групповой IP-адрес (Group Address) представляет собой четырехбайтовое поле, куда заносится IPv4 адрес групповой рассылки.

Работа протокола IGMP продемонстрирована ниже.

На первом этапе маршрутизатор опрашивает группы хостов, при своем включении и далее периодически рассылая по адресу 224.0.0.1 общий запрос Membership Query (при этом поле Групповой IP-адрес обнулено). Период этих рассылок может меняться администратором; значение по умолчанию – 125 секунд. Приняв такой запрос, каждый получатель групповых дейтаграмм выжидает случайное время. Если за этот период кто-то другой уже ответил сообщением Membership Report, то данный хост не отвечает; в противном случае он сам посылает такое сообщение. Значение поля Максимальное время отклика в Membership Query указывает максимальное время, на которое хост может задержать ответ Membership Report (обычно 10 секунд). Описанный прием используется, чтобы избежать посылки многочисленных ответов с адресом одной и той же группы: маршрутизатору не нужно «знать», сколько именно членов данной группы есть у него в сети, – ему требуется лишь сам факт их наличия.

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

При подключении хоста к новой группе он самостоятельно отправляет сообщение типа Membership Report, не дожидаясь очередного запроса от маршрутизатора. Для каждой группы, члены которой обнаружились в сети, маршрутизатор ведет отсчет времени неактивности. Если ни одного Membership Report для этой группы не было получено за определенный период (по умолчанию – 260 секунд), то маршрутизатор считает, что членов этой группы в сети больше нет.

Когда хост отсоединяется от группы, он может послать сообщение Leave Group по групповому адресу 224.0.0.2 («всем маршрутизаторам»); адрес группы содержится в поле Групповой IP-адрес. Получив сообщение Leave Group, маршрутизатор генерирует частный запрос Membership Query для членов только этой группы. Если за время, указанное в поле Максимальное время отклика (по умолчанию – 1 секунда), маршрутизатор не получил ни одного ответа Membership Report, то он считает, что членов данной группы в сети больше нет. Для надежности запрос посылается 2 раза.

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

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

Классическим методом является Веерная рассылка (Flooding) – наиболее простой метод маршрутизации групповых дейтаграмм, при котором дейтаграмма рассылается во все сети системы независимо от наличия в той или иной сети членов группы. При поступлении групповой дейтаграммы маршрутизатор проверяет, впервые ли он ее получает. Если да, то маршрутизатор рассылает дейтаграмму через все свои интерфейсы, кроме того, с которого она была получена; в противном случае дейтаграмма игнорируется.

Отметим, что маршрутизатор должен хранить в памяти список всех «недавно» полученных групповых дейтаграмм от любого источника для каждой группы и производить поиск в этом списке при получении новых дейтаграмм. При интенсивном групповом трафике это потребует больших затрат памяти и мощности процессора. Другим существенным недостатком этого метода является то, что групповая дейтаграмма рассылается от источника всеми возможными путями: в некоторые сети дейтаграмма может быть передана несколько раз (разными маршрутизаторами). При этом наличие или отсутствие получателей не принимается в расчет. Следовательно, плюсы веерной рассылки – простота реализации, надежность (за счет избыточности), независимость от маршрутных таблиц и протоколов маршрутизации.

Более усовершенствованный метод – остовые деревья (Spanning Trees). В системе сетей выбирается корневой маршрутизатор, после этого из графа системы выделяется подграф-дерево, соединяющий корневой маршрутизатор со всеми остальными маршрутизаторами системы («остовое дерево»). Эта процедура производится на этапе инициализации системы – в процессе работы дерево не изменяется (рис. 2.16).

Рис. 2.16 – Метод остовых деревьев

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

Метод остовых деревьев многие считают лучше веерной рассылки, поскольку здесь дейтаграммы распространяются по строго определенным маршрутам и в каждую сеть попадает только один экземпляр дейтаграммы. Кроме того, существенно снижена нагрузка на маршрутизаторы, которым больше не требуется хранить устаревшие таблицы дейтаграмм. Однако групповые дейтаграммы по-прежнему рассылаются во все сети независимо от наличия в них получателей. Еще существует большое количество сложных методов, оптимизирующих маршрутизацию групповых рассылок, среди которых наиболее популярными являются методы RPF (Reverse Path Forwarding) и CBT (Core Based Trees) [24].

Выводы

В главе 2 нами была проанализирована теоретическая основа функционирования любых вычислительных сетей – модель OSI, рассмотрены функциональные особенности каждого из семи ее уровней (представленные сведения систематизированы и проиллюстрированы рядом рисунков и таблиц). Определено соответствие между уровнями теоретической модели OSI и применяемым на практике стеком протоколов TCP/IP. Были выявлены особенности функционирования протоколов транспортного и сетевого уровней стека протокола TCP/IP. Особое внимание уделено анализу современных систем адресации, различным подходам к классификации протоколов маршрутизации, а также структурным единицам основных протоколов стека TCP/IP (Приложение В).

Контрольные вопросы

1. Определение и назначение многоуровнего подхода к сетевому взаимодействию.

2. Соотношение понятий интерфейс, протокол и стек протоколов.

3. Инкапсуляция данных в модели OSI.

4. Два основных типа протоколов модели OSI.

5. Функциональные особенности физического и канального уровней модели OSI.

6. Функциональные особенности сетевого и транспортного уровней модели OSI.

7. Общая характеристика протоколов сетевого уровня модели OSI.

8. Функциональные особенности сеансового, представительного и прикладного уровней модели OSI.

9. Общая характеристика трех уровней стека протоколов TCP/IP.

10. Причины возникновения гибридной модели сетевого взаимодействия и характеристика ее уровней.

11. Общая характеристика протоколов сетевого и транспортного уровней стека TCP/IP.

12. Пример взаимодействия двух компьютеров в рамках гибридной модели.

13. Пример инкапсуляции пакетов в стеке TCP/IP.

14. Характеристика функциональных особенностей протокола межсетевого взаимодействия IP.

15. Общая характеристика структуры пакета IPv4.

16. Основные отличия протокола IPv6 от IPv4.

17. Общая характеристика структуры пакета IPv6.

18. Заголовки расширений пакета IPv6.

19. Проблема перехода с протокола IPv4 на IPv6

20. Основные требования к современным системам адресации.

21. Функции и назначение MAC-адресов.

22. Характеристика символьной системы адресации.

23. Назначение и применение составных числовых адресов (на примере адреса IPv4).

24. Упрощенный подход к IPv4-адресации.

25. Классовый подход к IPv4-адресации.

26. Соотношение понятий маска подсети и рабочая группа.

27. Классы IPv4-адресов.

28. Ограничения и особые адреса в IPv4-адресации.

29. Примеры деления IP-адреса в соответствии с трехуровневой архитектурой.

30. Проверка принадлежности IPv4-адресов к одной подсети.

31. Специфика IPv6-адресации.

32. Сущность технологии бесклассовой междоменной маршрутизации CIDR и понятие префикса.

33. Соответствие адресов различных типов в одноранговых и доменных сетях.

34. Общая характеристика работы протокола ARP для разрешения МАС- и IP-адресов.

35. Структура запросов и ответов ARP.

36. Соотношение понятий ARP-кэш и ARP-таблица.

37. Централизованный и распределенный подход установления соответствия между символьными и IP-адресами.

38. Соотношение понятий мультеплексирвоание и демультиплексирование в протоколах транспортного уровня.

39. Соотношение понятий сегмент и дейтограмма в протоколах транспортного уровня.

40. Соотношение понятий порт, адрес и сокет в стеке TCP/IP.

41. Структура UDP-заголовка.

42. Структура TCP-заголовка.

43. Основные отличия транспортных протоколов TCP и UDP.

44. Общая характеристика бестабличной маршрутизации.

45. Централизованный и распределенный подходы к табличной маршрутизации.

46. Адаптивная и статическая маршрутизации.

47. Внешние и внутренние протоколы маршрутизации.

48. Общая характеристика и функциональные возможности дистанционно-векторного протокола RIP.

49. Общая характеристика и функциональные возможности протокола состояния связей OSPF.

50. Общая характеристика и функциональные возможности шлюзового протокола BGP.

51. Сфера применения внутренних протоколов RIP и OSPF.

52. Структура протокола обмена управляющими сообщениями ICMP и его характеристика.

53. Определение и назначение мультикастинга.

54. Структура протокола групповых рассылок IGMP и его характеристика.

55. Основные виды маршрутизации групповых рассылок.