3.4.2. Обеспечение стабильности
Пока еще вышеописанный механизм немного далек от реальной жизни и не обеспечивает своевременного и корректного пересчета таблиц маршрутизации. Вышеописанный механизм обеспечивает корректировку таблиц маршрутизации в некое конечное время. Однако неизвестно, действительно ли это конечное время будет настолько малым, что это будет приемлемо для реально существующих сетей. Кроме того, большое время пересчета таблиц может привести к несоответствиям в работе алгоритма в масштабе достаточно большой сети.
В случае отключения какой-либо сети или маршрутизатора, как мы видели выше, по происшествии некоторого времени (таймаута) соседние с отключенной компонентой маршрутизаторы помечают ее в своих таблицах маршрутизации как недоступную, то есть присваивается метрика 16. Далее эти маршрутизаторы будут рассылать update’ы с записью, содержащей метрику 16. Получив update, содержащий запись с метрикой 16, маршрутизатор не будет, как обычно, добавлять к полученной метрике cost сети (см. раздел 3.4.0.4 Функции участника алгоритма). Метрика и так уже «недостижима», чего же более.
Таким образом все маршрутизаторы сети через некоторое время узнают, что одной из сетей больше не существует, то есть она не доступна. Однако это некое время может оказаться слишком большим. Вообще, все это может привести к неприятностям. Каким? Рассмотрим на примере.
В нашем примере будет рассматриваться случай «падения» сети №2. Каким образом это произойдет технически — дело двадцать пятое и здесь не рассматривается.