Протокол RIP не обеспечивает решение всех возможных проблем, которые могут возникнуть в процессе определения маршрута в сетях передачи данных. Как уже упоминалось выше, в первую очередь он предназначен для использования в качестве IGP в гомогенных сетях небольшого размера. Кроме того, использование данного протокола приводит к появлению специфических ограничений на параметры сети, в которой он может быть использован.
Ограничение максимальной длины маршрута
Использование протокола RIP целесообразно в сетях, самый длинный путь в которых составляет не более 15 переходов (hops). Данное ограничение определяется способом вычисления маршрута, который принят в данном алгоритме и не может быть преодолено.
Зацикливание маршрутов
Использование протокола RIP может в ряде случаев привести к появлению «зацикленных маршрутов». Для предотвращения возникновения подобных ситуаций должны быть использованы специальные меры (poison reverse, split horizon).
Формат метрики
Для сравнения маршрутов протокол RIP использует достаточно простую «метрику» – число переходов. Однако использование данного критерия в целом ряде случаев не может обеспечить оптимальный выбор маршрута.
· RFC‑1388. Протокол RIP‑2 (1993 год) является новой версией RIP, которая в дополнение к широковещательному режиму поддерживает мультикастинг; позволяет работать с масками субсетей.
· RFC‑1582. Расширение к RIP по требованиям к хостам к поддержке определённых параметров.
· RFC‑1721. Анализ протокола RIP версии 2.
· RFC‑1722 (STD 0057). Протокол RIP версии 2, предписание к применению.
· RFC‑1724. Протокол RIP версии 2, расширение по MIB (база управляющей информации – management information base).
· RFC‑2080. Спецификации протокола RIP для IPv6.
· RFC‑2082. Протокол RIP версии 2, проблемы аутентификации с использованием MD5 (Message Digest 5) – 128‑битный алгоритмом хеширования, разработанный в 1991 году. MD5 предназначен для создания «отпечатков» или «дайджестов» сообщений произвольной длины.
· RFC‑2092. Спецификация для автоматически запускающегося протокола RIP (triggeredRIP).
· RFC‑2453 (STD 0056). Общее описание протокола второй версии.
Существуют две версии протокола RIP: RIP‑1 и RIP‑2. Версия 2 имеет некоторые усовершенствования, как то: возможность маршрутизации сетей по модели CIDR (кроме адреса сети передается и маска), поддержка мультикастинга, возможность использования аутентификации RIP‑сообщений и др.
В протоколе RIP имеются два типа сообщений, которыми обмениваются маршрутизаторы:
· ответ (response) – рассылка вектора расстояний;
· запрос (request) – маршрутизатор (например, после своей загрузки) запрашивает у соседей их маршрутные таблицы или данные об определенном маршруте.
Формат сообщений обоих типов одинаков:
Поля, помеченные знаком *, относятся к версии 2; в сообщениях RIP‑1 эти поля должны быть обнулены.
Сообщение RIP состоит из 32‑битного слова, определяющего тип сообщения и версию протокола (плюс «Routing Domain» в версии 2), за которым следует набор из одного и более элементов вектора расстояний. Каждый элемент вектора расстояний занимает 5 слов (20 октетов) (от начала поля «Address Family Identifier» до конца поля «Metric» включительно). Максимальное число элементов вектора – 25, если вектор длиннее, он может разбиваться на несколько сообщений.
· Поле «Command» определяет тип сообщения: 1 – request, 2 – response; поле «Version» – версию протокола (1 или 2).
· Поле «Address Family Identifier» содержит значение 2, которое обозначает семейство адресов IP; другие значения не определены. Поля «IP address» и «Metric» содержат адрес сети и расстояние до нее.
Дополнительно к полям версии 1 во второй версии определены следующие.
· «Routing Domain» – идентификатор RIP‑системы, к которой принадлежит данное сообщение; часто – номер автономной системы. Используется, когда к одному физическому каналу подключены маршрутизаторы из нескольких автономных систем, в каждой автономной системе поддерживается своя таблица маршрутов. Поскольку сообщения RIP рассылаются всем маршрутизаторам, подключенным к сети, требуется различать сообщения, относящиеся к «своей» и «чужой» автономным системам.
· «Route Tag» – используется как метка для внешних маршрутов при работе с протоколами внешней маршрутизации.
· «Subnet Mask» – маска сети, адрес которой содержится в поле IP address. RIP‑1 работает только с классовой моделью адресов.
· «Next Hop» – адрес следующего маршрутизатора для данного маршрута, если он отличается от адреса маршрутизатора, пославшего данное сообщение. Это поле используется, когда к одному физическому каналу подключены маршрутизаторы из нескольких автономных систем и, следовательно, некоторые маршрутизаторы «чужой» автономной системы физически могут быть достигнуты напрямую, минуя пограничный (логически подключенный к обеим автономным системам) маршрутизатор. Об этом пограничный маршрутизатор и объявляет в поле «Next Hop».
Адрес 0.0.0.0 в сообщении типа «ответ» обозначает маршрут, ведущий за пределы RIP‑системы. В сообщении типа «запрос» этот адрес означает запрос информации о всех маршрутах (полного вектора расстояний). Указание в сообщении типа «запрос» адреса конкретной сети означает запрос элемента вектора расстояний только для этой сети – такой режим используется обычно только в отладочных целях.
Аутентификация может производиться протоколом RIP‑2 для обработки только тех сообщений, которые содержат правильный аутентификационный код. При работе в таком режиме первый 20‑октетный элемент вектора расстояний, следующий непосредственно за первым 32‑битным словом RIP‑сообщения, является сегментом аутентификации. Он определяется по значению поля «Address Family Identifier», равному в этом случае 0xFFFF. Следующие 2 октета этого элемента определяют тип аутентификации, а остальные 16 октетов содержат аутентификационный код. Таким образом, в RIP‑сообщении с аутентификацией может передаваться не 25, а только 24 элемента вектора расстояний, которые следуют за сегментом аутентификации. К настоящему моменту надежного алгоритма аутентификации для протокола RIP не разработано; стандартом определена только аутентификация с помощью обычного пароля (значение поля «Тип» равно 2).
Для каждой записи в таблице маршрутов существует время жизни, контролируемое таймером. Если для любой конкретной сети, внесенной в таблицу маршрутов, в течение 180 с не получен вектор расстояний, подтверждающий или устанавливающий новое расстояние до данной сети, то сеть будет отмечена как недостижимая (расстояние равно бесконечности). Через определенное время модуль RIP производит «сборку мусора» – удаляет из таблицы маршрутов все сети, расстояние до которых бесконечно.
При получении сообщения типа «ответ» для каждого содержащегося в нем элемента вектора расстояний модуль RIP выполняет следующие действия:
· проверяет корректность адреса сети и маски, указанных в сообщении;
· проверяет, не превышает ли метрика (расстояние до сети) бесконечности;
· некорректный элемент игнорируется;
· если метрика меньше бесконечности, она увеличивается на 1;
· производится поиск сети, указанной в рассматриваемом элементе вектора расстояний, в таблице маршрутов;
· если запись о такой сети в таблице маршрутов отсутствует и метрика в полученном элементе вектора меньше бесконечности, сеть вносится в таблицу маршрутов с указанной метрикой; в поле «Следующий маршрутизатор» заносится адрес маршрутизатора, приславшего сообщение; запускается таймер для этой записи в таблице;
· если искомая запись присутствует в таблице с метрикой больше, чем объявленная в полученном векторе, в таблицу вносятся новые метрика и, соответственно, адрес следующего маршрутизатора; таймер для этой записи перезапускается;
· если искомая запись присутствует в таблице и отправителем полученного вектора был маршрутизатор, указанный в поле «Следующий маршрутизатор» этой записи, то таймер для этой записи перезапускается; более того, если при этом метрика в таблице отличается от метрики в полученном векторе расстояний, в таблицу вносится значение метрики из полученного вектора;
· во всех прочих случаях рассматриваемый элемент вектора расстояний игнорируется.
Сообщения типа «ответ» рассылаются модулем RIP каждые 30 сек. по широковещательному или мультикастинговому (только RIP‑2) адресу; рассылка «ответа» может происходить также вне графика, если маршрутная таблица была изменена (triggered response). Стандарт требует, чтобы triggered response рассылался не немедленно после изменения таблицы маршрутов, а через случайный интервал длительностью от 1 до 5 с. Эта мера позволяет несколько снизить нагрузку на сеть.
В каждую из сетей, подключенных к маршрутизатору, рассылается свой собственный вектор расстояний, построенный с учетом дополнения 1 (1А), сформулированного выше в п. 4.2.1. Там, где это возможно, адреса сетей агрегируются (обобщаются), то есть несколько подсетей с соседними адресами объединяются под одним, более общим адресом с соответствующим изменением маски.
В случае triggered response посылается информация только о тех сетях, записи о которых были изменены.