Lesson_1_Dyn_IP

Далее. Предположим, что найдена запись в таблице маршрутизации с адресом назначения, равным адресу назначения в полученном RTE. Если эта запись получена от того же маршрутизатора, что и RTE, и метрики равны, то необходимо перезапустить таймер timeout. Если эта запись получена от того же маршрутизатора, что и RTE, но метрики разные или полученная для записи метрика меньше, чем содержащаяся в таблице маршрутизации то:

•Поместить в запись таблицы маршрутизации новую метрику – а при необходимости и сменить адрес next hop – если он отличается от предыдущего .

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

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

•Если новая метрика – 16 (infinity), запустить процесс уничтожения записи, если нет – перезапустить timeout.

Процесс удаления записи запускается только в том случае, если метрика была изменена и приняла значения 16. Если метрика уже была равна 16, процесс удаления не запускается. Если получена запись, метрика и адрес которой совпадают с маршрутом, существующим в таблице маршрутизации, в принципе нет необходимости заменять существующую запись новой. Однако если существующая запись в таблице маршрутизации некоторое время не обновлялась (более нескольких периодов посылки update’ов), существует вероятность того, что с ней не все в порядке. В этом случае если получена информация о той же сети и с той же метрикой рекомендуется воспользоваться новой информацией. RFC 2453 рекомендует переключение на новую информацию в том случае, если запись в таблице маршрутизации не обновлялась половину времени от установленного timeout’а.

Для обоих типов сообщений в случае использования версии 1 остаток сообщения содержит перечень RTE. Каждый RTE содержит поле AFI, IPv4-адрес и метрику.

Формат пакета RIP v 2

Поле "Домен маршрутизации" используется вместе с полем "Следующий переход" для позволения нескольким автономным системам разделять одну физическую среду передачи.

Для аутентификации используется отдельный RTE. Это сделано по следующим причинам:

-аутентификация требуется для каждого отдельного сообщения;

-в заголовке пакета RIP недостаточно места для реализации схемы аутентификации.

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

аоставшаяся часть RTE будет содержать данные аутентификации. Таким образом, на данные остается 24 RTE. Если аутентификация не используется, ни один из RTE не должен содержать AFI, равное 0xFFFF. Начало сообщения RIP, использующего аутентификацию, будет вы глядеть следующим образом

RFC 2453 специфицирует использование только одной схемы аутентификации – использование простого нешифруемого пароля. Тип аутентификации – 2. 16 байт поля «данные аутентификации» содержат пароль. Пароль начинается с первого байта поля. Выравнивается, т.е. остаток поля, заполняется нулями.

Обычный RTE для RIP v2 имеет вид

IPv4-адрес

Маска подсети

Следующий переход

Метрика

Поля AFI, IP-адрес и метрика имеют то же значения и формируются тем же образом, что и для RIPv1.

Route tag (RT) – тэг маршрута. Поле RT является атрибутом, назначаемым записи в таблице маршрутизации. RT используется для того, чтобы отличить «внутренние» маршруты, т. е. маршруты, полученные через RIP, от маршрутов

«внешних», т. е. полученных от других протоколов маршрутизации, например EGP. Маршрутизаторы, на которых подняты несколько различных протоколов маршрутизации, должны обеспечивать возможность конфигурации RT для маршрутов, которые получены от «внешних» по отношению к RIP’у протоколов маршрутизации. RFC 2453 допускает иное использование поля RT, что может позволить EGP-протоколам взаимодействовать с RIP в целях передачи, например, транзитной информации через RIP-области.

Маска подсети - содержит маску подсети. Если это поле равно нулю, следовательно, маска подсети отсутствует, т.е. используется маска соответствующая классу. Если на каком-либо интерфейсе RIPv2-маршрутизатора существует вероятность того, что объявления может получать RIPv1маршрутизатор, то должны выполняться следующие правила для этого интерфейса:

1.Информация, являющаяся внутренней для одной сети, не должна посылаться в другую сеть.

2.Информация о подсетях не должна посылаться, поскольку RIPv1маршрутизатор может принять ее за посылку информации об адресе хоста.

