3. Методы маршрутизации подсетей
Обной из проблем, с которыми сталкиваются все хосты Internet, является определение маршрута к другому хосту. Использование подсетей лишь слегка изменяет эту проблему.
При использовании подсетей возникает два уровня процесса маршрутизации вместо одного. Если получатель находится в одной сети с отправителем, в маршрутизации участвуют только маршрутизаторы подсетей между хостами. Если получатель находится в другой сети, процесс маршрутизации требует выбора шлюза для выхода из сети отправителя и маршрута через эту сеть к выбранному шлюзу.
К счастью, большинство хостов могут игнорировать это различие (фактически, игнорировать любой выбор маршрута), используя принятый по умолчанию шлюз в качестве начала маршрута ко всем получателям и опираясь на сообщения ICMP Host Redirect для определения более подходящих маршрутов. Однако такой метод неэффективен для шлюзов и многодомных хостов, поскольку перенаправление может оказаться бесполезным при некорректном начальном выборе маршрута. Таким хостам следует использовать протокол обмена маршрутной информацией, но этот вопрос выходит за пределы настоящего документа. В любом случае, описанная выше проблема не зависит от использования подсетей.
Проблема хостов с одним подключением заключается в поиске хотя бы одного соседнего шлюза. Здесь также имеются два варианта — аппаратная информация и широковещание. Мы полагаем, что проблема поиска соседнего шлюза не зависит от использования подсетей и, следовательно, решение этой проблемы при наличии подсетей будет таким же.
Однако еще одна проблема сохраняется — отправитель должен понять, следует передавать дейтаграмму для адресата шлюзу или ее можно отправить получателю напрямую. Иными словами, находится ли адресат в одной физической сети с отправителем? Эта фаза процесса маршрутизации является единственной, которая требует от реализации явной поддержки подсетей. Фактически, если широковещание не применяется, это единственная ситуация, когда реализацию IP требуется изменить для поддержки подсетей.
В силу сказанного, возможно использовать существующие реализации без внесения изменений даже при наличии подсетей. Для того, чтобы это тсало возможным, реализация должна:
- использоваться только на хостах с одним подключением, но не на шлюзах;
- использоваться в широковещательной ЛВС;
- использовать протокол преобразования адресов (типа ARP [RFC826]);
- не требовать поддержки соединения в случаях отказов шлюза.
В такой ситуации можно ограничиться модификацией сервера ARP в подсети так, чтобы он при получении запроса ARP проверял адрес получателя на предмет определения своей принадлежности к лучшему пути в направлении получателя. При положительном результате проверки сервер передает запрашивающему хосту отклик ARP со своим аппаратным адресом. Запрашивающий хост в результате предполагает, что ему известен аппаратный адрес получателя и передает пакеты по этому адресу. Фактически пакеты получает шлюз, который пересылает их адресату обычным путем.
Этот метод требует некоторого «размывания» уровней на шлюзах, поскольку сервер ARP и таблица маршрутизации IP обычно не связаны. Однако реализовать такую связь можно достаточно просто и без существенного снижения производительности. Одна из проблем состоит в том, что при аварии исходного шлюза для отправителя не будет способа узнать другие маршруты к получателю, если такие маршруты имеются. В результате соединение будет прервано.
Не следует путать этот метод организации «подсетей на базе ARP» со слегка похожим на него использованием мостов на основе ARP. Подсети на базе ARP используют возможность шлюза проверять адрес IP и устанавливать маршрут к получателю на основе явной топологии подсети. Иными словами, малая часть процесса выбора маршрута переносится от хоста-отправителя к шлюзу. Мост на основе ARP, напротив, должен узнать расположение каждого хоста без помощи отображения между адресами хостов и топологией. Системы, построенные на основе таких мостов, не следует считать поделенными на подсети.
Важно отметить, что использование подсетей на базе ARP осложняется широковещанием. Серверу ARP [RFC826] никогда не следует отвечать на запросы, где получатель имеет широковещательный адрес. Такие запросы могут исходить только от хостов, которые не распознают широковещательных адресов в таком качестве и ответ на подобный запрос почти всегда будет приводить к возникновению маршрутной петли. Если имеется N таких хостов, которые не распознают адрес в качестве широковещательного, пакет, переданный с TTL может приводить к возникновению T^N ненужных широковещательных пакетов.