RFC: 2453
Оригинал: RIP Version 2
Предыдущие версии: RFC 1388, RFC 1723
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Сергей Кедров

RFC 2453, Страница 6 из 25

3.4.1. Обработка изменений в топологии

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

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

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

Дабы избежать подобной ситуации, протокол, основанный на distance-vector алгоритме должен содержать механизм устаревания (timing out) маршрутов. Детали такого механизма относятся к спецификации собственно протокола. Например, RIP посылает update’ы каждые 30 секунд. Следовательно, маршрутизатор получает информацию о сети N каждые 30 секунд. Если что-то случилось, и он не получит информацию о сети N в течении 180 секунд, он будет считать, что сеть более не достижима. Такой относительно большой таймаут выбирается по тому, что update’ы могут быть потеряны линком между маршрутизаторами, или быть по каким-либо причинам задержанными.

Маршрутизатор может не только определить на основании механизма устаревания, что сеть более недоступна, но и поделиться этой информацией с другими маршрутизаторами. RIP делает это с помощью стандартных update-сообщений. Сети, более не доступные, помечаются в таких сообщениях как «недоступные» (unreachable). Для индикации «недоступности» сети используется метрика 16. Эта метрика в RIP называется «бесконечность» (infinity) и является большей, чем наибольшая доступная к использованию в протоколе метрика. Другими словами, сеть, имеющая метрику 16, является недоступной и пакеты в такую сеть посланы быть не могут.

Страница 6 из 25

2007 - 2022 © Русские переводы RFC, IETF, ISOC.