TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
Напомним, что ICMP-сообщение об ошибке посылается, когда в сети не все благополучно. Важно обеспечить, чтобы трафик ICMP не перегружал сети, делая ситуацию еще хуже. Для этого протокола, требуется ввести несколько очевидных ограничений. ICMP не должен формировать сообщения о:
■ Маршрутизации и доставке ICMP-сообщений messages
■ Широковещательных и многоадресных датаграммах
■ Фрагментах датаграмм, кроме первых
■ Сообщениях, чей адрес источника не идентифицирует уникальный хост (например, IP-адреса источников 127.0.0.1 или 0.0.0.0)
7.4 Формат сообщения ICMP
Сообщение ICMP переносится в части данных датаграммы IP. Каждое сообщение ICMP начинается тремя одинаковыми полями: полем типа (Type),
Сообщение об ошибке ICMP обрамляется заголовком IP. Добавляются первые 8 октетов датаграммы, которая привела к ошибке. Эти сведения позволяют проанализировать причину ошибки, поскольку содержат информацию о предполагаемом назначении датаграммы и целевом протоколе четвертого уровня. Дополнительные 8 байт позволяют определить коммуникационный элемент приложения (более подробно об этом см. в разделе о протоколах TCP и UDP).
В сообщение включается и контрольная сумма ICMP, начиная от поля Type.
7.4.1 Сообщение Destination Unreachable
Существует много причин прекращения доставки датаграммы. Разорванная связь физически не позволит маршрутизатору достичь подсети назначения или выполнить пересылку в точку следующего попадания. Хост назначения может стать недоступным при отключении его для проведения профилактики.
Как уже отмечалось в главе 6, современные маршрутизаторы имеют хорошие средства обеспечения безопасности. Они могут быть сконфигурированы для просмотра входящего в сеть трафика. При запрещении сетевым администратором доступа к точке назначения датаграмма также не может быть доставлена.
Рис. 7.4. Формат ICMP-сообщения Destination Unreachable
Формат сообщения Destination Unreachable показан на рис. 7.4. Поле Type (в нашем случае 3) идентифицирует именно этот тип сообщения. Поле Code отражает причину отправки сообщения. Полный список кодов этого поля представлен в таблице 7.2.
Таблица 7.2 Коды ошибок сообщения Destination Unreachable
| Код | Смысл |
|---|---|
| 0 | Сеть недостижима. |
| 1 | Хост недостижим. |
| 2 | Запрашиваемый протокол не поддерживается в точке назначения. |
| 3 | Порт недостижим (недоступно удалённое приложение). |
| 4 | Необходима фрагментация, но установлен флаг "Не фрагментировать". |
| 5 | Неверен маршрут от источника. |
| 6 | Неизвестна сеть назначения. |
| 7 | Неизвестен хост назначения. |
| 8 | Хост источника изолирован. |
| 9 | Административно запрещены коммуникации с сетью назначения. |
| 10 | Административно запрещены коммуникации с хостом назначения. |
| 11 | Сеть недостижима для заданного типа обслуживания. |
| 12 | Хост недостижим для заданного типа обслуживания. |
7.4.2 Сообщение Time Exceeded
Пересылаемая
Рис. 7.5. Формат ICMP-сообщения Time Exceeded
Значения кодов (см. таблицу 7.3) отражают причину тайм-аута.
Таблица 7.3 Коды сообщения Time Exceeded
| Код | Смысл |
|---|---|
| 0 | Завершилось время жизни датаграммы. |
| 1 | Завершилось время на сборку фрагментов датаграммы. |
7.4.3 Сообщение Parameter Problem
ICMP-сообщение Parameter Problem используется для отчета об ошибках, не специфицированных в кодах других сообщений. Например, в полях вариантов может появиться неверная информация, не позволяющая правильно обработать датаграмму, в результате чего датаграмма будет отброшена. Более часто проблемы с параметрами возникают из-за ошибок в реализации, когда система пытается записать параметры в заголовок IP.
Рис. 7.6. Формат ICMP-сообщения Parameter Problem
Поле Pointer (указатель) сообщения Parameter Problem идентифицирует октет, в котором выявлена ошибка. На рис. 7.6 показан формат сообщения Parameter Problem, а в таблице 7.4 — значения кодов ошибок.
Таблица 7.4 Коды сообщения Parameter Problem
| Код | Смысл |
|---|---|
| 0 | Значение в поле указателя специфицирует ошибочный октет. |
| 1 | Отсутствует требуемый вариант (используется военными для указания на отсутствие параметров безопасности) |
| 2 | Неверная длина |
7.4.4 Проблемы перегрузок
Протокол IP очень прост: хост или маршрутизатор обрабатывают датаграмму и посылают ее как можно быстрее. Однако доставка не всегда проходит гладко. Могут возникнуть различные проблемы.
Когда один или несколько хостов отправляют трафик UDP на медленный сервер, то на последнем может возникнуть перегрузка, что приведет к отбрасыванию сервером некоторой части этого трафика.
Маршрутизатор может переполнить свои буферы и далее будет вынужден отбрасывать некоторые поступающие датаграммы. Медленное соединение через региональную сеть (например, на скорости 56 Кбит/с) между двумя скоростными локальными сетями (например, в 10 Мбит/с) может создать затор на пути следования датаграмм. Из-за этого в сети возникнут перегрузки, которые также приведут к отбрасыванию датаграммы и, следовательно, к созданию еще большего трафика.
7.4.5 Сообщение Source Quench
Сообщение Source Quench (подавление источника) показано на рис. 7.7. Оно позволяет попытаться решить проблему перегрузок, хотя и не всегда успешно. Механизмы для подавления источника перегрузки сети должны создавать разработчики конкретных продуктов, но остается открытым конкретный вопрос:
Когда и кому маршрутизатор или хост должен отправлять сообщение Source Quench?Рис. 7.7. Формат ICMP-сообщения Source Quench