Lesson_1_Dyn_IP

Сеть Метрика

1.0.0.01

3.0.0.01

При этом, протокол RIP стремится экономить пропускную способность линий связи и поэтому не рассылает через некоторый интерфейс сведения о доступности сети, которой принадлежит данный интерфейс. Действительно, у маршрутизатора R1 есть интерфейс в сети 3.0.0.0, а именно 3.0.0.1. Какой смысл посылать информацию о доступности сети 3.0.0.0 через интерфейс в этой сети 3.0.0.1, если тот, кто может получить данный пакет ПО ОПРЕДЕЛЕНИЮ имеет СВОЙ интерфейс в сети 3.0.0.0 и не нуждается в получении информации о маршруте в эту сеть, так как подключен в эту сеть с минимально возможной метрикой 1? Смысла в таких объявлениях нет. Из соображений экономии пропускной способности линий связи RIP маршрутизатор не включает в рассылаемый через некоторый интерфейс вектор расстояний сведения о доступности сети, через которую рассылается вектор расстояний.

Маршрутизатору R1 нет смысла рассылать вектор расстояний через интерфейс 1.0.0.1 в сети 1.0.0.0, так как в данной сети нет маршрутизаторов, которые могли бы услышать данные объявления. Отсюда следует, что протокол RIP требует минимальной настройки на маршрутизаторах (помимо активации самого протокола), т.е. необходимо указать, через какие интерфейсы необходимо рассылать вектор расстояний. Возможны такие реализации RIP в маршрутизаторах, при которых по умолчанию рассылка делается на всех интерфейсах. Это позволяет RIP маршрутизатору работать сразу после активации протокола RIP, но приводит к лишнему широковещательному или групповому трафику, что нежелательно - в большинстве реализаций маршрутизатор, после активации RIP ничего не рассылает, пока администратор не настроит, через какие интерфейсы маршрутизатор должен делать рассылку своих векторов расстояний. Так же, возможны ситуации, когда рассылка в сети, в которых больше нет маршрутизаторов, имеет смысл. Например, если УЗЛЫ сети умеют слушать RIP сообщения, то они смогут динамически узнавать, кому слать пакеты в другие сети, таким образом можно добиться некоторого динамического окружения для узлов, вместо использования IRDP (Internet Router Discovery Protocol).

Итак, в нашем случае маршрутизатор R1 рассылает свой вектор расстояний только через интерфейс 3.0.0.1 и не включает в него сведения о доступности сети 3.0.0.0. Рассылаемый вектор будет иметь вид:

Сеть Метрика

1.0.0.01

Маршрутизатор R1 и маршрутизатор R2 начинают рассылать свои вектора расстояний после инициализации, но кто-то, вероятно, успеет послать свой пакет первым, просто в силу обстоятельств - случайного или псевдослучайного характера. Предположим, что первым свой вектор рассылает R1, это не принципиально важно. Тогда, маршрутизатор R2 получает соответствующий RIP пакет и обрабатывает его следующим образом. Для начала данные RIP пакета разделяются на отдельные блоки, каждый из которых является объявлением о доступности одной сети, после чего каждый блок обрабатывается в соответствии с приводимым ниже алгоритмом.

Вначале, к полученной от соседа метрике данной сети добавляется единица, так как - то, что доступно соседу с метрикой N, для R2 будет доступно через R1 с метрикой N+1.

После этого маршрутизатор R2 проверяет, есть ли в его таблице маршрутизации маршрут в сеть, о которой объявляет сосед.

Если маршрута у R2 пока нет, то маршрутизатор R2 добавляет в свою таблицу маршрутизации маршрут в данную сеть с метрикой N+1 через тот порт маршрутизатора, который послал объявление (его адрес известен из IP заголовка).

