Если мы наберем в поисковике фразу "RFC RIP", мы тут же найдем RFC 1058, в котором полностью описана история, работа и реализация такого протокола.
Этот документ описывает работу RIP в routed, стандартном юниксовом демоне динамической маршрутизации - самой первой практической реализации этого протокола. )
RIP является протоколом внутренней маршрутизации, основанном на дистанционно-векторном протоколе Беллмана-Форда.
Протокол ограничен максимальным расстоянием в 15 хопов (маршрутизаторов) между конечными сетями и не распространяет в своих обновлениях маски сети, то есть не поддерживает такие технологии как VLSM и CIDR. Кроме того, его использование может приводить к "маршрутным петлям", эффект от которых уменьшается только наличием поля TTL в заголовках IP-пакетов. Кроме того, мерой стоимости маршрута (и основанием для выбора между несколькими маршрутами в одну сеть) является только число хопов. RIP не может учитывать ни загрузку каналов, ни их пропускную способность.
В своей работе RIP использует udp-дейтаграммы, рассылаемые широковещательно с порта 520 на порт 520. Дейтаграмма имеет очень простой формат, в котором, к тому же, заложены возможности развития протокола. Фиксированная часть заголовка содержит только поле версии и тип дейтаграммы - запрос или ответ. Остальную часть занимают записи маршрутов, которые состоят из типа протокола, чья информация переносится (для IP это 2), адреса сети назначения, пары забитых нулями зарезервированных полей и поля метрики маршрута. Максимальный размер сообщения составляет 512 байт, что означает, что переносить в нем можно только 25 маршрутных записей (но это не значит, что больше 25 маршрутов вообще переносить нельзя - вполне себе можно делать это в отдельных сообщениях).
Как работает маршрутизатор с протоколом RIP.
Сразу после включения маршрутизатор рассылает широковещательно пакеты, содержащие его таблицу маршрутизации, в которой будут находиться только маршруты в подключенные сети. При этом для каждой записи он будет указывать метрику 1. То же самое делают и его соседи. Кроме того, он прослушивает сеть на предмет появления таких же сообщений от других маршрутизаторов и анализирует их.
Если в сообщении встречается маршрут в неизвестную до этого сеть, маршрутизатор добавляет ее в собственную таблицу маршрутизации.
Если в сообщении встречается маршрут в уже известную сеть, и его метрика меньше метрики уже имеющегося маршрута - он заменяет запись в своей таблице на новую. Если метрика больше - считается, что этот маршрут хуже и добавлять его не стоит. ) Поэтому он просто проигнорирует такую запись.
После того, как пройдет 30 секунд после первого обновления, маршрутизаторы повторяют эту процедуру снова, рассылая свои таблицы маршрутизации широковещательно. При этом стоит заметить, что полученные от соседей маршруты в подключенные к ним сети они будут рассылать уже с метрикой, большей на единицу, то есть равной двум. Это будет продолжаться, пока все маршрутизаторы в сети не будут иметь маршруты во все известные сети.
Время, которое будет затрачено на полное построение всех таблиц маршрутизации на всех маршрутизаторах в сети называется временем сходимости сети (convergence), и, с учетом 30-секундного интервала обмена маршрутами, для сети из трех маршрутизаторов, это время будет равно максимум 30 секундам, в случае если все маршрутизаторы просто включили одновременно. Для сети, в которой между двумя максимально удаленными сетями находится 16 маршрутизаторов (предел для RIP) это время составит уже 7 минут. Это также худшее время сходимости при добавлении новой сети.
На самом деле таймер обновления может и не быть равен ровно 30 секундам, его даже рекомендуют увеличивать на небольшое случайное число при каждом старте таймера, чтобы в сетях типа Ethernet рассылка обновлений не вызывала коллизий.
Нам необходимо не только отслеживать появление новых сетей, но и исчезновение старых. Механизм для этого есть - для каждого маршрута, полученного через протокол RIP, в маршрутизаторе создается отдельный таймер, по истечении которого маршрут удаляется. Это время по-умолчанию установлено в 180 секунд, чтобы не считать маршруты недоступными в случае, если какие-то 1-4 пакета с обновлениями просто потеряются в сети.
Но стоит только промоделировать ситуацию с "отвалившейся" сетью на бумаге или на реальном железе, мы увидим, что в классическом варианте RIP она разрешается очень плохо. )
Дело в том, что маршрутизатор, сеть на котором была удалена из таблицы маршрутизации, тут же получит ее от соседа, хотя и с большей метрикой. И завернет весь траффик в нее - на соседа, и тут же образуется маршрутная петля. В течение 180 секунд, пока его сосед будет считать этот маршрут еще действительным, он будет пересылать пакеты в нее нашему роутеру, а он будет отсылать их обратно соседу - ведь маршрут в эту сеть он получил именно от него! ).
Но дальше ситуация становится еще более печальной. Как только маршрут удалится из таблицы второго маршрутизатора, он снова появится там с метрикой, выросшей на единицу - так как получит его сразу от соседей, образовав новые маршрутные петли. Ситуация будет развиваться в худшую сторону, образуя петли во всей сети, пока, наконец, метрика маршрута не станет равна 16. Это пометит маршрут как недоступный, и приведет к удалению его из таблицы маршрутизации (конечно, только если этот маршрут добавлен RIP). Таким образом, сеть все-таки сойдется, в самом плохом случае - через 48 минут. Это уже не такое приемлемое время, как 7 минут на "холодный старт" сети, с учетом того что все каналы связи будут заняты пересылкой пакетов в маршрутных петлях, вместо передачи полезных данных. Как раз тот случай, когда в математике все хорошо (сеть сошлась), но на практике неприемлемо (слишком долго сходилась).
С целью разрешить проблему сходимости сети для случаев, когда ранее доступные сети становятся недоступными, в RIP было добавлено два механизма.
1. Расщепление горизонта. Маршрутизатор анализирует маршруты перед отправкой и не рассылает через свои интерфейсы те маршруты, которые он получил через них же. Иными словами, если сеть отваливается, маршрутизатор не получит от соседа обновление через 180 секунд о маршруте, который он сам же ему отослал и петля образовываться не будет.
2. Отравление маршрутов или poisoned reverse. ) Маршрутизатор использует технику расщепления горизонта, но вместо того чтобы совсем не рассылать маршруты, полученные от соседей, им же - рассылает их с метрикой 16, сразу сообщая им о недоступности сети.
На самом деле в RIP может быть и больше таймеров - но особенности реализации все-таки присутствуют, как и умолчательные значения. Например, Cisco IOS после падения маршрута в первые 180 секунд считает его рабочим, далее - деактивирует, но все еще держит в таблице - причем, как "possibly down", с метрикой 16, пока не истечет еще один таймер - таймер захоронения. Опять же, чтобы не дай боже кто-нибудь не прислал его снова и не создал новую петлю )
Так что, как видно, расещпление горизонта - настолько нужная в RIP методика, что в большинстве современных RIP-маршрутизаторов она включена по-умолчанию. )
Ну и так как практически в любой ОС есть поддержка RIP - встроенная или нет - есть, что показывать в плане настроек.
Комментариев нет:
Отправить комментарий