Кафедра информационно-коммуникационные технологии
КУРСОВАЯ РАБОТА
«Протокол обмена управляющими сообщениями – ICMP. Протоколы обмена маршрутной информацией»
по дисциплине «Основы построения объединенных сетей»
Протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol, ICMP), позволяет маршрутизатору сообщить конечному узлу об ошибках, с которыми машрутизатор столкнулся при передаче какого-либо IP-пакета от данного конечного узла.
Управляющие сообщения ICMP не могут направляться промежуточному маршрутизатору, который участвовал в передаче пакета, с которым возникли проблемы, так как для такой посылки нет адресной информации – пакет несет в себе только адрес источника и адрес назначения, не фиксируя адреса промежуточных маршрутизаторов.
Протокол ICMP – это протокол сообщения об ошибках, а не протокол коррекции ошибок. Конечный узел может предпринять некоторые действия для того, чтобы ошибка больше не возникала, но эти действия протоколом ICMP не регламентируются.
Каждое сообщение протокола ICMP передается по сети внутри пакета IP. Пакеты IP с сообщениями ICMP маршрутизируются точно так же, как и любые другие пакеты, без приоритетов, поэтому они также могут теряться. Кроме того, в загруженной сети они могут вызывать дополнительную загрузку маршрутизаторов. Для того, чтобы не вызывать лавины сообщения об ошибках, потери пакетов IP, переносящие сообщения ICMP об ошибках, не могут порождать новые сообщения ICMP.
Все протоколы обмена маршрутной информацией стека TCP/IP относятся к классу адаптивных протоколов, которые в свою очередь делятся на две группы, каждая из которых связана с одним из следующих типов алгоритмов:
дистанционно-векторный алгоритм (Distance Vector Algorithms, DVA),
алгоритм состояния связей (Link State Algorithms, LSA).
В алгоритмах дистанционно-векторного типа каждый маршрутизатор периодически и широковещательно рассылает по сети вектор расстояний от себя до всех известных ему сетей. Получив вектор от соседнего маршрутизатора, каждый маршрутизатор добавляет к нему информацию об известных ему других сетях, о которых он узнал непосредственно (если они подключены к его портам) или из аналогичных объявлений других маршрутизаторов, а затем снова рассылает новое значение вектора по сети. В конце концов, каждый маршрутизатор узнает информацию об имеющихся в интерсети сетях и о расстоянии до них через соседние маршрутизаторы.
Дистанционно-векторные алгоритмы хорошо работают только в небольших сетях. В больших сетях они засоряют линии связи интенсивным широковещательным трафиком, к тому же изменения конфигурации могут отрабатываться по этому алгоритму не всегда корректно, так как маршрутизаторы не имеют точного представления о топологии связей в сети, а располагают только обобщенной информацией – вектором дистанций, к тому же полученной через посредников.
Наиболее распространенным протоколом, основанным на дистанционно-векторном алгоритме, является протокол RIP.
Алгоритмы состояния связей обеспечивают каждый маршрутизатор информацией, достаточной для построения точного графа связей сети. Все маршрутизаторы работают на основании одинаковых графов, что делает процесс маршрутизации более устойчивым к изменениям конфигурации. Широковещательная рассылка используется здесь только при изменениях состояния связей, что происходит в надежных сетях не так часто.
Для того чтобы понять, в каком состоянии находятся линии связи, подключенные к его портам, маршрутизатор периодически обменивается короткими пакетами со своими ближайшими соседями. Этот трафик также широковещательный, но он циркулирует только между соседями и поэтому не так засоряет сеть.
Протоколом, основанным на алгоритме состояния связей, в стеке TCP/IP является протокол OSPF.
Протокол BGP разработан компаниями IBM и CISCO. Главная цель BGP – сократить транзитный трафик.
BGP отличается от RIP и OSPF тем, что использует TCP в качестве транспортного протокола. Две системы, использующие BGP, связываются друг с другом и пересылают посредством TCP полные таблицы маршрутизации.
Протокол ICMP играет в сети вспомогательную роль. Спецификация этого протокола содержится в RFC 792.
Существует ряд ситуаций, когда протокол IP не может доставить пакет адресату, например, когда истекает время жизни пакета, когда в таблице маршрутизации отсутствует маршрут к заданному в пакете адресу назначения, когда пакет не проходит проверку по контрольной сумме и т.д. Протокол IP не предпринимает средств для гарантированной доставки данных. Это свойство «необязательности» протокола IP компенсируется протоколами более высокого уровня, например TCP на транспортном уровне.
Протокол ICMP служит дополнением протокола IP несколько другого рода. Он не предназначен для исправления возникших при передаче пакета проблем: если пакет потерян – ICMP не может послать его заново. Задача ICMP другая – он является средством оповещения отправителя о «несчастных случаях», произошедших с его пакетами. В то время как протокол IP посылает пакет и забывает о нем, протокол ICMP «отслеживает» передвижение пакета по сети и при отбрасывании пакета маршрутизатором, передает сообщение об этом узлу-источнику, обеспечивая таким образом обратную связь между посланным пакетом и отправителем.
Сообщения ICMP протокола, как правило, оповещают об ошибках, возникающих при обработке датаграмм. При этом, некоторые из пакетов могут исчезнуть в сети, не вызвав при этом никаких оповещений. Чтобы уйти от бесконечной посылки сообщений о сообщениях и т.д., когда количество сообщений лавинообразно возрастает («штормов»), сообщения ICMP не посылаются о сообщениях ICMP. Также ICMP сообщения посылаются только об ошибках в обработке нулевого фрагмента фрагментированных датаграмм (нулевой фрагмент имеет 0 в поле смещения). Если ошибка возникла при передаче какого-либо фрагмента, кроме нулевого, а также когда потерянный пакет имел широковещательный адрес или был упакован в кадр с широковещательным адресом несущей технологии, ICMP сообщения не передаются.
Поскольку IP-пакет содержит адрес отправителя, но не содержит никакой адресной информации о промежуточных маршрутизаторах, ICMP-сообщения направляются только конечным узлам. Здесь сообщения могут быть обработаны либо ядром операционной системы, либо протоколами транспортного и прикладного уровней, либо приложениями, либо просто проигнорированы. Важно, что обработка ICMP-сообщений не входит в обязанности протоколов IP и ICMP.
Существует несколько типов сообщений ICMP. Каждый тип сообщения имеет свой формат, при этом все они начинаются с общих трех полей: 8-битного целого числа, обозначающего тип сообщения (TYPE), 8-битного поля кода (CODE), который конкретизирует назначение сообщения, и 16-битного поля контрольной суммы (CHECKSUM). Кроме того, сообщение ICMP всегда содержит заголовок и первые 64 бита данных пакета IP, который вызвал ошибку. Это делается для того, чтобы узел-отправитель смог более точно проанализировать причину ошибки, так как все протоколы прикладного уровня стека TCP/IP содержат наиболее важную информацию для анализа в первых 64 битах своих сообщений.
Все типы ICMP-сообщений могут быть разделены на 2 класса:
· диагностические сообщения
· информационные сообщения типа запрос / ответ
ICMP-сообщение инкапсулируется в поле данных IP-пакета (рис 1).
ICMP-сообщение
Заголовок ICMP состоит из 8 байт; поля заголовка перечислены ниже:
· Тип (размером 1 байт) содержит код, определяющий тип сообщения. Основные типы перечислены в таблице 1.
· Код (размером 1 байт) более тонко дифференцирует тип ошибки.
· Контрольная сумма, подсчитанная для всего ICMP-сообщения, занимает 2 байта.
Заголовок также включает поле из 4 байт, содержимое которого зависит от значений полей типа и кода. В сообщениях типа запрос / ответ это поле содержит 2-байтовые подполя идентификатора и порядкового номера. Числа из этих подполей дублируются из сообщения-запроса в сообщение-ответ. Идентификатор позволяет узлу-получателю сообщения определить, какому приложению направлен этот ответ, а порядковый номер используется приложением, чтобы связать ответ с соответствующим запросом. В сообщениях об ошибке это поле не используется и заполняется нулями.
Таблица 1. Возможные значения поля типа
| Значение | Тип сообщения |
| 0 | Эхо-ответ (Echo Replay) |
| 3 | Узел назначения недостижим (Destination Unreachable) |
| 4 | Подавление источника (Source Quench) |
| 5 | Перенаправление маршрута (Redirect) |
| 8 | Эхо-запрос (Echo Request) |
| 11 | Истечение времени дейтаграммы (Time Exceeded for a Datagram) |
| 12 | Проблема с параметром пакета (Parameter Problem on a Datagram) |
| 13 | Запрос отметки времени (Timestamp Request) |
| 14 | Ответ отметки времени (Timestamp Replay) |
| 17 | Запрос маски (Address Mask Request) |
| 18 | Ответ маски (Address Mask Replay) |
Каждый тип ошибки может быть более точно охарактеризован кодом ошибки. Например, в таблице 2 приведены коды для сообщения о недостижимости узла назначения (ошибка типа 3 из табл. 1). Эти коды, которые могут быть указаны в сообщении этого типа, позволяют выделить множество различных причин данной ситуации.
Таблица 2. Коды, детализирующие причину ошибки о недостижимости
| Код | Причина |
| 0 | Сеть недостижима |
| 1 | Узел недостижим |
| 2 | Протокол недостижим |
| 3 | Порт недостижим |
| 4 | Требуется фрагментация, а бит DF установлен |
| 5 | Ошибка в маршруте, заданном источником |
| 6 | Сеть назначения неизвестна |
| 7 | Узел назначения неизвестен |
| 8 | Узел-источник изолирован |
| 9 | Взаимодействие с сетью назначения административно запрещено |
| 10 | Взаимодействие с узлом назначения административно запрещено |
| 11 | Сеть недостижима для заданного класса сервиса |
| 12 | Узел недостижим для заданного класса сервиса |
Маршрутизатор, обнаруживший по какой-либо причине, что он не может передать IP-пакет далее по сети, должен отправить ICMP-сообщение узлу-источнику, и только потом отбросить пакет. Кроме причины ошибки, ICMP-сообщение включает также заголовок недоставленного пакета и его первые 64 бита поля данных.