Применение RIP в MikroTik RouterOS

В цикле прошлых статей был подробно рассмотрен протокол OSPF и его реализация в RouterOS. В данной статье будет описан протокол RIP и его сравнение с OSPF. Поскольку оба протокола выполняют одинаковую функцию — распространение маршрутной информации в рамках AS, то теоретическое описание ряда понятий будет опущено, т. к. рассмотрено в прошлых статьях.

Протокол RIP (Routing Information Protocol — протокол маршрутной информации) является внутренним протоколом маршрутизации дистанционно-векторного типа, добавляющий в таблицу маршрутов только лучший путь к сети.

В качестве метрики используется число хопов (число маршрутизаторов, через которое проходит пакет до достижения сети назначения). Диапазон значений метрики от 1 до 16, причём connected-сети по умолчанию добавляются в таблицу маршрутизации с метрикой 1, а метрика, равная 16, считается недостижимой и такие маршруты считаются unreacheable.

Подобное условие ограничивает применение протокола только в небольших сетях. Следует иметь в виду, что увеличение метрик относительно значений по умолчанию, для connected-, static-, default- или redistribute-маршрутов уменьшает возможные масштабы сети.

Маршруты, полученные по протоколу RIP, встраиваются в таблицу маршрутизации со значением Distance=120, что больше, чем у OSPF, поэтому маршрутная информация протокола RIP является менее приоритетной, чем OSPF, а тем более относительно статических и непосредственно подключенных маршрутов.

RouterOS поддерживает первую (RFC 1058) и вторую (RFC 2453) версии протокола RIP. Основным отличием первой и второй версий является поддержка второй версией бесклассовых сетей, т. е. передачу в служебных пакетах масок сетей.

Также следует упомянуть о существовании третьей версии протокола — RIPng (RIP next generation — протокол маршрутной информации следующего поколения), предназначенного для ipv6-сетей, однако его поддержка в RouterOS не реализована:

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

Настройки протокола (/routing rip)

Для изменения глобальных настроек протокола следует перейти в раздел routing rip:

Настройки интерфейса (/routing rip interface)

Для тонкой настройки интерфейсов, участвующих в работе RIP, следует скорректировать настройки в разделе /routing rip interface:

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

Настройка сетей (/routing rip network)

В данном меню, подобно аналогичному меню в настройках OSPF, определяется список интерфейсов, на которых будет осуществляться приём/передача служебных сообщений протокола RIP. Рассылка маршрутной информации будет производиться на всех интерфейсах, ip-адрес которых попадает под указанный диапазон. В протоколе реализована проверка маски сети, поэтому маска, определённая в данном разделе и указанная на интерфейсе, должны совпадать.

Следует отметить, что по умолчанию будут анонсироваться только сети, указанные в данном разделе, аналогично протоколу OSPF. Дополнительно инжектировать в RIP маршруты можно, выбрав параметры редистрибьюции в меню routing rip.

Для PtP-интерфейсов должен быть указан ip-адрес дальней стороны.

Настройка соседей (/routing rip neighbor)

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

Следует иметь в виду, что протокол RIP, в отличие от OSPF, не устанавливает отношений соседства, поэтому динамический список устройств, с которыми происходит обмен маршрутной информации в данном меню отображаться не будет.

Для пояснения принципов работы протокола RIP, рассмотрим следующую схему:

Рисунок 1. Схема сети для пояснения принципов работы RIP

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

В схеме будет рассмотрена вторая версия протокола RIP, однако принципы работы первой и второй версии схожи. Для того, чтобы подтвердить работоспособность RIPv2 с бесклассовыми сетями, каналам связи между маршрутизаторами выделены подсети с маской /25.

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

Конфигурация устройств

R1:

R2:

R3:

R4:

Возьмём за основу маршрутизатор R1. На первом этапе R1 анализирует непосредственно присоединённые сети и инжектирует их в таблицу маршрутов RIP с метрикой 1:

Рисунок 2. Непосредственно подключенные сети в таблице маршрутов RIP на R1

Следует отметить, что, поскольку сети 172.16.12.0/25 и 172.16.13.0/25 добавлены в меню /routing rip network, то они отображаются с флагом R, тогда как сеть 192.168.10.0/24 с флагом C.
На втором этапе R1 анонсирует соседним маршрутизаторам информацию, полученную на первом этапе. Маршрутизаторы R2 и R3 совершают аналогичные операции:

Рисунок 3. Маршрутная информация полученная R1 от R2 и R3