Если же маршрут у R2 в данную сеть есть, то маршрутизатор R2 сравнивает его метрику из своей таблицы маршрутизации со значением N+1. Если у маршрутизатора R2 метрика в данную сеть больше, чем N+1, то маршрутизатор R2 выполняет предыдущий пункт алгоритма, т.е. добавляет в свою таблицу маршрутизации маршрут в данную сеть с метрикой N+1 через тот порт маршрутизатора, который послал объявление.

Иначе, если маршрут у маршрутизатора R2 не хуже, чем следует из объявления соседа, т.е. метрика маршрута в данную сеть у маршрутизатора R2 меньше либо равна N+1, то маршрутизатор R2 отбрасывает данное объявление и переходит к анализу следующего блока из принятого RIP пакета.

Применим эту логику к рассматриваемому примеру. Маршрутизатор R2, как уже было сказано, получил от маршрутизатора R1 следующий вектор расстояний:

Сеть Метрика

1.0.0.01

В полученном векторе расстояний, объявление о доступности только одной сети: 1.0.0.0. Маршрутизатор R2 добавляет к метрике, полученной от соседа единицу, и получает, что сеть 1.0.0.0 может быть доступна для R2 через R1 с метрикой 2. Так как, у маршрутизатора R2 пока вообще нет маршрута в сеть 1.0.0.0, то маршрутизатор R2 добавляет маршрут в эту сеть в свою таблицу маршрутизации. Тогда - сеть 1.0.0.0 доступна на R2 с метрикой 2, шлюзом в эту сеть будет тот, кто послал соответствующее объявление о доступности этой сети, принятое маршрутизатором R2, т.е. порт 3.0.0.1. Итого, таблица маршрутизации маршрутизатора R2 принимает вид:

2.0.0.02.0.0.1 1

3.0.0.03.0.0.2 1

1.0.0.03.0.0.1 2

Очевидно, что маршрутизатор R2 так же должен послать свой вектор расстояний через все свои интерфейсы (скорее всего кроме тех, которые ведут в тупиковые сети, см. выше). Т.е. через интерфейс 3.0.0.2 будет отправлен полный вектор расстояний с учетом уже полученных обновлений, при этом, как уже отмечалось, сеть 3.0.0.0 не будет фигурировать в данном векторе из соображений экономии полосы пропускания линии связи. Вектор расстояний, рассылаемый маршрутизатором R2, будет иметь вид:

Сеть Метрика

2.0.0.01

1.0.0.02

Маршрутизатор R1 получает RIP пакет с этим вектором расстояний и обрабатывает его в соответствии с приведенным выше алгоритмом. Для начала рассмотрим обработку записи о первой сети.

Сеть 2.0.0.0 доступна маршрутизатору R1 с метрикой 1, следовательно, маршрутизатору R1 она доступна с метрикой 2. пока у маршрутизатора R1 нет маршрута в сеть 2.0.0.0, поэтому он принимает это объявление и заносит в свою таблицу маршрутизации сведения о доступности сеть 2.0.0.0 с метрикой 2 через 3.0.0.2 (интерфейс, пославший пакет).

Сеть 1.0.0.0 доступна R1 с метрикой 2, следовательно, маршрутизатору R1 она доступна с метрикой 3. Но в таблице маршрутизации маршрутизатора R1 уже есть информация о доступности сети 1.0.0.0 с лучшей метрикой, равной 1. Следовательно, это объявление от соседа маршрутизатор R1 игнорирует. В итоге таблица маршрутизации маршрутизатора R1 примет вид:

1.0.0.01.0.0.1 1

3.0.0.03.0.0.1 1

Таким образом, таблицы маршрутизации обоих маршрутизаторов, теперь содержат все необходимые для работы в данной AS маршруты. Разумеется, процесс обмена RIP сообщениями не прекратится после этого, но ничего нового маршрутизаторы уже друг другу сказать не могут, поэтому таблицы маршрутизации у маршрутизаторов R1 и R2 меняться не будут.

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

