Lesson_1_Dyn_IP

КОМПЬЮТЕРНАЯ АКАДЕМИЯ «ШАГ»	2009

того, чтобы случайно потерянные RIP пакеты не приводили к ложному удалению записей из маршрутных таблиц. Так же, можно одновременно уменьшить оба таймера. Но в этом случае будет другая проблема - чем меньше таймер между рассылками вектора расстояний, тем больший трафик порождает в сети протокол RIP, а если вспомнить, что вектор расстояний может быть весьма велик (содержать в себе достаточно много сетей), становиться ясно, что одновременное уменьшение обоих таймеров так же весьма нежелательно. Итого: таймер между рассылками вектора расстояний должен быть как можно больше (для уменьшения трафика), таймер удаления записей должен быть как можно меньше, но при этом он должен быть заметно больше первого таймера! Таким образом, возникли противоречия требований, указывающих на невозможность решения данной задачи. Данные противоречия не являются проблемой протокола RIP как такового, но указывают на слабые места самого дистанционно векторного алгоритма.

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

Итак, пусть у маршрутизатора R1 отказала сеть 1.0.0.0. Маршрутизатор R1 удаляет эту запись из своей таблицы маршрутизации, так как абсолютно уверен

КОМПЬЮТЕРНАЯ АКАДЕМИЯ «ШАГ»	2009

в том, что она отказала, и перестает включать эту сеть в рассылаемые вектора расстояний.

Таблица маршрутизации маршрутизатора R1 принимает вид:

Сеть

Шлюз

Метрика

2.0.0.02.0.0.1 1

7.0.0.07.0.0.1 1

3.0.0.07.0.0.2 2

4.0.0.07.0.0.2 2

8.0.0.07.0.0.2 2

5.0.0.07.0.0.2 3

6.0.0.07.0.0.2 3

Маршрутизатор R2 по-прежнему думает, что эта сеть доступна через маршрутизатор R1 и будет думать так в течение, еще по меньшей мере 150 (максимум 180) секунд. Маршрутизатор R2 разумеется не исключает эту сеть из рассылаемых векторов расстояний в течение всего этого времени, поэтому в очередной раз маршрутизатор R2 рассылает через интерфейс 7.0.0.2 рассылает свой вектор расстояний следующего вида:

Сеть Метрика

3.0.0.01

4.0.0.01

8.0.0.01

1.0.0.02

2.0.0.02

5.0.0.02

6.0.0.02

Из этого вектора расстояний маршрутизатор R1 делает вывод, что сеть 1.0.0.0 доступна через маршрутизатор R2! Действительно, в соответствии с рассмотренной выше логикой, у маршрутизатора R1 нет маршрута в сеть 1.0.0.0, а сосед объявляет о доступности этой сети с метрикой 2, т.е. самому маршрутизатору R1 сеть 1.0.0.0 будет доступна с метрикой 3 через интерфейс маршрутизатора R2, а именно через 7.0.0.2. Но сам R2 знает о доступности 1.0.0.0 только по недоразумению, обманывая тем самым маршрутизатор R1! Более того, в таблице маршрутизации маршрутизатора R2, маршрут в сеть 1.0.0.0 лежит через 7.0.0.1, а у маршрутизатора R1 маршрут в эту сеть будет лежать через 7.0.0.2, т.е. маршрутизаторы R1 и R2 будут передавать друг другу пакеты в сеть 1.0.0.0 до тех пор, пока у этих пакетов не истечет TTL, заполняя тем самым пропускную способность сети 7.0.0.0! Таким образом, мы видим, что имеет место маршрутная петля, крайне не желательное явления в составной сети. Проблема даже не в том, что пакеты не попадут в сеть 1.0.0.0, она ведь все равно не доступна, проблема в том, что пропускная способность сети 7.0.0.0 будет истощаться, что совершенно не допустимо.

Проанализируем, как долго живет данная маршрутная петля. Примерно через 180 секунд после того, как маршрутизатор R1 перестал заявлять о доступности сети 1.0.0.0 с метрикой 1, маршрутизатор R2 «забудет», что эта сеть доступна ему с метрикой 2 и вычеркнет запись о сети 1.0.0.0 из своей таблицы маршрутизации. НО! Маршрутизатор R1, к тому времени, уже давно знает, что сеть 1.0.0.0 доступна ему с метрикой 3. Эту информацию он включает в рассылаемый вектор расстояний, и как только маршрутизатор R2 забудет о

