3.3.1.4 Обнаружение «мертвых» шлюзов
Уровень IP должен обеспечивать возможность обнаружения неработающих маршрутизаторов на следующем интервале (next-hop gateway), включенных в кэш маршрутов, и выбора других маршрутов взамен поврежденных (см. параграф 3.3.1.5).
Процесс обнаружения сбойных маршрутизаторов детально рассмотрен в [RFC816]. До сегодняшнего дня не разработано полного алгоритма, обеспечивающего эффективное обнаружение сбойных маршрутов, хотя предложен целый ряд методик.
Не рекомендуется использовать конкретный маршрутизатор при отсутствии признаков его работоспособности.
Активные средства проверки типа ping (т.е., использование сообщений ICMP Echo Request/Reply) слишком накладны и не обеспечивают требуемого масштабирования. В частности, следует отметить, что недопустимо проверять состояние первого маршрутизатора путем непрерывной передачи по его адресу запросов ICMP.
Даже при отсутствии других способов проверки состояния маршрутизатора ping следует использовать только в случаях отсутствия подтверждений работы маршрутизатора при передаче ему реального трафика, что позволяет усомниться в работоспособности маршрутизатора.
Чтобы избежать использования ping уровни выше и ниже IP должны обеспечивать возможность получения сведений о состоянии пути в кэше маршрутов за счет использования позитивной (маршрутизатор работает) или негативной информации о состоянии шлюза.
- Обсуждение:
Если реализация не включает адекватного механизма обнаружения неработающих маршрутизаторов, сбой в маршрутизаторе будет приводить к пропаданию пакетов в «черной дыре». Такие ситуации вызывают массу нареканий со стороны пользователей и весьма сложны для обнаружения.
Механизм обнаружения «мертвых» маршрутизаторов не должен создавать неприемлемой нагрузки на хост, подключенную сеть или соседние маршрутизаторы. Продолжительность детектирования и приемлемый уровень нагрузки в некоторой степени зависят от характера использования хоста, но в общем случае требуется достаточно быстро находить повреждение в ближайшем маршрутизаторе (first-hop gateway), чтобы не нарушалась работа приложений транспортного уровня, не использующих прямых соединений (connections) за время детектирования сбоя и поиска альтернативного пути.
Передача информации от соседних уровней стека протоколов усложняет интерфейс между уровнями, но может существенно упростить обнаружение сбойных маршрутизаторов. Информация может приходить почти от всех элементов архитектуры IP/TCP, но наиболее важны сведения от транспортного и канального уровней. Ниже приведены примеры такой информации:
TCP или другой протокол на основе соединений должен обеспечивать возможность получения негативной информации (например, слишком большое число повторных передач).
TCP может давать позитивную информацию после получения (нового) подтверждения о доставке данных. Даже при асимметричном маршруте такое подтверждение свидетельствует об успешной передаче.
Сообщения ICMP Redirect от конкретных маршрутизаторов должны использоваться как позитивные сведения о работе шлюза.
Информация канального уровня, который способен эффективно детектировать сбои и сообщать о них (например, с помощью сообщений ARPANET Destination Dead), должна использоваться как негативные сведения.
Сбои в работе ARP или при проверке отображений (преобразований) ARP могут использоваться как негативная информация для соответствующих адресов IP.
Поступление пакетов от конкретного адреса канального уровня является подтверждением работы соответствующего устройства. Однако включение таких данных в сведения о работоспособности шлюзов требует отображения адресов канального уровня в адреса IP и последующей проверки принадлежности этих адресов указанным в кэше маршрутов шлюзам. Такое решение может оказаться недостаточно эффективным.
Отметим, что использование позитивных сведений от каждой полученной дейтаграммы может привести к чрезмерной загрузке системы.
Сведения могут передаваться с использованием требуемых аргументов во все интерфейсы с IP-уровнем, однако некоторые транспортные и прикладные протоколы не способны генерировать корректные анонсы. Такие интерфейсы, следовательно, должны поддерживать нейтральные сведения, поскольку передача анонса с неверным знаком (позитив — негатив) может привести к некорректной работе системы.
Существуют (и широко распространен) иной метод определения «мертвых» маршрутизаторов, но его использование не рекомендуется. Этот метод основан на получении хостом (в пассивном режиме wiretapping) дейтаграмм протокола IGP (Interior Gateway Protocol), которыми маршрутизаторы обмениваются между собой с использованием широковещательных адресов. Такое решение имеет существенный недостаток — хосты должны распознавать все протоколы внутренних шлюзов, которые маршрутизатор может использовать (см. [RFC1009]). Кроме того, такой вариант будет работать только в широковещательной сети.
В настоящее время ping (т. е., использование сообщений ICMP Echo) используется как механизм проверки работоспособности маршрутизаторов только при возникновении абсолютной необходимости. Отклики на ping гарантируют работоспособность проверяемого интерфейса и связанной с ним машины, но они не гарантируют возможности передачи дейтаграмм в другие интерфейсы маршрутизатора. При наличии сообщений Redirect или иных явных признаков того, что машина является шлюзом, отклики на ping будут говорить о том что маршрутизатор успешно выполняет свои функции. Однако отбрасывание хостом без уведомления пакетов, которые маршрутизатор должен пересылать или перенаправлять, может приводить к тому, что такое предположение перестанет быть верным. Чтобы избежать подобных проблем, разрабатывается новый тип сообщений "are you a gateway?" (это маршрутизатор?).