3.4.3. Split horizon
Часть вышерассмотренных проблем может быть разрешена с помощью более тщательного отношения к тому, куда какая информация посылается. то есть нет необходимости посылать информацию о сети тому маршрутизатору, который информацию об этой же сети и прислал. В нашем примере маршрутизатор A не должен посылать маршрутизатору B от него же полученную информацию о сети №2. «Split horizon» — это механизм, препятствующий посылке информации тому маршрутизатору, от которого эта информация получена.
Механизм имеет два варианта реализации. Первый «simple split horizon», или «split horizon» заключается в том, что информация не посылается тому маршрутизатору, от которого она получена. В нашем примере: маршрутизатор A не будет посылать информацию о сети №2 маршрутизатору B.
Второй вариант называется «split horizon with poisoned reverse». Отличается от первого тем, что информация посылается тому маршрутизатору, от которого она была получена, но! В качестве метрики используется 16 — то есть «недостижима». В нашем примере: маршрутизатор A посылает информацию о сети №2 маршрутизатору B с метрикой 16.
Выбор используемого в той или иной ситуации способа остается на совести сетевого администратора. Однако необходимо отметить два момента, которые следует учитывать при выборе:
При наличии в сети циклов и использовании механизма «split horizon with poisoned reverse» отработка изменений в топологии будет происходить быстрее в силу того, что маршрутизаторы будут получать информацию о «недостижимости» сети друг от друга достаточно быстро. При использовании «split horizon» неправильные маршруты будут исключаться только по происшествии таймаута.
Механизм «split horizon with poisoned reverse» подразумевает внесение дополнительной информации в update-сообщения по сравнению со«split horizon». В большой сети с большим количеством сетей и маршрутизаторов и наличием линков с небольшой скоростью это может оказаться ощутимым. Второй вопрос, стоит ли использовать в такой сети RIP?
3.4.4. Triggered update
Механизм «triggered update» разработан в целях ускорения процесса отработки изменений сетевых маршрутов. Механизм прост. В том случае, если маршрутизатор получает информацию о изменении конфигурации сети — перестал функционировать собственный интерфейс, пришел update, из-за которого пришлось изменить таблицу маршрутизации, мор, глад, семь казней египетских (последние три не учитываются) — в таких случаях маршрутизатор не ожидает очередного срока посылки update’а, а посылает update немедленно. То есть не то чтобы совсем немедленно, маршрутизатор ожидает некое небольшое случайное время. Делается это для того, чтобы избежать одновременного шторма update’ов в пределах сети.
Реальная жизнь может вносить коррективы в безупречную работу алгоритма. Например, даже в случае использования «triggered update» может оказаться так, что у каких-либо маршрутизаторов, еще не получивших новую информацию, наступает время посылки регулярного update’а. Ничего не зная о происходящем, такой маршрутизатор выдает всем окружающим уже устаревшую информацию. Несмотря на то, что при «triggered update» задержка посылки update’а достаточно мала, такая ситуация возможна. Ничего плохого в ней нет, однако время отработки изменений в сети в таком случае увеличиться. Такие случаи надо даже не то, чтобы учитывать, но помнить о том, что они возможны.