КОМПЬЮТЕРНАЯ АКАДЕМИЯ «ШАГ»	2009

доступности сети 1.0.0.0 с метрикой 2, его сосед – маршрутизатор R1 сообщит ему о доступности этой сети с метрикой 3, т.е. сам маршрутизатор R2 будет полагать эту сеть доступной с метрикой 4! Таким образом, маршрутизаторы будут обманывать друг друга очень долго: через 180 секунд R1 забудет о доступности 1.0.0.0 с метрикой 3, но получит сведения о доступности этой сети от R2 с метрикой 4, т.е. сам будет думать, что сеть 1.0.0.0 доступна через R2 с метрикой 5. Так будет продолжаться до тех пор, пока метрика не станет равной 16, а эта метрика в RIP считается недостижимой. Через сколько времени это произойдет? Практически сразу после отказа сети 1.0.0.0 маршрутизатор R1 получит информацию о ее доступности с метрикой 3 от маршрутизатора R2 и с этого момента каждый 180 секунд пара R1 и R2 увеличивает метрику маршрута в сеть 1.0.0.0 на 1. Таким образом, еще 13 раз по три минуты пройдет до тех пор, пока один из маршрутизаторов не заявит другому о том, что сеть 1.0.0.0 доступна ему с метрикой 15. Следовательно, получивший это сообщение сделает вывод о доступности ему этой сети с метрикой 16, т.е. о недоступности сети (метрика 16 означает в RIP недоступность сети). Следовательно, маршрутная петля существовала в сети около 36 минут, причем независимо от диаметра сети

– даже если в сети два маршрутизатора, время жизни петли не завит от количества маршрутизаторов и переходов в сети и всегда будет порядка 36 минут!

Приведенный выше пример указывает, что протокол RIP содержит важнейший недостаток - между соседними маршрутизаторами могут возникать маршрутные петли в случае отказа одной из сетей, причем время жизни такой петли КРАЙНЕ велико!

Рассмотрим метод борьбы с этой проблемой, который называется расщепление горизонта (Split Horizon). «Split horizon» - это механизм, препятствующий посылке информации тому маршрутизатору, от которого эта информация получена. Механизм имеет два варианта реализации. Первый

«simple split horizon», или «split horizon» заключается в том, что информация не посылается тому маршрутизатору, от которого она получена. В нашем примере: маршрутизатор R2 не будет посылать информацию о сети 1.0.0.0 маршрутизатору R1.

Следующий метод предотвращения маршрутных петель называется «poisoned reverse». Отличается от первого тем, что информация посылается тому маршрутизатору, от которого она была получена, но в качестве метрики используется 16 – т. е. «недостижима». В нашем примере: маршрутизатор R2 посылает информацию о сети 1.0.0.0 маршрутизатору R1 с метрикой 16. Необходимо отметить два момента, которые следует учитывать при выборе этого механизма:

1.При использовании механизма «poisoned reverse» отработка изменений

втопологии будет происходить быстрее в силу того, что маршрутизаторы будут получать информацию о «недостижимости» сети друг от друга достаточно быстро. При использовании «split horizon» неправильные маршруты будут исключаться только по прошествии таймаута.

2.Механизм «poisoned reverse» подразумевает внесение дополнительной информации в update-сообщения по сравнению со«split horizon». В большой сети с большим количеством подсетей и маршрутизаторов соединенных каналами с небольшой скоростью, это может оказаться ощутимым.

Совместное использование технологий Split-Horizon и Poison Reverse необходимо для предотвращения образования петель маршрутизации, которые

КОМПЬЮТЕРНАЯ АКАДЕМИЯ «ШАГ»	2009

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

