ICND2_Vol1_RUS

Подсчет до бесконечности

Медленная сходимость является причиной несогласованной маршрутизации.

Когда сеть 10.4.0.0 отказывает, маршрутизатор C обнаруживает отказ и прекращает маршрутизацию пакетов через интерфейс E0. Однако на этом этапе маршрутизаторы A и B не получают уведомления об отказе. Маршрутизатор A продолжает считать, что у него есть доступ к сети 10.4.0.0 через маршрутизатор B. Таблица маршрутизации маршрутизатора A все еще содержит путь к сети 10.4.0.0 с расстоянием 2.

Подсчет до бесконечности (прод.)

Маршрутизатор C решает, что лучший путь к сети 10.4.0.0 лежит через маршрутизатор B.

Когда маршрутизатор B отправляет периодическую копию своей таблицы маршрутизации маршрутизатору C, маршрутизатор C считает, что он имеет исправный путь к сети 10.4.0.0 через маршрутизатор B. Маршрутизатор C обновляет свою таблицу маршрутизации, чтобы добавить путь к сети 10.4.0.0 через маршрутизатор B с количеством переходов равным 2.

Подсчет до бесконечности (прод.)

Маршрутизатор A обновляет свою таблицу маршрутизации в соответствии с новым, ошибочным числом переходов.

Маршрутизатор B получает новое обновление от маршрутизатора C и обновляет свою таблицу, добавляя новую стоимость (3 перехода). Маршрутизатор A получает новую таблицу маршрутизации от маршрутизатора B, обнаруживает обновленный вектор расстояния к сети 10.4.0.0 и заново рассчитывает свой собственный вектор расстояния до 10.4.0.0. Новое значение равняется 4.

Подсчет до бесконечности (прод.)

Число переходов к сети 10.4.0.0 увеличивается до бесконечности.

На этот момент таблицы маршрутизации всех трех маршрутизаторов неверны.

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

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

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

Решение проблемы подсчета до бесконечности: задание максимального значения

Для предотвращения образования бесконечных петель вводится ограничение на число переходов.

Решение проблемы подсчета до бесконечности — задание максимума. Дистанционновекторные протоколы определяют бесконечность как некое максимальное число. Это число относится к одной из метрик маршрутизации, например к количеству переходов.

Пример: задание максимума предотвращает подсчет до бесконечности

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

Петли маршрутизации

Пакеты для сети 10.4.0.0 двигаются в петле между маршрутизаторами B и C.

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

Существует несколько методов предотвращения образования петель маршрутизации.

В том числе: Split horizon (разделение горизонта), Route poisoning (порча маршрута), Poison reverse (обратная порча маршрута), таймеры удержания и триггерные обновления.

Пример: петли маршрутизации

Вэтом примере пакет, направленный в сеть 10.4.0.0, прибывает на маршрутизатор A.

Всоответствии со своей таблицей маршрутизации маршрутизатор A пересылает пакет через интерфейс S0. Пакет прибывает на маршрутизатор B, который пересылает его через интерфейс S1, в соответствии со своей таблицей маршрутизации. Маршрутизатор C получает этот пакет и проверяет его таблицу маршрутизации, которая указывает, что пакет следует переслать через интерфейс S0. Таким образом, пакет возвращается на маршрутизатор B, который снова пересылает пакет маршрутизатору C через интерфейс S1. Пакет попадает в бесконечную петлю между маршрутизаторами B и C.

Решение проблемы петель маршрутизации: Split Horizon

Не следует посылать информацию о маршруте в обратном направлении, т. е. к источнику исходных данных.

Один из методов, позволяющих исключить образование петель маршрутизации и ускорить сходимость, называется Split horizon (разделение горизонта). Основное правило Split horizon — не следует посылать информацию о маршруте в обратном направлении, т. е. к источнику исходных данных.

Пример: Split Horizon

На рисунке описывается, как метод Split horizon исключает образование петель маршрутизации.

Маршрутизатор B имеет доступ к сети 10.4.0.0 через маршрутизатор C. Маршрутизатору B нет никакого смысла объявлять маршрутизатору C, что маршрутизатор B имеет доступ к сети 10.4.0.0 через маршрутизатор C.

Если маршрутизатор B передал объявление о своем маршруте к сети 10.4.0.0 маршрутизатору A, маршрутизатору A не имеет смысла объявлять о расстоянии от сети 10.4.0.0 до маршрутизатора B.

Когда маршрутизатор C объявляет о том, что его подключение к сети 10.4.0.0 недоступно, маршрутизатор B видит, что альтернативный путь к сети 10.4.0.0 отсутствует и заключает, что она недоступна. Маршрутизатор C не использует маршрутизатор B, чтобы достичь сети 10.4.0.0.

Решение проблемы петель маршрутизации: Route Poisoning и Poison Reverse

Маршрутизаторы до бесконечности объявляют расстояния недоступных маршрутов.

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

Пример: Route Poisoning

Когда сеть 10.4.0.0 перестает быть доступной, маршрутизатор C «портит» свой канал к сети 10.4.0.0, отправляя обновление для этого канала, которое сообщает, что канал имеет бесконечную метрику и количество переходов равное 16 (это значит, что сеть недоступна). Благодаря порче маршрута маршрутизатора C к сети 10.4.0.0 этот маршрутизатор становится невосприимчивым к неверным обновлением, относящимся к сети 10.4.0.0 и поступающих от соседних маршрутизаторов, которые могут объявлять о действующем альтернативном пути.

Решение проблемы петель маршрутизации: Route Poisoning и Poison Reverse (прод.)

Функция Poison reverse является единственным исключением правила Split Horizon

Когда маршрутизатор B видит, что метрика сети 10.4.0.0 стала бесконечной, он отправляет обновление, которое называется Poison reverse (обратная порча маршрута), обратно к маршрутизатору C. Обновление Poison reverse указывает, что сеть 10.4.0.0 недоступна. Poison reverse является особым состоянием, переопределяющим метод Split horizon. Оно обеспечивает невосприимчивость маршрутизатора C к неверным обновлениям, относящимся к сети 10.4.0.0.

Решение проблемы петель маршрутизации: таймеры удержания

Маршрутизатор поддерживает запись о том, что сеть находится в состоянии «предположительно недоступна», что дает другим

маршрутизаторам достаточно времени для повторного вычисления маршрутов с учетом изменения топологии.

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

Таймеры удержания работают следующим образом.

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

Если от соседнего маршрутизатора приходит обновление с лучшей метрикой, чем исходная метрика сети, маршрутизатор отмечает сеть как «доступную» и удаляет таймер удержания.

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

Во время периода удержания маршруты заносятся в таблицу маршрутизации как "предположительно недоступные". Маршрутизатор будет направлять пакеты

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

Триггерные обновления

Маршрутизатор отправляет обновления при изменении таблицы маршрутизации.

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

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

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

Пакеты с обновлением могут быть отброшены или повреждены одним из каналов сети.

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

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