Адаптация RIP-маршрутизаторов к изменениям состояния сети

Этап 5 — получение RIP-сообщений от соседей и обработка полученной информации

Этап 3 — получение RIP-сообщений от соседей и обработка полученной информации

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

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

Аналогичные операции с новой информацией выполняют и остальные маршрутизаторы сети.

Этап 4 — рассылка новой, уже не минимальной, таблицы соседям

Каждый маршрутизатор отсылает новое RIP-сообщение всем своим соседям. В этом сооб­щении он помещает данные обо всех известных ему сетах — как не­посредственно подключен­ных, так и удаленных, о которых маршрутизатор узнал из RIP-сообщений.

Этап 5 повторяет этап 3 — маршрутизаторы принимают RIP-сообщения, обраба­тывают со­держащуюся в них информацию и на ее основании корректируют свои таблицы маршрутиза­ции.

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

Для адаптации к изменениям в сети протокол RIP использует ряд механизмов.

К новым маршрутам RIP-маршрутизаторы приспосабливаются просто — они пе­редают новую информацию в очередном сообщении своим соседям, и постепенно эта информация становится известна всем маршрутизаторам сети. А вот к отри­цательным изменениям, связанным с поте­рей какого-либо маршрута, RIP-маршрутизаторы адаптируются сложнее. Это связано с тем, что в формате сообще­нии протокола RIP нет поля, которое бы указывало на то, что путь к данной сети больше не существует.

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

1 ) истечение времени жизни маршрута;

2) указание специального расстояния (бесконечности) до сети, ставшей недос­тупной.

Для отработки первого механизма каждая запись таблицы маршрутизации (как и записи таблицы продвижения моста/коммутатора), полученная по протоколу RIP, имеет время жизни (TTL). При поступлении очередного RIP-сообщения, которое подтверждает справед­ливость данной записи, таймер TTL устанавлива­ется в исходное состояние, а затем из него каждую секунду вычитается единица. Если за время тайм-аута не придет новое маршрутное сообщение об этом мар­шруте, то он помечается как недействительный.

Время тайм-аута связано с периодом рассылки векторов по сети. В RIP IР пери­од рассылки выбран равным 30 с, а в качестве тайм-аута выбрано шестикратное значение периода рас­сылки, то есть 180 с. Выбор достаточно малого времени пе­риода рассылки объясняется не­сколькими причинами, которые будут понятны из дальнейшего изложения. Шестикратный запас времени нужен для уверенно­сти в том, что сеть действительно стала недоступной, а не просто произошли подери RIP-сообщений (а это возможно, так как RIP использует транс­портный протокол UDP, который не обеспечивает надежной доставки сообщений).

Дата добавления: 2014-10-15