Т.е. могут существовать ситуации, когда три или более маршрутизатора включены в процесс "взаимного обмана". Например, когда какой-либо маршрутизатор М1 полагает, что он имеет маршрут через маршрутизатор М2, маршрутизатор М2 через М3, М3 через М4, а М4 через М1. Для ускорения сходимости в подобных ситуациях служит технология Triggered Update. Эта технология требует, чтобы маршрутизатор немедленно посылал сообщения об обновлении своим соседям, если он обнаружил изменение в метрике маршрута. Сообщения должны быть посланы, даже если не пришло время для регулярных сообщений (update).

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

Маршруты, получаемые с помощью протокола RIP, проходят серию стадий в таблице маршрутизации:

UP - маршрут может находиться в данной стадии, если он достижим с определенной (меньше 16) метрикой. Маршрут остается в данном состоянии в течение шестикратного интервала времени между периодичной посылкой сообщений об обновлении. Это значение известно как таймер маршрута. Данный таймер сбрасывается каждый раз, когда приходит новое сообщение об обновлении для данного маршрута. По истечении этого таймера маршрут более не рассматривается как корректный и переводится в стадию Garbage-Collection;

Hold-Down - маршрут, находящийся в стадии UP, переходит в данную стадию, если маршрутизатор получил сообщение об обновлении маршрута с метрикой, равной бесконечности, от маршрутизатора, который явился источником информации об этом маршруте. Маршрут будет оставаться в данной стадии весь период времени, равный четырехкратному интервалу посылки сообщений об обновлении. Это значение известно как Hold-Down Timer. В этой стадии маршрутизатор будет игнорировать информацию о сети на промежутке времени, следующем за получением сообщения, информирующего о том, что и эта сеть недостижима. Такой механизм

КОМПЬЮТЕРНАЯ АКАДЕМИЯ «ШАГ»	2009

предотвращения маршрутных петель в недостижимые сети называется

Hold-Down.

Когда таймер Hold-Down обнулится, маршрут перейдет в стадию GarbageCollection. Если сообщение, содержащее информацию об этом маршруте с метрикой меньше 16, получено от исходного маршрутизатора до обнуления таймера, этот маршрут перейдет в стадию UP. Цель этого состояния - в позволении всем другим маршрутизаторам в автономной системе получать информацию о том, что маршрут не функционирует;

Garbage-Collection. Когда таймер маршрута, который был в стадии UP, обнулился, он переходит в стадию Garbage-Collection. Маршрут может оставаться в этой стадии на время, равное четырехкратному интервалу обновления. Это значение времени называется Garbage-Collection Timer. В этой стадии соседи могут извещать маршрутизатор, что сеть более недостижима. В течение этой стадии маршрут с метрикой, равной 16, включается во все сообщения об обновлении, посылаемые этим маршрутизатором. Это вызывает удаление данного маршрута из списка возможных, на соседних маршрутизаторах. Если не получено сообщение об обновлении до обнуления таймера Garbage-Collection, маршрут удаляется из таблицы маршрутизации. Если соседний маршрутизатор информирует об этом маршруте с метрикой меньше 16 до обнуления таймера, новый маршрут будет заменять маршрут, подготовленный для удаления, и в этом случае таймер обнуляется.

Обмен маршрутной информацией между двумя RIP-маршрутизаторами порождает следующий трафик:

Запрос:

КОМПЬЮТЕРНАЯ АКАДЕМИЯ «ШАГ»	2009

Ответ:

КОМПЬЮТЕРНАЯ АКАДЕМИЯ «ШАГ»	2009

В случае если настроен RIP первой версии, взаимодействие имеет следующий вид:

Запрос:

КОМПЬЮТЕРНАЯ АКАДЕМИЯ «ШАГ»	2009

Ответ:

Рассмотрим формат пакета для RIP v1 и RIP v2.

Для передачи сообщений RIP использует протокол UDP. Для посылки и приема сообщений в обеих версиях RIP используется UDP порт 520. Это означает, что сообщения содержат в качестве порта источника и назначения 520. Сообщения RIP, являющиеся ответом на запрос, в качестве порта назначения содержат порт, с которого был получен запрос. Запросы могут посылаться с порта, отличного от стандартного для RIP, но всегда должны адресоваться на стандартный порт 520. Заголовок RIP имеет вид:

0	8	16	32
	команда	версия	должно быть установлено в 0
		RTE (Запись маршрута - route entry)