Изначально, маршрутные таблицы маршрутизаторов R1, R2, R3 содержат информацию только о подключенных сетях:

Маршрутизатор R1:

1.0.0.01.0.0.1 1

2.0.0.02.0.0.1 1

7.0.0.07.0.0.1 1

Маршрутизатор R2:

3.0.0.03.0.0.1 1

4.0.0.04.0.0.1 1

7.0.0.07.0.0.2 1

8.0.0.08.0.0.1 1

Маршрутизатор R3:

5.0.0.05.0.0.1 1

6.0.0.06.0.0.1 1

8.0.0.08.0.0.2 1

Предположим, что очередность рассылки векторов расстояний такова: сначала рассылает свой вектор расстояний маршрутизатор R1, затем – маршрутизатор R2, после этого маршрутизатор R3, ну а потом снова приходит очередь R1 и так далее.

Итак, R1 через интерфейс 7.0.0.1 рассылает следующий вектор расстояний:

Сеть Метрика

1.0.0.01

2.0.0.01

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

После обработки вектора расстояний маршрутизатор R2 получает следующую таблицу маршрутизации:

3.0.0.03.0.0.1 1

4.0.0.04.0.0.1 1

7.0.0.07.0.0.2 1

8.0.0.08.0.0.1 1

1.0.0.07.0.0.1 2

Обратите внимание, метрика для сетей 1.0.0.0 и 2.0.0.0 увеличивается на 1 до значения 2, т.к. в соответствии с вектором расстояний, полученным от R1, подключенного в ту же сеть что и R2, исходная метрика для этих сетей была равна 1

После этого свой вектор расстояний рассылает маршрутизатор 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

Данный вектор получает и обрабатывает маршрутизатор R1 и его таблица маршрутизации принимает вид:

1.0.0.01.0.0.1 1

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.1 маршрутизатор R2 рассылает другой вектор расстояний:

Сеть Метрика

3.0.0.01

4.0.0.01

7.0.0.01

1.0.0.02

2.0.0.02

Этот вектор в свою очередь получает и обрабатывает уже маршрутизатор R3 и его таблица маршрутизации после обработки этого вектора расстояний принимает вид:

5.0.0.05.0.0.1 1

6.0.0.06.0.0.1 1

8.0.0.08.0.0.2 1

3.0.0.08.0.0.1 2

4.0.0.08.0.0.1 2

7.0.0.08.0.0.1 2

1.0.0.08.0.0.1 3

При этом, таблица маршрутизации маршрутизатора R3 УЖЕ содержит в себе всю необходимую информацию для работы в данной AS, а маршрутизаторы R1 и R2 еще не до конца обучились.

После этого приходит очередь объявлять свой вектор расстояний маршрутизатору R3. Маршрутизатор рассылает свой вектор расстояний через интерфейс 8.0.0.2 и он содержит в себе сведения о следующих сетях:

Сеть Метрика

5.0.0.01

6.0.0.01

3.0.0.02

4.0.0.02

7.0.0.02

1.0.0.03

2.0.0.03

Данное объявление получает маршрутизатор R2 и после обработки полученного сообщения таблица маршрутизации маршрутизатора R2 принимает вид:

3.0.0.03.0.0.1 1

4.0.0.04.0.0.1 1

7.0.0.07.0.0.2 1

8.0.0.08.0.0.1 1

1.0.0.07.0.0.1 2

2.0.0.07.0.0.1 2

5.0.0.08.0.0.2 2

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

Продолжим рассмотрение работы маршрутизаторов. Следующим снова объявляет свой вектор расстояний маршрутизатор R1. Его таблица маршрутизации имеет вид:

1.0.0.01.0.0.1 1

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

Маршрутизатор R1 через интерфейс 7.0.0.1 рассылает вектор расстояний следующего вида:

Сеть Метрика

1.0.0.01

2.0.0.01

3.0.0.02

4.0.0.02

8.0.0.02

