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

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

3.9. Процесс ввода (получения информации) — Input Processing

Данный раздел описывает процесс обработки получаемых RIP-сообщений. Процедура обработки зависит от значения поля команда в заголовке пакета RIP.

3.9.1. Сообщения типа Request

Сообщения типа Request используются для запроса на получения полной таблицы маршрутизации или ее части. Как правило Request посылается как broadcast (multicast для RIPv2). В качестве порта-источника сообщения используется стандартный порт UDP для RIP — 520. Таким образом поступают маршрутизаторы, которые только загрузились и хотят узнать о окружающих их сетях. Что нужно сделать в этом случае? «Заорать» во все стороны (со всех интерфейсов): «Люди добрые, дайте, кто чего знает!»

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

Запрос обрабатывается последовательно запись за записью. Если запрос не содержит записей — соответственно ответ не формируется и не отсылается.

RIP поддерживает один специализированный тип запроса: запрос содержит только одно поле RTE, в котором поле AFI установлено в 0 и метрика установлена в infinity (16). Данный специализированный тип означает запрос на полную таблицу маршрутизации. В этом случае управление передается процессу вывода (Output processing) с указанием того, что нужно выслать полную таблицу маршрутизации на указанный адрес/порт.

Исключая вышеописанный случай, обработка запроса проста и однотипна. Как говорилось ранее, обработка запроса ведется запись за записью (RTE за RTE). Для каждого RTE проверяется собственная таблица на предмет того, есть ли там соответствующая запись. Если есть, в метрику обрабатываемого RTE помещается метрика из таблицы маршрутизации. Если нет, в метрику обрабатываемого RTE помещается 16 (infinity). После того, как все RTE обработаны, поле команды в заголовке изменяется с Request на Response и пакет отсылается обратно запрашивающему.

Обратим внимание на некоторую разницу при формировании ответов на запросы всей таблицы маршрутизации или только ее части. При запросе полной таблицы маршрутизации срабатывает обычный Output processing (процесс вывода), который включает в себя механизм split horizon. При запросе информации о конкретных маршрутах информация в Response помещается в том виде, в котором она присутствует в таблице маршрутизации, то есть никакого split horizon. Почему так? Ну… в общем потому, что запрос полной таблицы необходим, как правило, для получения маршрутной информации. Здесь split horizon необходим. Запросы на конкретные сети формируются, как правило, в диагностических целях, поэтому информация в ответе должна быть точной.

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

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