Сидни Фейт - TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)

В сообщении об изменениях присутствуют все точки назначения и метрики из таблицы маршрутизации отправителя. В запросе указывают элементы для каждого из адресов, метрику которого нужно получить. Элемент с адресом 0 и метрикой 16 запрашивает полное изменение таблицы маршрутизации.

Регулярные изменения RIP пересылаются через протокол UDP из порта источника 520 в порт 520 маршрутизатора назначения. Однако запросы могут посылаться из любого порта, на который и придет ответ на запрос.

Выше мы рассмотрели базовые механизмы протокола RIP. Однако реализации этого протокола имеют некоторые дополнительные возможности для решения следующих проблем:

■ При интервале между изменениями, равном 30 с, требуется много времени на распространение изменений по большой сети

■ После изменения, особенно при потере соединения, имеется тенденция к зацикливанию трафика по кольцу

Далее рассматриваются пути решения этих проблем.

Триггерные изменения (triggered updates) ускоряют процесс исследования изменений. Маршрутизатор, изменив метрику пути, посылает объявление о таком изменении.

Отметим, что новое изменение приводит к переключению следующего изменения, и процесс продолжается далее (это напоминает работу триггера). Такой кратковременный поток сообщений позволит множеству пользователей не применять заведомо неисправные пути.

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

В процессе распространения согласований таблиц маршрутизатор может обнаружить восстановление неисправности и послать сообщение об отмене изменений, поскольку плохой маршрутизатор снова стал хорошим. В таком случае никто не должен менять в своих таблицах хорошую информацию на плохую и вносить изменения, чтобы не распространять далее неверные сведения.

По этой причине многие разработчики реализуют в своих устройствах операцию хранения (hold down), когда в течение определенного периода времени игнорируются точки назначения, маркированные как недостижимые.

Почему иногда происходит зацикливание трафика в RIP? Причина в том, что после изменения проходит некоторое время, пока все маршрутизаторы не обновят информацию. На рис. 8.7 показан простой пример (он взят из RFC 1058). Маршрутизатор D имеет два пути к сети N . Один из них короткий (в одно попадание), а другой — длинный (в 10 попаданий). Если оборвется связь по короткому пути, маршрутизатор D заменит его на альтернативный (длинный) путь с метрикой 10.

Рис. 8.7.Маршрутизация после неисправности в сети

Однако в сообщениях RIP об изменении; посланных маршрутизаторам А, В и С, будут только следующие сведения:

Сеть N Метрика = 2

Нет никакого способа указать в сообщении, что путь проходит через маршрутизатор D. Что же произойдет, когда маршрутизатор D получит изменения от А до того, как укажет А на собственные изменения?

■ D изменит строку своей таблицы на:

■ D попытается переслать трафик к сети N через А (последний отправит трафик обратно).

■ D отправит объявления об изменении своей таблицы на А, В и С (что он может достичь сети N за три попадания).

■ Маршрутизаторы ответят, что они теперь смогут попасть в сеть N за четыре попадания. Маршрутизаторы В и С столкнутся с неоднозначностью и, в зависимости от времени поступления изменений, могут пытаться отправлять свои трафики к сети N друг через друга, через А или D.

■ Изменения RIP будут распространяться дальше и глубже.

Хорошо то, что метрики для сети N в А, В и С будут постоянно увеличиваться с приходом каждого нового изменения, пока не достигнут значения 11 и не будет определен правильный маршрут. Два простых механизма позволяют избежать путаницы в сети, которая может возникнуть во время устранения неисправности.

Деление горизонта (split horizon) требует, чтобы маршрутизаторы не посылали своих объявлений о пути к системам со следующим попаданием по этому пути. В примере на рис. 8.7 маршрутизаторы А, В и С не будут указывать D, что могут достичь сети N, поскольку путь к N проходит через сам маршрутизатор D.