R2 и R3 передают маршруты R1 с метрикой=1. R1, получив маршрутную информацию, инкрементирует метрику и добавляет их в таблицу маршрутов RIP и таблицу маршрутизации. После добавления маршрутов, для каждого из них запускается таймер, равный timeout-timer, который подробнее будет рассмотрен ниже.

Следует отметить, что R2 и R3 также передают информацию о сетях 172.16.12.0/25 и 172.16.13.0/25, однако R1 отбрасывает их, поскольку в его таблице маршрутов уже есть эти сети с лучшей метрикой. Из этого правила есть исключение: в случае, если маршрут с худшей метрикой получен от того же устройства, то в таблицу маршрутов попадает более новая маршрутная информация.

На этом же этапе R2 и R3 получают от R4 маршрут к сети 192.168.40.0/24.

На третьем этапе R2 и R3 анонсируют для R1сеть 192.168.40.0/24, полученную на предыдущем этапе от R4:

Рисунок 4. Маршрутная информация о сети 192.168.40.0/24 на R1

Маршрут добавляется в таблицу маршрутов RIP с метрикой 3 и импортируется в таблицу маршрутизации. На рисунке 4 видно, что в таблицу маршрутов добавлена информация полученная от R2, однако R3 анонсировал эту сеть с точно такой же метрикой. В протоколе отсутствует механизм выбора лучшего маршрута при равных метриках, поэтому в таблицу будет добавлен маршрут, полученный первым — в рассмотренном случае R2 передал маршрутную информацию раньше, чем R3.

Для данной схемы сети хватило трёх этапов для того, чтобы достигнуть сходимости — на каждом из маршруторов присутствует информация о всех подсетях:

Рисунок 5. Таблица маршрутизации R4 после завершения процесса сходимости

В случае, если бы сеть была статична, то можно сказать, что функция RIP выполнена, однако для отслеживания изменений в сети устройства периодически, в соответствии с таймером update-timer, рассылают всю таблицу маршрутов RIP.

Маршрутизатор, получив в служебном сообщении информацию, которая уже присутствует в его таблице маршрутов RIP, сбрасывает timeout-timer в исходное состояние и заново начинает отсчёт времени. Таким образом, при настройках по умолчанию, каждые 30 секунд по сети заново рассылается вся таблица маршрутов RIP.

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

Для адаптации сети в первом случае маршрутизатор выставляет в служебных сообщениях метрику, равную 15, что при получении даёт недостижимый маршрут, а во втором случае устройства сети исключат маршрутную информацию только после истечения времени timeout-timer.

Для демонстрации процесса адаптации рассмотрим следующую схему:

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

Конфигурация устройств

R1:

R2:

Как видно на рисунке 7, маршрутизаторы успешно обменялись маршрутной информацией и R2 получил от R1 маршрут к сети 192.168.10.0/24 с метрикой 2:

Рисунок 7. Листинг маршрутов RIP на R2

Отключим интерфейс ether4 на R1 (команда /interface ether set ether4 disabled=yes) и оценим изменения на маршрутизаторе R2:

Рисунок 8. Листинг маршрутов RIP и таблицы маршрутизации на R2

R2, получив обновления от R1, оставляет маршрут к сети 192.168.10.0/24 с бесконечной метрикой, при этом удалив маршрут из таблицы маршрутизации. Маршрут будет храниться в таблице маршрутов RIP на протяжении garbage-timer, после чего будет удалён.

Теперь рассмотрим случай, когда R1 не может отправить обновления на R2, восстановив исходную конфигурацию предыдущего примера (команда /interface ether set ether4 disabled=no):

Разорвём связь между коммутаторами SW1 и SW2, отключив на SW2 интерфейс ether4 и проанализируем таблицу маршрутов RIP на R2:

Рисунок 10. Листинг маршрутов RIP на R2

R2 не получил обновления от R1 и маршрут к сети 192.168.10.0/24 остаётся в таблице маршрутизации до истечения timeout-timer (при настройках по умолчанию и худшем сценарии – 3 минуты):

Рисунок 11. Листинг маршрутов RIP и таблицы маршрутизации R2

По истечении timeout-timer маршруту присваивается метрика 16 и он остаётся в таблице маршрутов RIP на протяжении garbage-timer, из таблицы маршрутизации маршрут удаляется:

Рисунок 12. Листинг маршрутов RIP и таблицы маршрутизации R2

Поскольку RIP относится к дистанционно-векторным протоколам, то маршрутизаторы не владеют информацией о структуре сети, как в OSPF, передавая информацию, полученную от других маршрутизаторов с определённой метрикой.