Этот вектор расстояний получает маршрутизатор R2 и отбрасывает все объявления, так как имеет в своей таблице маршрутизации не худшие маршруты

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 и извлекает из него сведения о доступности сетей 5.0.0.0 и 6.0.0.0, таким образом, после обработки данного вектора расстояний таблица маршрутизации маршрутизатора R1 принимает вид:

1.0.0.01.0.0.1 1

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

Врезультате, таблица маршрутизации маршрутизатора R1 так же содержит

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

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

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

Начнем с рассмотрения самого простого случая - в работающей AS появляется новая сеть. Положим, что в сети, которую мы рассмотрели выше, появилась новая сеть N9, с номером 9.0.0.0, подключенная к маршрутизатору

R1.

Убедимся, что протокол RIP легко справляется с такой ситуацией. Действительно, когда маршрутизатор R1 в следующий раз будет рассылать свой вектор расстояний через интерфейс 7.0.0.1, он включит в него сведения о доступности сети 9.0.0.0 с метрикой 1, и маршрутизатор R2 добавит в свою таблицу сведения о доступности сети 9.0.0.0 через 7.0.0.1 с метрикой 2. После этого, когда придет очередь маршрутизатору R2 рассылать вектор расстояний через интерфейс 8.0.0.1, он включит в него сведения о доступности сети 9.0.0.0 с метрикой 2, получив этот вектор расстояний, маршрутизатор R3 включит в свою таблицу маршрутизации сведения о доступности сети 9.0.0.0 с метрикой 3 через 8.0.0.1. Таким образом, в случае, если очередность объявлений маршрутизаторов такая же, как и в прошлом примере, то время, через которое маршрутизаторы R2 и R3 узнают о доступности новой сети (с момента ее появления) оказывается менее двух таймеров между объявлениями одного маршрутизатора, т.е. менее 60 секунд. Маршрутизатор R1 объявляет о доступности сети 9.0.0.0 в худшем случае через 30 секунд после ее появления, и еще, время меньшее либо равное 30 секунд проходит, пока о доступности этой сети узнает маршрутизатор R3 от маршрутизатора R2.

Можно легко оценить среднюю и худшую скорость распространения информации о новой сети в RIP системе. Маршрутизатор, к которому подключена новая сеть, объявляет о ее доступности не позднее, чем через 30 секунд после ее появления. Второй маршрутизатор распространяет эту информацию также не позднее, чем через 30 секунд, после того, как узнает о ней и т.д. Т.е. в сети с N переходами информация о новой сети достигнет самого дальнего маршрутизатора через N/2 минут, а так как максимально возможное количество переходов, поддерживаемое RIP системой не превышает 14, то, следовательно, в худшем случае все маршрутизаторы AS узнают о доступности новой сети через 7 минут. Т.е. 7 минут - это самый худший из всех случаев! Возможно, что маршрутизатор, у которого появилась новая подключенная сеть

как раз к моменту, когда она появилась и должен быть объявлять о ее доступности, так что задержки на первом маршрутизаторе практически не было. Второй маршрутизатор узнал о доступности этой сети так же как раз непосредственно перед тем моментом, когда ему пришло время объявлять свой вектор расстояний, так что и второй маршрутизатор вносит малую задержку и т.д. Таким образом, в лучшем случае задержка передачи сведений о новой сети самому дальнему маршрутизатору составит малое, трудно поддающееся учету время, теоретически стремящееся к нулю. Отсюда, можно сделать вывод, что в среднем, характерное время распространения информации о новой сети в AS построенной на базе RIP составляет около N/4 минут, где N число переходов между самыми дальними маршрутизаторами AS. С учетом того, что количество переходов не превышает 14, это время не превысит 3.5 минуты, что вполне приемлемо.

Приведенный выше пример говорит о том, что информация о новых сетях распространяется в RIP системе достаточно быстро.

