Табл.18. Новая запись в таблице маршрутов

Все последующие IP-пакеты для узла 128.6.7.23 будут посланы прямо через указанный шлюз

До сих пор мы рассматривали способы добавления маршрутов в IP-таблицу, но не способы их исключения. Что случится, если шлюз будет выключен? Хотелось бы иметь способ возврата к маршруту по умолчанию после того, как какой-либо маршрут разрушен. Однако, если шлюз вышел из строя или был выключен, то он уже не может послать сообщение перенаправления. Поэтому должен существовать метод определения работоспособности шлюзов, с которыми ваша машина связана непосредственно. Лучший способ обнаружения неработающих шлюзов основан на выявлении “плохих” маршрутов. Модуль TCP поддерживает различные таймеры, которые помогают ему определить разрыв соединения. Когда случается сбой, то можно пометить маршрут как “плохой” и вернуться к маршруту по умолчанию. Аналогичный метод может использоваться при обработке ошибок шлюза по умолчанию. Если два шлюза отмечены как шлюзы по умолчанию, то машина может использовать их по очереди, переключаясь между ними при возникновении сбоев

6.3. Слежение за маршрутизацией

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

Таким образом, слежение за маршрутизацией в некотором смысле “решает” проблему поддержания корректности таблиц маршрутов. Однако существуют несколько причин, по которым этот метод применять не рекомендуется. Наиболее серьезной проблемой является то, что протоколы маршрутизации пока еще подвергаются частым пересмотрам и изменениям. Появляются новые протоколы маршрутизации. Эти изменения должны учитываться в программном обеспечении всех машин

Несколько более специальная проблема связана с бездисковыми рабочими станциями. По своей природе бездисковые машины сильно зависят от сети и от файл-серверов, с которых они осуществляют загрузку программ, и где располагается их область свопинга. Исполнение программ, следящих за широковещательными передачами в сети, на бездисковых машинах связано с большими трудностями. Протоколы маршрутизации построены в основном на широковещательных передачах. Например, все сетевые шлюзы могут широковещательно передавать содержание своих таблиц маршрутов через каждые 30 секунд. Программы, которые следят за такими передачами, должны быть загружены на бездисковые станции через сеть. На достаточно занятой машине программы, которые не используются в течение нескольких секунд, обычно отправляются в область свопинга. Поэтому программы, следящие за маршрутизацией, большую часть времени находятся в свопинге. Когда они вновь активизируются, должна производиться подкачка из свопинга. Как только посылается широковещательное сообщение, все машины активизируют программы, следящие за маршрутизацией. Это приводит к тому, что многие бездисковые станции будут выполнять подкачку из свопинга в одно и тоже время. Поэтому в сети возникнет временная перегрузка. Таким образом, исполнение программ, прослушивающих широковещательные передачи, на бездисковых рабочих станциях очень нежелательно

6.4. Протокол ARP с представителем

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

Во многом метод, реализуемый протоколом ARP с представителем, аналогичен использованию маршрутов по умолчанию и сообщений перенаправления. Но протокол ARP с представителем не затрагивает таблиц маршрутов, все делается на уровне адресов Ethernet. Протокол ARP с представителем может использоваться либо для маршрутизации IP-пакетов ко всем сетям, либо только в локальной сети, либо в какой-то комбинации подсетей. Проще всего продемонстрировать его использование при работе со всеми адресами

Чтобы использовать протокол, нужно настроить узел так, как будто все машины в мире подключены непосредственно к вашей локальной сети Ethernet. В ОС UNIX это делается командой “route add default 128.6.4.2.0”, где 128.6.4.2 - IP-адрес вашего узла. Как уже отмечалось, метрика 0 говорит о том, что все IP-пакеты, которым подходит данный маршрут, должны посылаться напрямую по локальной сети

Когда нужно послать IP-пакет узлу в локальной сети Ethernet, ваша машина должна определить Ethernet-адрес этого узла. Для этого она использует ARP-таблицу. Если в ARP-таблице уже есть запись, соответствующая IP-адресу места назначения, то из нее просто берется Ethernet-адрес, и кадр, содержащий IP-пакет, отправляется. Если такой записи нет, то посылается широковещательный ARP-запрос. Узел с искомым IP-адресом назначения принимает его и в ARP-ответе сообщает свой Ethernet-адрес. Эти действия соответствуют обычному протоколу ARP, описанному выше

Протокол ARP с представителем основан на том, что шлюзы работают как представители удаленных узлов. Предположим, в подсети 128.6.5 имеется узел 128.6.5.2 (узел A на рис 12). Он желает послать IP-пакет узлу 128.6.4.194, который подключен к другой сети Ethernet (узел B в подсети 128.6.4). Существует шлюз с IP-адресом 128.6.5.1, соединяющий две подсети (шлюз R)

Рис.12. Сеть, использующая протокол ARP с представителем

Если в ARP-таблице узла A нет маршрута доступа к узлу B, то узел A посылает ARP-запрос узлу B. Фактически машина A спрашивает: “Если кто-нибудь знает Ethernet-адрес узла 128.6.4.194, сообщите мне его”. Узел B не может ответить на запрос самостоятельно. Он подключен к другой сети Ethernet и никогда даже не увидит этот ARP-запрос. Однако шлюз R может работать от его имени. Шлюз R отвечает: “Я здесь, IP-адресу 128.6.4.194 соответствует Ethernet-адрес 2:7:1:0:EB:CD”, где 2:7:1:0:EB:CD в действительности является Ethernet-адресом шлюза. Это создает иллюзию, что узел 128.6.4.194 подключен непосредственно к той же локальной сети Ethernet, что и узел A, и имеет Ethernet-адрес 2:7:1:0:EB:CD. Когда узел A захочет послать новый IP-пакет узлу B, он использует указанный Ethernet-адрес. Кадр, содержащий IP-пакет, попадет к шлюзу R, а он переправит его по назначению