Таким образом, устройства «несут ответственность» только за непосредственно подключенные сети. Негативной особенностью протокола RIP в изложенном алгоритме работы является вероятность появления ложных маршрутов. Для рассмотрения такой ситуации обратимся к схеме сети на рисунке 6.

Пусть R1 отправил update-сообщение для R2 и сразу после этого вышел из строя интерфейс ether4 – сеть 192.168.10.0/24 стала недоступна. R1 изменяет метрику для этой сети в своей таблице RIP на максимальную, однако сделает рассылку с обновлённой информацией для R2 только через update-timer, по умолчанию равный 30 секунд.

Поскольку таймеры протокола носят локальный характер и не синхронизированы между маршрутизаторами, то высока вероятность, что R2 сформирует update-сообщение для R1 до истечения update-timer. В этом update-сообщении R2 передаст информацию о том, что в его таблице маршрутов есть путь к сети 192.168.10.0/24 с метрикой 2 и, поскольку метрика будет лучше, чем бесконечная, R1 поместит её в таблицу маршрутов и импортирует в таблицу маршрутизации.

В этой ситуации, если хост сети 192.168.20.0/24 попытается передать пакет хосту в сети 192.168.10.0/24 (за исключением ситуации, когда dst-address=192.168.10.1), R2 отправит пакет в сторону R1, а R1 – в сторону R2. Пакет будет существовать до тех пор, пока его поле TTL не достигнет предельного значения 255, после чего будет отброшен.

Спустя timeout-timer, значение по умолчанию которого равно 3 минуты, R2 присваивает маршруту в сеть 192.168.10.0/24 бесконечную метрику, т.к. не получал update-сообщений с метрикой меньше 2. В этот момент R1 передаст R2 информацию о пути к данной сети с метрикой 3, а R2 инкрементирует значение метрики и поместит его в таблицу маршрутов RIP и таблицу маршрутизации.

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

Для того, чтобы предотвратить возникновение ложных маршрутов в протоколе RIP предусмотрен ряд защитных механизмов:

• Расщепление горизонта;
• Триггерные обновления;
• Замораживание изменений.

Расщепление горизонта

Метод расщепления горизонта заключается в том, что маршрутизаторы не отправляют в update-сообщениях информацию о маршрутах, полученных от этих устройств. Т.е. в рассмотренной ситуации с ложным маршрутом, R2 не передаёт R1 информацию о сети 192.168.10.0/24, поскольку эта информация получена от R1 и ложный маршрут не возникнет.

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

Так, если перенести рассмотренный случай с возникновением ложного маршрута на схему сети, представленную на рисунке 1, то R2 и R3 не будут передавать update-сообщения о сети 192.168.10.0/24, однако R4 будет анонсировать эту сеть одному из маршрутизаторов (R4 получит маршрут к сети либо от R2, либо от R3, в зависимости от того, кто ранее её анонсирует). Т.е. R4 будет анонсировать маршрут к сети 192.168.10.0/24 с метрикой 3 и данный маршрут распространится по всему RIP-домену.

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

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

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

Замораживание изменений

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

Протокол RIP, по сравнению с OSPF имеет ряд недостатков. Первым недостатком является долгое время адаптации протокола к изменениям в сети. Действительно, при настройках по умолчанию возможны ситуации, когда сеть адаптируется к изменениям спустя timeout-timer=3 минуты.

Использование RIP в связке с протоколом BFD, как это реализовано в OSPF, невозможно. Решением данной проблемы является уменьшение значений таймеров, заданных по умолчанию, однако следует иметь в виду, что снижение update-timer увеличит служебный трафик в сети, а малое значение timeout-timer может привести к ложным удалениям маршрутов, т.к. служебные сообщения передаются по UDP и какое-то из обновлений может быть потеряно, не дойдя до адресата.

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

Третьим недостатком является ограничение на размеры сети. Поскольку в качестве метрики RIP использует число хопов и это значение не может превышать 16, то это задаёт границу для числа возможных маршрутизаторов в сети. Кроме того, в отличие от OSPF, в котором использовались area, топология RIP никаким образом не структурируется, являясь одним RIP-доменом.

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

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

Таким образом, несмотря на недостатки, протокол RIP может быть использован в небольших сетях. Также, возможно использование протокола на периферии крупных сетей: если сеть имеет чёткую структуру с возможностью выделения трёх уровней – ядро, агрегация, доступ, то использование протокола RIP на уровне доступа с импортом маршрутов в другой протокол, например OSPF, на уровне агрегации является допустимым решением.

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