Рассмотрим теперь обратную ситуацию: пусть некоторая сеть перестала быть доступна. Например, в нашем предыдущем примере сеть N1 перестает быть доступна, например, из-за отказа линии связи, соединяющей эту сеть с маршрутизатором R1.

Маршрутизатор R1, разумеется, перестает включать сеть 1.0.0.0 в свой вектор расстояний и удаляет ее из таблицы маршрутизации. Если маршрутизатор R2 имеет запись о доступности сети 1.0.0.0 в таблице маршрутизации, то данная запись будет удалена только после того, как в течение некоторого таймаута не будут получены уведомления о доступности сети 1.0.0.0. Это время должно быть существенно больше, чем интервал между рассылкой вектора расстояний. Если бы достаточно было ОДИН раз НЕ получить сведения о доступности сети для того, чтобы вычеркнуть ее из таблицы

маршрутизации, то потеря одного RIP пакета приводила бы сразу к потере маршрутов и дестабилизации работы сети. Так как пакеты протокола RIP могут теряться в сети (вследствие использования UDP), то НЕДОПУСТИМО, чтобы нормальные потери пакетов в сети приводили к потерям маршрутов. Поэтому таймаут удаления записи из таблицы маршрутизации (в случае не прихода подтверждений этой записи от соседей) должен быть заметно больше, нежели таймаут между обычными рассылками векторов расстояний. В RIP стандартно рекомендуемое значение этого таймаута в ШЕСТЬ раз превышает таймаут между рассылками вектора расстояний и составляет по умолчанию 180 секунд. Таким образом, даже потеря последовательности из 5 RIP объявлений подряд не приведет к потерям маршрутов! Далее рассмотрим, каким же образом маршрутизаторы AS «забывают» маршруты в отказавшие сети.

Итак, маршрутизатор R1 перестал включать сведения о доступности сети 1.0.0.0 в свой вектор расстояний. Рассмотрим худший случай: пусть непосредственно перед тем, как сеть 1.0.0.0 стала недоступной, маршрутизатор R1 разослал свой вектор расстояний соседу – маршрутизатору R2. Тогда через 30 секунд маршрутизатор R1 пошлет новый вектор расстояний R2 и тот впервые не увидит там сведений о доступности сети 1.0.0.0, но, как уже говорилось выше, никаких выводов не сделает, продолжая сообщать R3 о доступности этой сети. На данный момент R2 не получает сведений о доступности сети 1.0.0.0 уже 30 секунд, и еще через 150 секунд удалит сведения о доступности этой сети из своей маршрутной таблицы, перестав включать эту сеть в свой вектор расстояний. После этого, еще через 180 секунд о доступности этой сети «забудет» и маршрутизатор R3. Таким образом, худшая скорость распространения информации об отказавших сетях в RIP составляет около 3N минут, где N число переходов в AS. при N=14 (максимальный диаметр сети на базе RIP) это время составляет 42 минуты, что весьма много. В лучшем же случае, сразу после отказа сети 1.0.0.0 маршрутизатору R1 приходит время рассылать свой вектор расстояний, в это векторе не будет сведений о сети 1.0.0.0, и у маршрутизатора R2 сеть 1.0.0.0 будет «не подтверждена» уже 30 секунд. Таким образом, маршрутизатор R2 узнает о ее недоступности не через 180 секунд после ее отказа, а через 150 секунд. Аналогично, можно показать, что в лучшем случае скорость распространения информации об отказавших сетях составляет 2.5N, что при диаметре сети в 14 переходов составляет 35 минут, ну а среднее время распространения такой информации составляет 2.75N (при 14 переходах – 38.5 минут).

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

Среднее время распространения информации о новых сетях составляет в RIP около N/4 минут (при 14 переходах – 3.5 минуты)

Среднее время распространения информации об отказавших сетях составляет в RIP около 2.75N минут (при 14 переходах – 38.5 минуты)

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