Меню
Контакты
109147, Москва, ул.Воронцовская, 35Б, корп.2 офис.11, 4 этаж
Пн-Пт: с 9-00 до 17-00   Сб-вс: выходной
Интернет-магазин
сетевого оборудования
Москва +7 (495) 103-41-03 +7 (915) 420-28-94
109147, Москва, ул.Воронцовская, 35Б, корп.2 офис.11, 4 этаж
Пн-Пт: с 9-00 до 17-00   Сб-вс: выходной
Заказать звонок

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

 24 Июл 2018    MikroTik, О настройках и установке оборудования производителя Mikrotik, Практика и программирование MikroTik, Scripts

Введение

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

Протокол RIP (Routing Information Protocol)

Протокол 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 не реализована:

Параметр
RIPv1
RIPv2
Маршрутная информация
классовая
бесклассовая
Адрес рассылки
255.255.255.255
224.0.0.9
Транспортный протокол
UDP:520
UDP:520
Split Horizon
да
да
Triggered update
да
да
Route poisoning
да
да
Poison reverse
да
да

Меню настройки RIP

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

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

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

ПараметрДиапазон значенийЗначение по умолчаниюОписание
distribute-default always | if-installed | never never анонсирование маршрута по умолчанию
redistribute-static yes | no no анонсирование статических маршрутов
redistribute-connected yes | no no анонсирование непосредственно подключенных сетей
redistribute-ospf yes | no no анонсирование маршрутов, полученных по OSPF
redistribute-bgp yes | no no анонсирование маршрутов, полученных по BGP
metric-default 1-15 1 метрика анонсируемого маршрута по умолчанию
metric-static 1-15 1 метрика анонсируемых статических маршрутов
metric-connected 1-15 1 метрика анонсируемых непосредственно подключенных сетей
metric-ospf 1-15 1 метрика анонсируемых OSPF-маршрутов
metric-bgp 1-15 1 метрика анонсируемых BGP-маршрутов
update-timer 5s - 30m 30s период рассылки маршрутной информации
timeout-timer 5s - 30m 3m интервал времени, по истечении которого маршрут будет помечен как invalid и ему будет присвоена метрика 16
garbage-timer 5s - 30m 2m интервал времени, по истечении которого маршрут, помеченный как invalid, будет удалён из таблицы маршрутизации
routing-table   main имя таблицы маршрутизации, в которую будут экспортированы маршруты, полученные по RIP

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

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

Параметр Диапазон значений Значение по умолчанию Описание
interface   all перечень интерфейсов, к которым будет применяться настройки, указанные в данном разделе
send v1 | v1-2 | v2 v2 версия протокола в отправляемых служебных сообщенях
receive v1 | v1-2 | v2 v1-2 версия протокола в принимаемых служебных сообщениях
passive yes | no no режим пассивного интерфейса (служебные сообщения не будут рассылаться с этого интерфейса, однако приём сообщений осуществляться будет)
authentication none | simple | md5 none метод аутентификации
authentication-key     ключ аутентификации при простой аутентификации
key-chain     имя ключа, при аутентификации с помощью md5
in-prefix-list     имя фильтра входящей маршрутной информации
out-prefix-list     имя фильтра исходящей маршрутной информации

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

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

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

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

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

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

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

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

Принципы работы протокола RIP

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

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

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

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

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

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

R1:

R1

R2:

R2

R3:

R3

R4:

R4

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

Непосредственно подключенные сети в таблице маршрутов RIP на R1
Рисунок 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 совершают аналогичные операции:

Маршрутная информация полученная 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:

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

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

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

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

Адаптация к изменениям в сети

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

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

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

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

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

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

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

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

R1:

R1

R2:

R2

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

Листинг маршрутов RIP на R2

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

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

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

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

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

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

Схема сети для демонстрации процесса адаптации в RIP

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

Листинг маршрутов RIP на R2

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

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

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

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

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

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

Рисунок 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, поскольку оба протокола относятся к классу протоколов внутренней маршрутизации.

Источник