Пакет RIP может содержать от 1 до 25 RTE. Поле RTE имеет следующий формат

0		16		32
	address family identifier (AFI)		должно быть установлено в 0
	IPv4-адрес
	должно быть установлено в 0
	должно быть установлено в 0
		метрика
	Каждое сообщение содержит RIP-заголовок. RIP-заголовок содержит
идентификаторы команды и версии.

КОМПЬЮТЕРНАЯ АКАДЕМИЯ «ШАГ»	2009

Версия - поле содержит номер версии.

Команда - поле команды указывает функциональное назначение сообщения. Версии RIP 1 и 2 используют следующие виды команд:

1запрос (Request) Запрос, направляемый какой-либо системе для получения полной таблицы маршрутизации или ее части.

2ответ (Response) Сообщение, содержащее полную таблицу маршрутизации или ее часть.Данный тип сообщения может быть ответом на запрос , или может посылаться на регулярной основе

AFI - поле AFI указывает тип используемого адреса. Для RIPv1 поддерживается только AF_INET = 2.

IPv4-адрес – содержит сообщаемый маршрут в сеть.

Метрика - поле содержит целое значение от 1 до 15 (включительно). Значение 16 означает, что сеть «недостижима», т. е. пакеты, предназначенные этой сети, переданы быть не могут.

Сообщения типа 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 не применяется. Причина такой логики заключается в том, что запросы о конкретных сетях могут использоваться для различных целей, а не только для построения таблиц маршрутизации. Запросы

КОМПЬЮТЕРНАЯ АКАДЕМИЯ «ШАГ»	2009

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

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

Сообщение типа Response может быть получено в следующих случаях:

-ответ на конкретный запрос.

-регулярный update.

-triggered update, вызванный изменением таблицы маршрутизации. Независимо от того, чем вызван Response, механизм его обработки

остается одним и тем же. Поскольку в результате обработки Response существует возможность изменения таблицы маршрутизации, сам Response должен быть тщательно проверен на корректность. Если в качестве UDP-порта назначения пакета используется не RIP-порт, сообщение должно игнорироваться. Проверяется и IP-адрес источника: если источник пакета находится не в непосредственно подключенной сети, то такой пакет игнорируется. Кроме того, производится проверка на то, является ли адрес источника одним из собственных адресов маршрутизатора – это возможно, если несколько интерфейсов маршрутизатора подключены к одной broadcast-сети. После проверки Response на корректность, поля RTE пакета обрабатываются по очереди запись – за – записью. Каждая RTE проверяется на корректность. В случае некорректности какой-либо записи она должна игнорироваться. Сообщение о том, что была получена некорректная запись, должно быть внесено

влогфайл (log file) маршрутизатора. Базовые проверки должны содержать:

-проверка на корректность адреса назначения – поле IP-адреса. Адрес должен быть unicast’ным, не быть нулевым или вида 127.х.х.х.

-проверка корректность метрики. Метрика должна находиться в диапазоне от 1 до 16, включительно.

В том случае, если RTE не прошла какую-либо проверку, она должна игнорироваться, известие об этом должно помещаться в логфайл.

Итак, если все проверки для RTE пройдены, то для дальнейшей обработки необходимо добавить 1 к метрике cost той сети, с которой RTE была получена. Если результат получается больше, чем 16, использовать в качестве результата 16 (infinity - бесконечность).

Далее, проверяется таблицу маршрутизации на предмет наличия записи, адрес которой в точности совпадает с полученным в RTE. Если такового не найдено, то создается новая запись в соответствии с информацией, полученной

вRTE (исключая те случаи, когда метрика = 16). Добавление записи в таблицу маршрутизации состоит в следующем:

• Запись в поле «Адрес назначения» адреса, содержащийся в полученном

RTE.

• Запись в поле «метрика» полученное в результате расчетов значение.

• Запись поле «next hop» адреса маршрутизатора, от которого получен update содержащий данное RTE.

• Запуск timeout (времени жизни маршрута). Если для данного маршрута работает garbage-collection, сбросить данный таймер.

• Установить флаг изменения маршрута, или записи – route change.

• Передать информацию в Output processing на trigger update.