3.Supernet routes (суперсетевые маршруты, т. е. маршруты с маской сети, более короткой, чем натуральная – соответствующая классу) не должны рассылаться, поскольку они могут быть неправильно интерпретированы RIPv1маршрутизаторами.

Следующий переход - поле указывает адрес маршрутизатора, которому должны быть посланы данные для того, чтобы они достигли сети назначения, которая указана в поле IP-адрес данного RTE. Например, маршрутизатор рассылает информацию о сети 10.10.10.0, но по каким либо причинам считает, что пакеты для этой сети должны посылаться не через него, а через другой маршрутизатор. В этом случае в поле «Следующий переход» указывается адрес этого «другого» маршрутизатора. Next hop должен содержать адрес, принадлежащий той же сети, на которой был получен данный маршрут. Если next hop не находиться на той же сети, его значение должно рассматриваться как равное 0.0.0.0.

Значение и формат поля Метрика – такие же, как и для RIP v1.

Как следует из приведенных выше форматов пакетов для разных версий протокола RIP, вторая версия протокола имеет следующие преимущества:

- возможность взаимодействия с внешними протоколами маршрутизации

(EGP);

- использование аутентификации; - работа с масками подсетей;

Кроме приведенных выше преимуществ, в целях уменьшения использования полосы пропускания сетей, RIPv2 вместо широковещательного адреса получателя использует мультикаст – 224.0.0.9. При этом нет необходимости использовать IGMP, поскольку RIP сообщения не должны пересылаться маршрутизаторами. В сетях NBMA (Non-broadcast multi-access) для рассылки сообщений может использоваться unicast-адрес. Однако в том случае, если на такой сети маршрутизатором получено RIP-сообщение, адресованное на адрес 224.0.0.9, оно также должно быть обработано. При использовании адреса типа мультикаст он должен использоваться на всех интерфейсах. Если RIPv2маршрутизатор получает RIPv1 Request, он должен формировать и отправить RIPv1 Response. Если же такой маршрутизатор сконфигурирован на отправку только RIPv2-сообщений, он не должен отвечать на такой запрос.

Вывод отладочной информации говорит о том, что происходит обмен маршрутной информацией с маршрутизатором 192.168.55.2. От этого маршрутизатора получен маршрут в сеть 192.168.88.0.

Просмотр таблицы маршрутизации, показывает маршрут, полученный динамически, индекс «R» указывает, что эта запись осуществлена протоколом

RIP.

Аналогично для R2

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

Рассмотрим более сложный пример:

Для R1 выполняем следующие настройки 1. Присваиваем имя R1

2. Конфигурируем интерфейсы

3. Конфигурируем RIP

указываем, что через интерфейс e0/0 ненужно рассылать объявления, т.к. этот интерфейс подключен в тупиковую сеть

Для PC1

Аналогично, настраиваем остальных участников схемы. По окончании настройки, взаимодействия между маршрутизаторами анализируются при помощи команды #debug ip rip.

Спустя некоторое время (~1 мин) на каждом маршрутизаторе проверяется таблица маршрутизации.

Для R1

Для R2

Для R3

Для R4

Работу схемы проверяют командой trace, выполняемой на одной из станций в адрес максимально удаленной станции. Например PC1 -> PC4

Для PC1

при этом замечается маршрут следования пакетов, в данном случае это путь через R1-R3-R4 (10.0.0.1-11.0.0.1-15.0.0.1). После чего на одном из транзитных маршрутизаторов выключается интерфейс, имитируя отказ маршрута.

после отключения интерфейса, отслеживается работа RIP на маршрутизаторе, к которому подключен источник пакетов, в данном случае R1. При верной настройке, отказавший маршрут должен быть переобъявлен с другой стороны схемы, в данном случае – через R2.

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

повторная проверка достижимости PC1->PC4 подтверждает правильность настройки протокола RIP, и показывает новый путь следования пакетов R1-R2- R4 (10.0.0.1-17.0.0.2-13.0.0.2)

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