Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Семейство адресов, IP-адрес и поле метрики могут повторяться, поэтому сообщение может содержать до 25 адресных элементов. Максимальная длина сообщения составляет 512 октетов. Если нужно переслать сведения о более чем 25 элементах, используется несколько сообщений.
В сообщении об изменениях присутствуют все точки назначения и метрики из таблицы маршрутизации отправителя. В запросе указывают элементы для каждого из адресов, метрику которого нужно получить. Элемент с адресом 0 и метрикой 16 запрашивает полное изменение таблицы маршрутизации.
Регулярные изменения RIP пересылаются через протокол UDP из порта источника 520 в порт 520 маршрутизатора назначения. Однако запросы могут посылаться из любого порта, на который и придет ответ на запрос.
8.9.6 Настройка RIP
Выше мы рассмотрели базовые механизмы протокола RIP. Однако реализации этого протокола имеют некоторые дополнительные возможности для решения следующих проблем:
■ При интервале между изменениями, равном 30 с, требуется много времени на распространение изменений по большой сети
■ После изменения, особенно при потере соединения, имеется тенденция к зацикливанию трафика по кольцу
Далее рассматриваются пути решения этих проблем.
8.9.7 Триггерные изменения и хранение
Триггерные изменения (triggered updates) ускоряют процесс исследования изменений. Маршрутизатор, изменив метрику пути, посылает объявление о таком изменении.
Отметим, что новое изменение приводит к переключению следующего изменения, и процесс продолжается далее (это напоминает работу триггера). Такой кратковременный поток сообщений позволит множеству пользователей не применять заведомо неисправные пути.
Поскольку формируются причины для одновременной пересылки большого числа изменений, каждая из систем будет ожидать произвольный период времени, прежде чем начать дальнейшую пересылку. Кроме того, полоса пропускания для трансляции таких изменений может быть сокращена за счет пересылки только реально изменившихся строк, а не всей таблицы маршрутизации.
В процессе распространения согласований таблиц маршрутизатор может обнаружить восстановление неисправности и послать сообщение об отмене изменений, поскольку плохой маршрутизатор снова стал хорошим. В таком случае никто не должен менять в своих таблицах хорошую информацию на плохую и вносить изменения, чтобы не распространять далее неверные сведения.
По этой причине многие разработчики реализуют в своих устройствах операцию хранения (hold down), когда в течение определенного периода времени игнорируются точки назначения, маркированные как недостижимые.
8.9.8 Деление горизонта и опасный реверс
Почему иногда происходит зацикливание трафика в RIP? Причина в том, что после изменения проходит некоторое время, пока все маршрутизаторы не обновят информацию. На рис. 8.7 показан простой пример (он взят из RFC 1058). Маршрутизатор D имеет два пути к сети N. Один из них короткий (в одно попадание), а другой — длинный (в 10 попаданий). Если оборвется связь по короткому пути, маршрутизатор D заменит его на альтернативный (длинный) путь с метрикой 10.
Рис. 8.7. Маршрутизация после неисправности в сети
Однако в сообщениях RIP об изменении; посланных маршрутизаторам А, В и С, будут только следующие сведения:
Сеть N Метрика = 2
Нет никакого способа указать в сообщении, что путь проходит через маршрутизатор D. Что же произойдет, когда маршрутизатор D получит изменения от А до того, как укажет А на собственные изменения?
■ D изменит строку своей таблицы на:
Назначение Следующее попадание Метрика Сеть N А 3■ D попытается переслать трафик к сети N через А (последний отправит трафик обратно).
■ D отправит объявления об изменении своей таблицы на А, В и С (что он может достичь сети N за три попадания).
■ Маршрутизаторы ответят, что они теперь смогут попасть в сеть N за четыре попадания. Маршрутизаторы В и С столкнутся с неоднозначностью и, в зависимости от времени поступления изменений, могут пытаться отправлять свои трафики к сети N друг через друга, через А или D.
■ Изменения RIP будут распространяться дальше и глубже.
Хорошо то, что метрики для сети N в А, В и С будут постоянно увеличиваться с приходом каждого нового изменения, пока не достигнут значения 11 и не будет определен правильный маршрут. Два простых механизма позволяют избежать путаницы в сети, которая может возникнуть во время устранения неисправности.
Деление горизонта (split horizon) требует, чтобы маршрутизаторы не посылали своих объявлений о пути к системам со следующим попаданием по этому пути. В примере на рис. 8.7 маршрутизаторы А, В и С не будут указывать D, что могут достичь сети N, поскольку путь к N проходит через сам маршрутизатор D.
Опасный реверс (poisoned reverse) идет еще дальше. По этому алгоритму маршрутизаторы А, В и С (см. рис. 8.7) предотвращают распространение неверных сведений с помощью специального сообщения, означающего "Не пытайтесь передавать через меня!". Более точно — изменения будут включать элемент:
Сеть N Метрика = 16
Это исключает проблемы в небольших сетях, но для сетей с большим диаметром колец зацикливания они остаются, даже когда реально нельзя достичь точки назначения. Метрики все равно когда-нибудь увеличатся до 16, и будет восстановлен правильный маршрут. Этот процесс называется подсчетом до бесконечности (counting to infinity).
Способы, идентичные рассмотренным выше алгоритмам, можно обнаружить в любом из маршрутизаторов RIP. Однако существует десяток версий RIP, написанных для слишком простых устройств (возможно, для кухонных тостеров). Если нет достоверных данных о способе работы конкретной модели маршрутизатора, его лучше переместить в небольшую сеть и конфигурировать вручную.
Несколько очевидных недостатков сообщений протокола RIP версии 1 мы рассмотрим в следующих разделах.
8.9.9 Нет маски подсети
В сообщения прокола RIP версии 1 не включаются маски (см. рис. 8.6), следовательно, нельзя определить, что представляет собой адрес: подсеть или хост.
Долгое время разработчики маршрутизаторов решали эту проблему, требуя, чтобы пользователи выбирали одну маску подсети для всей сети. Подключенный к сети маршрутизатор определял эту маску с помощью анализа конфигурации интерфейсов сети.
Маршрутизаторы, не подключенные непосредственно к сети, не имели возможности определить маску подсети. Сведения о подсети удаленной сети были для них бесполезны. По этой причине маршрутизаторы RIP версии 1 не посылали сведений о подсетях и хостах на маршрутизаторы, которые не были подключены непосредственно к сети, содержащей эти подсети и хосты. Внешний маршрутизатор посылал единственный элемент для всей сети (например, 145.102.0.0).
Данный способ мог привести как к избытку строк в таблице маршрутизации, так и к их недостатку. Если в сети использовалась адресация CIDR, следовало обеспечить отдельные строки для каждого из адресов класса С такой связки. В то время как один элемент с маской подсети мог бы представлять всю сеть CIDR.
8.9.10 Широковещательные рассылки в локальной сети
Версия 1 выполняет широковещательные рассылки в локальной сети. Следовательно, каждый из сетевых интерфейсов должен принимать и анализировать такие сообщения. Больший смысл имеет использование многоадресных рассылок.
8.9.11 Отсутствие аутентификации
Еще одним неприятным свойством версии 1 является отсутствие аутентификации для сообщений RIP. Если некто получил доступ к сети и сформировал сообщение с заведомо ложной информацией (фальсифицировав адрес источника), то это может сделать недоступным большинство точек назначения и привести к серьезному нарушению работы сети.
8.9.12 Отсутствие распознавания медленных и быстрых связей
Сетевой администратор может вручную присвоить для связи значение счетчика попаданий. Следовательно, для связи "точка-точка" со скоростью 9,6 Кбайт/с можно установить значение счетчика 5, что укажет на ее меньшие возможности по сравнению со связью 10 Мбайт/с.
К сожалению, когда счетчик достигнет значения 15, точка назначения станет недоступной, а значит, администратору лучше использовать для всех связей одно и то же значение веса, равное 1.
