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

Определение

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

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

В широком смысле маршрутизация выполняется двумя разными способами:

• Динамическая — периодически обновляет свою таблицу маршрутизации путями и их стоимостью/метрикой, принимая оптимальные решения на основе изменения сетевых рабочих условий.
• Статическая — считается простейшей формой этого процесса, выполняет правила маршрутизации с предварительно настроенными путями передачи данных в таблице, которые могут быть изменены вручную только администраторами.

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

Разновидности маршрутизации

Устройство может использовать три пути для изучения маршрутов:

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

Маршрутизация по умолчанию — это методика, где все маршрутизаторы настроены на отправку всех пакетов по одному пути. Это очень полезный метод для небольших сетей или для сетей с единой точкой входа и выхода. Он обычно используется в дополнение к статическому и динамическому способам.

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

Классификация протоколов

Протоколы маршрутизации классифицируются как протоколы внутренних шлюзов (IGP) или внешние шлюзовые протоколы (EGP). IGP используются для обмена информацией о процессе в межсетевых сетях, которые попадают под единый административный домен (также называемый автономными системами). EGP используются для обмена информацией между различными автономными системами. Обычными примерами IGP являются протокол маршрутизации (RIP), расширенный протокол внутренних шлюзов (EIGRP) и Open Shortest Path First (OSPF).

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

В большинстве (IP) используются следующие протоколы маршрутизации:

Протокол маршрутизации (RIP) и протокол маршрутизации внутренних шлюзов (IGRP): обеспечивают процесс для внутренних шлюзов через протоколы маршрутных или дистанционных векторов. RIP используется для определения кратчайшего пути от источника к месту назначения. Это позволяет передавать данные на высокой скорости в кратчайшие сроки.

Open Shortest Path First (OSPF): обеспечивает процесс для внутренних шлюзов через протоколы маршрутизации состояния канала.

• Протокол пограничного шлюза (BGP) v4: предоставляет общедоступный протокол маршрутизации через внешнее взаимодействие со шлюзом.

Как настроить статическую маршрутизацию Cisco

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

Код для командной строки: ip route prefix mask{адрес|интерфейс}[расстояние]. Разъясним основные составляющие кода:

сеть — целевая сеть;

mask — маска подсети для этой сети;

адрес — IP-адрес маршрутизатора следующего перехода;

интерфейс — интерфейс оборудования исходящего трафика;

расстояние — административное расстояние маршрута.

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

Пример статической маршрутизации:

ip route 10.0.0.0 255.0.0.0 131.108.3.4 110, где 10.0.0.0 — целевая сеть, 255.0.0.0 — маска подсети, а 131.108.3.4 — следующий скачок для используемого маршрутизатора, 110 — административная дистанция.

Пример создания статического маршрута

В качестве примера того, когда требуется статический маршрут, рассмотрим следующий случай:

Ваш основной доступ в интернет осуществляется через кабельный модем для интернет-провайдера.

У вас есть маршрутизатор ISDN в вашей домашней сети для подключения к компании, в которой вы работаете. Адрес этого устройства в вашей локальной сети 192.168.1.100.

Сетевой адрес вашей компании 134.177.0.0.

При настройке статической маршрутизации cisco создаются два неявных статических маршрута.

Путь передачи данных по умолчанию был создан с вашим провайдером в качестве шлюза, а второй статический маршрут создается в локальной сети для всех адресов 192.168.1.x. В этой конфигурации при попытке доступа к устройству в сети 134.177.0.0 маршрутизатор перенаправляет запрос поставщику услуг интернета.



В этом случае необходимо определить статический маршрут, указав прибору, что 134.177.0.0 должен быть доступен через маршрутизатор ISDN по адресу 192.168.1.100.

Статические и динамические маршрутизаторы

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

Статическая маршрутизация

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

Хорошим примером статического устройства является многосетевой компьютер под управлением Windows 2000 (компьютер с несколькими сетевыми интерфейсами). Создание статической маршрутизации в Windows 2000 так же просто, как установка нескольких карт сетевого интерфейса, настройка TCP/IP и включение IP-маршрутизации.

Динамическая маршрутизация

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

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

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

Динамическая методика использует множество различных алгоритмов и протоколов. Наиболее популярными являются протокол маршрутизации (RIP) и Open Shortest Path First (OSPF).



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

Операции протокола динамической маршрутизации можно объяснить следующим образом:

• Маршрутизатор предоставляет и получает сообщения на интерфейсах устройства.

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

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

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

Сравнительный анализ

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

Статическая методика — это простейшая форма маршрутизации, но это кропотливый ручной процесс. Используйте данный метод, когда у вас очень мало устройств для настройки (менее 5), и вы уверены, что пути передачи информации, вероятно, никогда не изменятся.

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

Протоколы динамической маршрутизации поддерживаются программными приложениями, запущенными на принимающем/передающем устройстве (маршрутизаторе).

Устройство, использующее динамическую методику, распознает маршруты для всех сетей, которые напрямую к нему подключены. Затем маршрутизатор изучает данные других приборов, которые выполняют один и тот же протокол (RIP, RIP2, EIGRP, OSPF, IS-IS, BGP). Затем каждый маршрутизатор сортирует список маршрутов и выбирает один или несколько оптимальных путей для каждого сетевого адресата.

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



Плюсы и минусы

Статическая маршрутизация имеет следующие преимущества:

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

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

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

Настройка статической маршрутизации более безопасна.

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

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

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

К недостаткам относятся следующие:

Сетевые администраторы должны хорошо знать всю чтобы правильно настроить пути передачи данных.

Изменения топологии требуют ручной настройки статической маршрутизации cisco packet tracer для всех устройств, что очень трудоемко.

Статические маршруты не масштабируются по мере роста сети. Это связано с тем, что все они настраиваются администратором вручную.

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

В чем разница между статической и динамической маршрутизацией?

Статическая IP-маршрутизация — это когда вы статически настраиваете устройство для отправки трафика для определенных пунктов назначения в предварительно сконфигурированных направлениях. Динамический способ — это когда вы используете протокол маршрутизации, такой как OSPF, ISIS, EIGRP и или BGP, чтобы выяснить, какой тип трафика должен пройти. В реальном мире очень мало ситуаций, когда используется только один из двух методов. Типичная сеть будет использовать динамический протокол OSPF для определения оптимальных маршрутов внутри предприятия, BGP — для определения лучших точек выхода для остальной части интернета и статическую маршрутизацию для отправки специфического трафика по выделенным путям.

IP-адресация и маршрутизация: как это работает?

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

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



Когда использовать маршрутизацию по умолчанию

Маршрутизация по умолчанию используется только в сетях-заглушках. Stub — это сети, которые имеют только один интерфейс вывода, и все, проходящее через эти сети, должно пересекать единую точку выхода.

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

Использование административных расстояний

По умолчанию для статических маршрутов административное расстояние составляет 1. AD используются для определения приоритетов. Для разных маршрутов в конкретной целевой сети могут быть назначены разные веса, так что один из путей передачи данных используется в приоритете. Маршруты с одинаковой весовой нагрузкой разделяют трафик.

Итак, приступим.

Статей и видео о том, как настроить OSPF горы. Гораздо меньше описаний принципов работы. Вообще, тут такое дело, что OSPF можно просто настроить согласно мануалам, даже не зная про алгоритмы SPF и непонятные LSA. И всё будет работать и даже, скорее всего, прекрасно работать - на то он и рассчитан. То есть тут не как с вланами, где приходилось знать теорию вплоть до формата заголовка.
Но инженера от эникейщика отличает то, что он понимает, почему его сеть функционирует так, а не иначе, и не хуже самогo OSPF знает, какой маршрут будет выбран протоколом.
В рамках статьи, которая уже на этот момент составляет 8 000 символов, мы не сможем погрузиться в глубины теории, но рассмотрим принципиальные моменты.
Очень просто и понятно, кстати, написано про OSPF на xgu.ru или в английской википедии .
Итак, OSPFv2 работает поверх IP, а конкретно, он заточен только под IPv4 (OSPFv3 не зависит от протоколов 3-го уровня и потому может работать с IPv6).

Рассмотрим его работу на примере вот такой упрощённой сети:

Для начала надо сказать, что для того, чтобы между маршрутизаторами завязалась дружба (отношения смежности) должны выполниться следующие условия:

1) в OSPF должны быть настроены одинаковые Hello Interval на тех маршрутизаторах, что подключены друг к другу. По умолчанию это 10 секунд в Broadcast сетях, типа Ethernet. Это своего рода KeepAlive сообщения. То есть каждые 10 секунд каждый маршрутизатор отправляет Hello пакет своему соседу, чтобы сказать: “Хей, я жив”,
2) Одинаковыми должны быть и Dead Interval на них. Обычно это 4 интервала Hello - 40 секунд. Если в течение этого времени от соседа не получено Hello, то он считается недоступным и начинается ПАНИКА процесс перестроения локальной базы данных и рассылка обновлений всем соседям,
3) Интерфейсы, подключенные друг к другу, должны быть в одной подсети ,
4) OSPF позволяет снизить нагрузку на CPU маршрутизаторов, разделив Автономную Систему на зоны. Так вот номера зон тоже должны совпадать,
5) У каждого маршрутизатора, участвующего в процессе OSPF есть свой уникальный индентификатор - Router ID . Если вы о нём не позаботитесь, то маршрутизатор выберет его автоматически на основе информации о подключенных интерфейсах (выбирается высший адрес из интерфейсов, активных на момент запуска процесса OSPF). Но опять же у хорошего инженера всё под контролем, поэтому обычно создаётся Loopback интерфейс, которому присваивается адрес с маской /32 и именно он назначается Router ID. Это бывает удобно при обслуживании и траблшутинге.
6) Должен совпадать размер MTU

1) Штиль. Состояние OSPF - DOWN
В это короткое мгновение в сети ничего не происходит - все молчат.

2) Поднимается ветер: маршрутизатор рассылает Hello-пакеты на мультикастный адрес 224.0.0.5 со всех интерфейсов, где запущен OSPF. TTL таких сообщений равен одному, поэтому их получат только маршрутизаторы, находящиеся в том же сегменте сети. R1 переходит в состояние INIT .

В пакеты вкладывается следующая информация:

• Router ID
• Hello Interval
• Dead Interval
• Neighbors
• Subnet mask
• Area ID
• Router Priority
• Адреса DR и BDR маршрутизаторов
• Пароль аутентификации

Нас интересуют пока первые четыре или точнее вообще только Router ID и Neighbors.
Сообщение Hello от маршрутизатора R1 несёт в себе его Router ID и не содержит Neighbors, потому что у него их пока нет.
После получения этого мультикастного сообщения маршрутизатор R2 добавляет R1 в свою таблицу соседей (если совпали все необходимые параметры).

И отправляет на R1 уже юникастом новое сообщение Hello, где содержится Router ID этого маршрутизатора, а в списке Neigbors перечислены все его соседи. В числе прочих соседей в этом списке есть Router ID R1, то есть R2 уже считает его соседом.

3) Дружба. Когда R1 получает это сообщение Hello от R2, он пролистывает список соседей и находит в нём свой собственный Router ID, он добавляет R2 в свой список соседей.

Теперь R1 и R2 друг у друга во взаимных соседях - это означает, что между ними установлены отношения смежности и маршрутизатор R1 переходит в состояние TWO WAY .

Общий совет по всем задачам:

Даже если Вы сразу не знаете ответа и решения, постарайтесь подумать к чему относится условие задачи:
- К каким особенностям, настройкам протокола?
- Глобальные эти настройки или привязаны к конкретному интерфейсу?
Если Вы не знаете или забыли команду, такие размышления, скорее всего, приведут Вас к правильному контексту, где Вы просто, с помощью подсказки в командной строке, можете догадаться или вспомнить как настроить то, что требуется в задании.
Постарайтесь поразмышлять в таком ключе прежде чем пойдете в гугл или на какой-то сайт в поиске команд.

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

Прежде чем мы перейдём к тестированию резервных линков и скорости, сделаем ещё одну полезную вещь.
Если бы у нас была возможность отловить трафик на интерфейсе FE0/0.2 msk-arbat-gw1, который смотрит в сторону серверов, то мы бы увидели, что каждые 10 секунд в неизвестность улетают сообщения Hello. Ответить на Hello некому, отношения смежности устанавливать не с кем, поэтому и пытаться рассылать отсюда сообщения смысла нет.
Выключается это очень просто:

msk-arbat-gw1(config)#router OSPF 1
msk-arbat-gw1(config-router)#passive-interface fastEthernet 0/0.2

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

*Не представляю, как вы до сих пор не запутались*

Кроме того, эта команда повышает безопасность - никто из этой сети не прикинется маршрутизатором и не будет пытаться поломать нас полностью.

Теперь займёмся самым интересным - тестированием.
Ничего сложного нет в настройке OSPF на всех маршрутизаторах в Сибирском кольце - сделаете сами.
И после этого картина должна быть следующей:

msk-arbat-gw1#sh ip OSPF neighbor

172.16.255.32 1 FULL/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 FULL/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911

Питер, Кемерово, Красноярск и Владивосток - непосредственно подключенные.

msk-arbat-gw1#sh ip route

172.16.0.0/16 is variably subnetted, 25 subnets, 6 masks



S 172.16.2.4/30 via 172.16.2.2



O 172.16.2.160/30 via 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:04:18, FastEthernet1/0.911





S 172.16.16.0/21 via 172.16.2.2
S 172.16.24.0/22 via 172.16.2.18
O 172.16.24.0/24 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 00:07:18, FastEthernet0/1.8

O 172.16.255.32/32 via 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:04:18, FastEthernet0/1.8
via 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:04:28, FastEthernet1/0.911

Все обо всех всё знают.
Каким маршрутом трафик доставляется из Москвы в Красноярск? Из таблицы видно, что krs-stolbi-gw1 подключен напрямую и это же видно из трассировки:

1 172.16.2.130 35 msec 8 msec 5 msec

Теперь рвём интерфейс между Москвой и Красноярском и смотрим, через сколько линк восстановится.
Не проходит и 5 секунд, как все маршрутизаторы узнали о происшествии и пересчитали свои таблицы маршрутизации:

msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0

Known via «OSPF 1», distance 110, metric 4, type intra area
Last update from 172.16.2.197 on FastEthernet1/0.911, 00:00:53 ago
Routing Descriptor Blocks:
* 172.16.2.197, from 172.16.255.80, 00:00:53 ago, via FastEthernet1/0.911
Route metric is 4, traffic share count is 1

Vld-gw1#sh ip route 172.16.128.0
Routing entry for 172.16.128.0/24
Known via «OSPF 1», distance 110, metric 3, type intra area
Last update from 172.16.2.193 on FastEthernet1/0, 00:01:57 ago
Routing Descriptor Blocks:
* 172.16.2.193, from 172.16.255.80, 00:01:57 ago, via FastEthernet1/0
Route metric is 3, traffic share count is 1

Msk-arbat-gw1#traceroute 172.16.128.1
Type escape sequence to abort.
Tracing the route to 172.16.128.1

1 172.16.2.197 4 msec 10 msec 10 msec
2 172.16.2.193 8 msec 11 msec 15 msec
3 172.16.2.161 15 msec 13 msec 6 msec

То есть теперь Красноярска трафик достигает таким путём:

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

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

EIGRP

Теперь займёмся другим очень важным протоколом

Итак, чем хорош EIGRP?
- прост в конфигурации
- быстрое переключение на заранее просчитанный запасной маршрут
- требует меньше ресурсов роутера (по сравнению с OSPF)
- суммирование маршрутов на любом роутере (в OSPF только на ABR\ASBR)
- балансировка трафика на неравноценных маршрутах (OSPF только на равноценных)

Мы решили перевести одну из записей блога Ивана Пепельняка, в которой разбирается ряд популярных мифов про EIGRP:
- “EIGRP это гибридный протокол маршрутизации”. Если я правильно помню, это началось с первой презентации EIGRP много лет назад и обычно понимается как «EIGRP взял лучшее от link-state и distance-vector протоколов». Это совершенно не так. У EIGRP нет никаких отличительных особенностей link-state. Правильно будет говорить «EIGRP это продвинутый distance-vector- протокол маршрутизации».

- “EIGRP это distance-vector протокол”. Неплохо, но не до конца верно тоже. EIGRP отличается от других DV способом, которым обрабатывает потерянные маршруты (или маршруты с возрастающей метрикой). Все остальные протоколы пассивно ждут обновления информации от соседа (некоторые, например, RIP, даже блокируют маршрут для предотвращения петель маршрутизации), в то время как EIGRP ведет себя активнее и запрашивает информацию сам.

- “EIGRP сложен во внедрении и обслуживании”. Неправда. В свое время, EIGRP в больших сетях с низкоскоростными линками было сложновато правильно внедрить, но ровно до того момента, как были введены stub routers. С ними (а также несколькими исправлениями работы DUAL-алгоритма), он не чуть не хуже, чем OSPF.

- “Как и LS протоколы, EIGRP хранит таблицу топологии маршрутов, которыми обменивается”. Просто удивительно, насколько это неверно. EIGRP не имеет вообще никакого понятия о том, что находится дальше ближайших соседей, в то время как LS протоколы точно знают топологию всей области, к которой они подключены.

- “EIGRP это DV протокол, который действует, как LS”. Неплохая попытка, но по-прежнему, абсолютно неверно. LS протоколы строят таблицу маршрутизации, проходя через следующие шаги:
- каждый маршрутизатор описывает сеть, исходя из информации, доступной ему локально (его линки, подсети, в которых он находится, соседи, которых он видит) посредством пакета (или нескольких), называемого LSA (в OSPF) или LSP (IS-IS)
- LSA распространяются по сети. Каждый маршрутизатор должен получить каждую LSA, созданную в его сети. Информация, полученная из LSA, заносится в таблицу топологии.
- каждый маршрутизатор независимо анализирует свою таблицу топологии и запускает SPF алгоритм для подсчета лучших маршрутов к каждому из других маршрутизаторов
Поведение EIGRP даже близко не напоминает эти шаги, поэтому непонятно, с какой стати он «действует, как LS»

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

Теперь чуть ближе к теории работы:

Каждый процесс EIGRP обслуживает 3 таблицы:
- Таблицу соседей (neighbor table), в которой содержится информация о “соседях”, т.е. других маршрутизаторах, непосредственно подключенных к текущему и участвующих в обмене маршрутами. Можно посмотреть с помощью команды show ip eigrp neighbors
- Таблицу топологии сети (topology table), в которой содержится информация о маршрутах, полученная от соседей. Смотрим командой show ip eigrp topology
- Таблицу маршрутизации (routing table), на основе которой роутер принимает решения о перенаправлении пакетов. Просмотр через show ip route

Метрика.
Для оценки качества определенного маршрута, в протоколах маршрутизации используется некое число, отражающее различные его характеристики или совокупность характеристик- метрика. Характеристики, принимаемые в расчет, могут быть разными- начиная от количества роутеров на данном маршруте и заканчивая средним арифметическим загрузки всех интерфейсов по ходу маршрута. Что касается метрики EIGRP, процитируем Jeremy Cioara: “у меня создалось впечатление, что создатели EIGRP, окинув критическим взглядом свое творение, решили, что все слишком просто и хорошо работает. И тогда они придумали формулу метрики, что бы все сказали “ВАУ, это действительно сложно и профессионально выглядит”. Узрите же полную формулу подсчета метрики EIGRP: (K1 * bw + (K2 * bw) / (256 - load) + K3 * delay) * (K5 / (reliability + K4)), в которой:
- bw это не просто пропускная способность, а (10000000/самая маленькая пропускная способность по дороге маршрута в килобитах) * 256
- delay это не просто задержка, а сумма всех задержек по дороге в десятках микросекунд * 256 (delay в командах show interface, show ip eigrp topology и прочих показывается в микросекундах!)
- K1-K5 это коэффициенты, которые служат для того, чтобы в формулу “включился” тот или иной параметр.

Страшно? было бы, если бы все это работало, как написано. На деле же из всех 4 возможных слагаемых формулы, по умолчанию используются только два: bw и delay (коэффициенты K1 и K3=1, остальные нулю), что сильно ее упрощает - мы просто складываем эти два числа (не забывая при этом, что они все равно считаются по своим формулам). Важно помнить следующее: метрика считается по худшему показателю пропускной способности по всей длине маршрута .

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

Определимся с терминами, применяемыми внутри EIGRP. Каждый маршрут в EIGRP характеризуется двумя числами: Feasible Distance и Advertised Distance (вместо Advertised Distance иногда можно встретить Reported Distance, это одно и то же). Каждое из этих чисел представляет собой метрику, или стоимость (чем больше-тем хуже) данного маршрута с разных точек измерения: FD это “от меня до места назначения”, а AD- “от соседа, который мне рассказал об этом маршруте, до места назначения”. Ответ на закономерный вопрос “Зачем нам надо знать стоимость от соседа, если она и так включена в FD?”- чуть ниже (пока можете остановиться и поломать голову сами, если хотите).

У каждой подсети, о которой знает EIGRP, на каждом роутере существует Successor- роутер из числа соседей, через который идет лучший (с меньшей метрикой), по мнению протокола, маршрут к этой подсети. Кроме того, у подсети может также существовать один или несколько запасных маршрутов (роутер-сосед, через которого идет такой маршрут, называется Feasible Successor). EIGRP- единственный протокол маршрутизации, запоминающий запасные маршруты (в OSPF они есть, но содержатся, так сказать, в “сыром виде” в таблице топологии- их еще надо обработать алгоритмом SPF), что дает ему плюс в быстродействии: как только протокол определяет, что основной маршрут (через successor) недоступен, он сразу переключается на запасной. Для того, чтобы роутер мог стать feasible successor для маршрута, его AD должно быть меньше FD successor’а этого маршрута (вот зачем нам нужно знать AD). Это правило применяется для того, чтобы избежать колец маршрутизации.

Предыдущий абзац взорвал мозг? Материал трудный, поэтому еще раз на примере. У нас есть вот такая сеть:

С точки зрения R1, R2 является Successor’ом для подсети 192.168.2.0/24. Чтобы стать FS для этой подсети, R4 требуется, чтобы его AD была меньше FD для этого маршрута. FD у нас ((10000000/1544)*256)+(2100*256) =2195456, AD у R4 (с его точки зрения это FD, т.е. сколько ему стоит добраться до этой сети) = ((10000000/100000)*256)+(100*256)=51200. Все сходится, AD у R4 меньше, чем FD маршрута, он становится FS. *тут мозг такой и говорит: “БДЫЩЬ”*. Теперь смотрим на R3- он анонсирует свою сеть 192.168.1.0/24 соседу R1, который, в свою очередь, рассказывает о ней своим соседям R2 и R4. R4 не в курсе, что R2 знает об этой подсети, и решает ему рассказать. R2 передает информацию о том, что он имеет доступ через R4 к подсети 192.168.1.0/24 дальше, на R1. R1 строго смотрит на FD маршрута и AD, которой хвастается R2 (которая, как легко понять по схеме, будет явно больше FD, так как включает и его тоже) и прогоняет его, чтобы не лез со всякими глупостями. Такая ситуация довольно маловероятна, но может иметь место при определенном стечении обстоятельств, например, при отключении механизма “расщепления горизонта” (split-horizon). А теперь к более вероятной ситуации: представим, что R4 подключен к сети 192.168.2.0/24 не через FastEthernet, а через модем на 56k (задержка для dialup составляет 20000 usec), соответственно, добраться ему стоит ((10000000/56)*256)+(2000*256)= 46226176. Это больше, чем FD для этого маршрута, поэтому R4 не станет Feasible Successor’ом. Но это не значит, что EIGRP вообще не будет использовать данный маршрут. Просто переключение на него займет больше времени (подробнее об этом дальше).

соседство

Роутеры не разговаривают о маршрутах с кем попало - прежде чем начать обмениваться информацией, они должны установить отношения соседства. После включения процесса командой router eigrp с указанием номера автономной системы, мы, командой network говорим, какие интерфейсы будут участвовать и одновременно, информацию о каких сетях мы желаем распространять. Незамедлительно, через эти интерфейсы начинают рассылаться hello-пакеты на мультикаст- адрес 224.0.0.10 (по умолчанию каждые 5 секунд для ethernet). Все маршрутизаторы с включенным EIGRP получают эти пакеты, далее каждый маршрутизатор-получатель делает следующее:
- сверяет адрес отправителя hello-пакета, с адресом интерфейса, из которого получен пакет, и удостоверяется, что они из одной подсети
- сверяет значения полученных из пакета K-коэффициентов (проще говоря, какие переменные используются в подсчете метрики) со своими. Понятно, что если они различаются, то метрики для маршрутов будут считаться по разным правилам, что недопустимо
- проверяет номер автономной системы
- опционально: если настроена аутентификация, проверяет соответствие ее типа и ключей.

Если получателя все устраивает, он добавляет отправителя в список своих соседей, и посылает ему (уже юникастом) update-пакет, в котором содержится список всех известных ему маршрутов (aka full-update). Отправитель, получив такой пакет, в свою очередь, делает то же самое. Для обмена маршрутами EIGRP использует Reliable Transport Protocol (RTP, не путать с Real-time Transport Protocol, который используется в ip-телефонии), который подразумевает подтверждение о доставке, поэтому каждый из роутеров, получив update- пакет, отвечает ack -пакетом (сокращение от acknowledgement- подтверждение). Итак, отношение соседства установлены, роутеры узнали друг у друга исчерпывающую информацию о маршрутах, что дальше? Дальше они будут продолжать посылать мультикаст hello-пакеты в подтверждение того, что они на связи, а в случае изменения топологии- update-пакеты, содержащие сведения только об изменениях (partial update).

Теперь вернемся к предыдущей схеме с модемом.

R2 по каким-то причинам потерял связь с 192.168.2.0/24. До этой подсети у него нет запасных маршрутов (т.е. отсутствует FS). Как всякий ответственный роутер с EIGRP, он хочет восстановить связь. Для этого он начинает рассылать специальные сообщения (query- пакеты) всем своим соседям, которые, в свою очередь, не находя нужного маршрута у себя, расспрашивают всех своих соседей, и так далее. Когда волна запросов докатывается до R4, он говорит “погодите-ка, у меня есть маршрут к этой подсети! Плохонький, но хоть что-то. Все про него забыли, а я-то помню”. Все это он упаковывает в reply-пакет и отправляет соседу, от которого получил запрос (query), и дальше по цепочке. Понятное дело, это все занимает больше времени, чем просто переключение на Feasible Successor, но, в итоге, мы получаем связь с подсетью.

А сейчас опасный момент: может, вы уже обратили внимание и насторожились, прочитав момент про эту веерную рассылку. Падение одного интерфейса вызывает нечто похожее на широковещательный шторм в сети (не в таких масштабах, конечно, но все-таки), причем чем больше в ней роутеров, тем больше ресурсов потратится на все эти запросы-ответы. Но это еще пол-беды. Возможна ситуация и похуже: представим, что роутеры, изображенные на картинке- это только часть большой и распределенной сети, т.е. некоторые могут находится за много тысяч километров от нашего R2, на плохих каналах и прочее. Так вот, беда в том, что, послав query соседу, роутер обязан дождаться от него reply. Неважно, что в ответе- но он должен прийти. Даже если роутер уже получил положительный ответ, как в нашем случае, он не может поставить этот маршрут в работу, пока не дождется ответа на все свои запросы. А запросы-то, может, еще где-нибудь на Аляске бродят. Такое состояние маршрута называется stuck-in-active. Тут нам нужно познакомится с терминами, отражающими состояние маршрута в EIGRP: active\passive route. Обычно они вводят в заблуждение. Здравый смысл подсказывает, что active значит маршрут “активен”, включен, работает. Однако тут все наоборот: passive это “все хорошо”, а состояние active означает, что данная подсеть недоступна, и маршрутизатор находится в активном поиске другого маршрута, рассылая query и ожидая reply. Так вот, состояние stuck-in-active (застрял в активном состоянии) может продолжатся до 3 минут! По истечение этого срока, роутер обрывает отношения соседства с тем соседом, от которого он не может дождаться ответа, и может использовать новый маршрут через R4.

История, леденящая кровь сетевого инженера. 3 минуты даунтайма это не шутки. Как мы можем избежать инфаркта этой ситуации? Выхода два: суммирование маршрутов и так называемая stub-конфигурация.

Вообще говоря, есть еще один выход, и он называется фильтрация маршрутов (route filtering). Но это настолько объемная тема, что впроу отдельную статью под нее писать, а у нас и так уже пол-книги получилось в этот раз. Поэтому на ваше усмотрение.

Как мы уже упоминали, в EIGRP суммирование маршрутов можно проводить на любом роутере. Для иллюстрации, представим, что к нашему многострадальному R2 подключены подсети от 192.168.0.0/24 до 192.168.7.0/24, что очень удобненько суммируется в 192.168.0.0/21 (вспоминаем binary math). Роутер анонсирует этот суммарный маршрут, и все остальные знают: если адрес назначения начинается на 192.168.0-7, то это к нему. Что будет происходить, если одна из подсетей пропадет? Роутер будет рассылать query-пакеты с адресом этой сети (конкретным, например, 192.168.5.0/24), но соседи, вместо того, чтобы уже от своего имени продолжить порочную рассылку, будут сразу в ответ слать отрезвляющие реплаи, мол, это твоя подсеть, ты и разбирайся.

Второй вариант- stub- конфигурация. Образно говоря, stub означает “конец пути”, “тупик” в EIGRP, т.е., чтобы попасть в какую-то подсеть, не подключенную напрямую к такому роутеру, придется идти назад. Роутер, сконфигурированный, как stub, не будет пересылать трафик между подсетями, которые ему стали известны от EIGRP (проще говоря, которые в show ip route помечены буквой D). Кроме того, его соседи не будут отправлять ему query-пакеты. Самый распространенный случай применения- hub-and-spoke топологии, особенно с избыточными линками. Возьмем такую сеть: слева- филиалы, справа- основной сайт, главный офис и т.п. Для отказоустойчивости избыточные линки. Запущен EIGRP с дефолтными настройками.

А теперь “внимание, вопрос”: что будет, если R1 потеряет связь с R4, а R5 потеряет LAN? Трафик из подсети R1 в подсеть главного офиса будет идти по маршруту R1->R5->R2(или R3)->R4. Будет это эффективно? Нет. Будет страдать не только подсеть за R1, но и подсеть за R2 (или R3), из-за увеличения объемов трафика и его последствий. Вот для таких-то ситуаций и придуман stub. За роутерами в филиалах нет других роутеров, которые вели бы в другие подсети, это “конец дороги”, дальше только назад. Поэтому мы с легким сердцем можем сконфигурировать их как stub’ы, что, во-первых, избавит нас от проблемы с “кривым маршрутом”, изложенной чуть выше, а во-вторых, от флуда query-пакетов в случае потери маршрута.

Существуют различные режимы работы stub-роутера, задаются они командой eigrp stub:

R1(config)#router eigrp 1
R1(config-router)#eigrp stub?
connected Do advertise connected routes
leak-map Allow dynamic prefixes based on the leak-map
receive-only Set IP-EIGRP as receive only neighbor
redistributed Do advertise redistributed routes
static Do advertise static routes
summary Do advertise summary routes

По умолчанию, если просто дать команду eigrp stub, включаются режимы сonnected и summary. Интерес представляет режим receive-only, в котором роутер не анонсирует никаких сетей, только слушает, что ему говорят соседи (в RIP есть команда passive interface, которая делает то же самое, но в EIGRP она полностью отключает протокол на выбранном интерфейсе, что не позволяет установить соседство).

Важные моменты в теории EIGRP, не попавшие в статью:

• В EIGRP можно настроить аутентификацию соседей
• Концепция graceful shutdown

Практика EIGRP

“Лифт ми Ап” купили фабрику в Калининграде. Там производят мозги лифтов: микросхемы, ПО. Фабрика очень крупная - три точки по городу - три маршрутизатора соединены в кольцо.

Но вот незадача - на них уже запущен EIGRP в качестве протокола динамической маршрутизации. Причём адресация конечных узлов совсем из другой подсети - 10.0.0.0/8. Все другие параметры (линковые адреса, адреса лупбэк интерфейсов) мы поменяли, но несколько тысяч адресов локальной сети с серверами, принтерами, точками доступа - работа не на пару часов - отложили на потом, а в IP-плане зарезервировали на будущее для Калининграда подсеть 172.16.32.0/20.

Сейчас у нас используются такие сети:

Как настраивается это чудо? Незамысловато, на первый взгляд:

router eigrp 1
network 172.16.0.0 0.0.255.255
network 10.0.0.0

В EIGRP обратную маску можно задавать, указывая тем самым более узкие рамки, либо не задавать, тогда будет выбрана стандартная маска для этого класса (16 для класса B - 172.16.0.0 и 8 для класса 8 - 10.0.0.0)

Такие команды даются на всех маршрутизаторах Автономной Системы. АС определяется цифрой в команде router eigrp, то есть в нашем случае имеем АС №1. Эта цифра должна быть одинаковой на всех маршрутизаторах (в отличии от OSPF).

Но есть в EIGRP серьёзный подвох: по умолчанию включено автоматическое суммирование маршрутов в классовом виде (в версиях IOS до 15).
Сравним таблицы маршрутизации на трёх калининградских маршрутизаторах:

Сеть 10.0.0.1/24 подключена у нас к klgr-center-gw1 и он о ней знает:

klgr-center-gw1:
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:35:23, Null0
C 10.0.0.0/24 is directly connected, FastEthernet1/0

Но не знает о 10.0.1.0/24 и 10.0.2.0/24/

Klgr-balt-gw1 знает о своих двух сетях 10.0.1.0/24 и 10.0.2.0/24, но вот сеть 10.0.0.0/24 он куда-то спрятал.

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:42:05, Null0
C 10.0.1.0/24 is directly connected, FastEthernet1/1.2
C 10.0.2.0/24 is directly connected, FastEthernet1/1.3

Они оба создали маршрут 10.0.0.0/8 с адресом next hop Null0.

А вот klgr-center-gw2 знает, что подсети 10.0.0.0/8 находятся за обоими его WAN интерфейсами.

D 10.0.0.0/8 via 172.16.2.41, 00:42:49, FastEthernet0/1
via 172.16.2.45, 00:38:05, FastEthernet0/0

Что-то очень странное творится.
Но, если вы проверите конфигурацию этого маршрутизатора, то, вероятно, заметите:

router eigrp 1
network 172.16.0.0
network 10.0.0.0
auto-summary

Во всём виновато автоматическое суммирование. Это самое большое зло EIGRP. Рассмотрим более подробно, что происходит. klgr-center-gw1 и klgr-balt-gw1 имеют подсети из 10.0.0.0/8, они их суммируют по умолчанию, когда передают соседям.
То есть, например, msk-balt-gw1 передаёт не две сети 10.0.1.0/24 и 10.0.2.0/24, а одну обобщённую: 10.0.0.0/8. То есть его сосед будет думать, что за msk-balt-gw1 находится вся эта сеть.
Но, что произойдёт, если вдруг на balt-gw1 попадёт пакет с адресатом 10.0.50.243, о котором тот ничего не знает? На этот случай и создаётся так называетмый Blackhole-маршрут:
10.0.0.0/8 is a summary, 00:42:05, Null0
Полученный пакет будет выброшен в эту чёрную дыру. Это делается во избежание петель маршрутизации.
Так вот оба эти маршрутизатора создали свои blackhole-маршруты и игнорируют чужие анонсы. Реально на такой сети эти три девайса друг друга так и не смогут пинговать, пока… пока вы не отключите auto-summary.

Первое, что вы должны сделать при настройке EIGRP:

router eigrp 1
no auto-summary

На всех устройствах. И всем будет хорошо:

Klgr-center-gw1:

C 10.0.0.0 is directly connected, FastEthernet1/0
D 10.0.1.0 via 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 via 172.16.2.37, 00:03:11, FastEthernet0/0

klgr-balt-gw1

10.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 is directly connected, FastEthernet1/1.2
C 10.0.2.0 is directly connected, FastEthernet1/1.3

klgr-center-gw2:

10.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 via 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 via 172.16.2.41, 00:11:48, FastEthernet0/1

Настройка передачи маршрутов между различными протоколами

Наша задача организовать передачу маршрутов между этими протоколами: из OSPF в EIGRP и наоборот, чтобы все знали маршрут до любой подсети.
Это называется редистрибуцией (перераспределением) маршрутов.

Для её осуществления нам нужна хотя бы одна точка стыка, где будут запущены одновременно два протокола. Это может быть msk-arbat-gw1 или klgr-balt-gw1. Выберем второй.

Из EIGRP в OSPF:

klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribute eigrp 1 subnets

Смотрим маршруты на msk-arbat-gw1:

msk-arbat-gw1#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O E2 10.0.0.0/8 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 via 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 is variably subnetted, 30 subnets, 5 masks
O E2 172.16.0.0/16 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.2.32/30 is directly connected, FastEthernet0/1.7
O E2 172.16.2.36/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.40/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.44/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
C 172.16.2.128/30 is directly connected, FastEthernet0/1.8
O 172.16.2.160/30 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:13:21, FastEthernet1/0.911
C 172.16.2.196/30 is directly connected, FastEthernet1/0.911
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104
O 172.16.24.0/24 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 via 172.16.2.130, 00:13:21, FastEthernet0/1.8

O 172.16.160.0/24 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 is directly connected, Loopback0
O 172.16.255.48/32 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O E2 172.16.255.64/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.65/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.66/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O 172.16.255.80/32 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:13:21, FastEthernet0/1.8
via 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
198.51.100.0/28 is subnetted, 1 subnets
C 198.51.100.0 is directly connected, FastEthernet0/1.6
S* 0.0.0.0/0 via 198.51.100.1

Вот те, что с меткой Е2 - новые импортированные маршруты. Е2 - означает, что это внешние маршруты 2-го типа (), то есть они были введены в процесс OSPF извне

Теперь из OSPF в EIGRP. Это чуточку сложнее:

klgr-gw1(config)#router eigrp 1
klgr-gw1(config-router)#redistribute ospf 1 metric 100000 20 255 1 1500

Без указания метрики (вот этого длинного набора цифр) команда выполнится, но редистрибуции не произойдёт.

Импортированные маршруты получают метку EX в таблице маршрутизации и административную дистанцию 170, вместо 90 для внутренних:

klgr-gw2#sh ip route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 30 subnets, 4 masks
D EX 172.16.0.0/24 [170 /33280] via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [90 /30720] via 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 is directly connected, FastEthernet0/0
D 172.16.2.40/30 via 172.16.2.37, 00:38:59, FastEthernet0/0
via 172.16.2.46, 00:38:59, FastEthernet0/1
….

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

Маршрут по умолчанию

Теперь самое время проверить доступ в интернет. Из Москвы он прекрасно себе работает, а вот если проверить, например из Петербурга (помним, что мы удалили все статические маршруты):

PC>ping linkmeup.ru

Pinging 192.0.2.2 with 32 bytes of data:

Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.

Ping statistics for 192.0.2.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Это связано с тем, что ни spb-ozerki-gw1, ни spb-vsl-gw1, ни кто-либо другой в нашей сети не знает о маршруте по умолчанию, кроме msk-arbat-gw1, на котором он настроен статически.
Чтобы исправить эту ситуацию, нам достаточно дать одну команду в Москве:

msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information originate

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

Интернет теперь доступен:

PC>tracert linkmeup.ru

Tracing route to 192.0.2.2 over a maximum of 30 hops:

1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2

Полезные команды для траблшутинга

1) Список соседей и состояние связи с ними вызывается командой show ip ospf neighbor

msk-arbat-gw1:

Neighbor ID Pri State Dead Time Address Interface
172.16.255.32 1 FULL/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 FULL/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 FULL/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/DR 00:00:33 172.16.2.197 FastEthernet1/0.911

2) Или для EIGRP: show ip eigrp neighbors

IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58

3) С помощью команды show ip protocols можно посмотреть информацию о запущенных протоколах динамической маршрутизации и их взаимосвязи.

Klgr-balt-gw1:

Routing Protocol is «EIGRP 1 »

Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: EIGRP 1, OSPF 1
Automatic network summarization is in effect
Automatic address summarization:
Maximum path: 4
Routing for Networks:
172.16.0.0

172.16.2.42 90 4
172.16.2.38 90 4
Distance: internal 90 external 170

Routing Protocol is «OSPF 1»
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 172.16.255.64
It is an autonomous system boundary router
Redistributing External Routes from,
EIGRP 1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
172.16.2.32 0.0.0.3 area 0
Routing Information Sources:
Gateway Distance Last Update
172.16.255.64 110 00:00:23
Distance: (default is 110)

4) Для отладки и понимания работы протоколов будет полезно воспользоваться следующими командами:
debug ip OSPF events
debug ip OSPF adj
debug EIGRP packets

Попробуйте подёргать разные интерфейсы и посмотреть, что происходит в дебаге, какие сообщения летят.

Задача №7
На последок комплесная задачка.
На последнем совещании Лифт ми Ап было решено, что сеть Калининграда необходимо также переводить на OSPF.
Переход должен быть совершен без разрывов связи. Было решено, что лучшим вариантом будет параллельно с EIGRP поднять OSPF на трёх маршрутизаторах Калининграда и после того, как будет проверено, что вся информация о маршрутах Калининграда распространилась по остальной сети и наоборот, отключить EIGRP. за логотип сайта.

OSPF

EIGRP

route redistribution

packet tracer

сети для самых маленьких

Добавить метки

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

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

При изменениях в топологии требуется некоторое время (время сходимости или конвергенции ) для согласования информации в таблицах маршрутизации всех маршрутизаторов сети. Время сходимости является важным фактором при выборе протокола маршрутизации.

Маршрутная информация собирается по определенным правилам в ходе реализации алгоритма динамического обмена обновлениями ( update , модификациями) между маршрутизаторами. Протокол маршрутизации должен создавать и поддерживать таблицы маршрутизации , где хранятся пути ко всем доступным сетям назначения, а также извещать другие маршрутизаторы о всех известных ему изменениях в топологии сети, т.е. решать задачу обнаружения сетей .

Совокупность сетей, представленных маршрутизаторами под общим административным управлением, образует автономную систему ( рис. 3.1). Примерами автономных систем являются сети отдельных провайдеров ISP . Автономные системы нумеруются (AS1, AS2, …AS107, …) и в некоторых протоколах ( IGRP , EIGRP ) эти номера используются при конфигурировании.

Рис. 3.1.

В настоящем курсе рассматривается маршрутизация только внутри автономной системы, где работают протоколы внутренней маршрутизации (Interior Gateway Protocols - IGP ), к которым относятся RIP , RIPv2, EIGRP , OSPF , IS-IS . Маршрутизацию между автономными системами производят протоколы внешней маршрутизации ( Exterior Gateway Protocols - EGP ). Примером протокола внешней маршрутизации является протокол BGP , который работает на пограничных маршрутизаторах автономных систем ( рис. 3.1).

Совокупность протоколов маршрутизации приведена в табл. 3.1 , из которой следует, что протоколы динамической маршрутизации, работающие внутри автономных систем, в свою очередь , подразделяются на протоколы вектора расстояния (distance-vector) и протоколы состояния канала (link-state) .

Протоколы вектора расстояния определяют расстояние и направление, т.е. вектор соединения в составной сети на пути к адресату. При использовании протокола вектора расстояния маршрутизаторы посылают всю или часть таблицы маршрутизации соседним (смежным) маршрутизаторам. В таких протоколах как RIP и RIP-2 расстояние выражается в количестве переходов (hop count) в соединении на пути от узла источника к адресату назначения. Обмен обновлениями ( update ) или модификациями происходит периодически , даже если в сети нет никаких изменений, на что тратится значительная часть полосы пропускания. Получив обновление маршрутной информации, маршрутизатор может заново вычислить все известные пути и модернизировать таблицу маршрутизации.

Протоколы состояния канала создают полную картину топологии сети и вычисляют кратчайшие пути ко всем сетям назначения. Если путей с одинаковой метрикой несколько, то выбирается первый из вычисленных. Рассылка обновлений маршрутной информации производится только при изменениях топологии сети . Протоколы состояния канала (или соединения) быстрее реагируют на изменения в сети по сравнению с протоколами вектора расстояния, но при этом требуют больших вычислительных ресурсов.

Когда инкапсулированный в кадр пакет прибывает на входной интерфейс , маршрутизатор декапсулирует его, затем использует таблицу маршрутизации, чтобы определить, по какому маршруту направить пакет, т.е. на какой свой выходной интерфейс передать поступивший пакет . Выходной интерфейс связан с наиболее рациональным маршрутом к адресату назначения. Этот процесс называется коммутацией или продвижением пакета. На выходном интерфейсе пакет инкапсулируется в новый кадр , при этом маршрутизатор добавляет информацию для формирования кадра (см. материалы "Принципы и средства межсетевого взаимодействия").

Маршрутизаторы способны одновременно поддерживать несколько независимых протоколов с разными административными расстояниями (AD) , которые показывают степень достоверности источника маршрута. Чем меньше AD , тем выше достоверность (см. табл. 1.1). В таблицу маршрутизации устанавливаются маршруты, созданные протоколами с наименьшим административным расстоянием.

Определение протоколом маршрутизации наиболее рационального (оптимального) пути производится на основе определенного критерия - метрики . Значение метрики используется при оценке возможных путей к адресату назначения. В настоящем курсе рассматриваются следующие протоколы маршрутизации:

Перечисленные протоколы используют разные параметры метрики.

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

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

(Load)

Полоса пропускания (Bandwidth)	-	способность соединения передавать данные с некоторой скоростью. Например, соединения сети FastEthernet передающие данные со скоростью 100 Мбит/c, предпочтительней каналов Е1 со скоростью 2,048 Мбит/c.
Задержка (Delay)	-	это длительность времени прохождения пакета от источника до адресата назначения. Задержка зависит от количества промежуточных соединений и их типов, объема буферных устройств маршрутизаторов, сходимости сети и расстояния между узлами.
-	определяется количеством информации, загружающей сетевые ресурсы (маршрутизаторы и каналы). Чем больше загрузка, тем больше очереди на обслуживание, тем дольше пакет будет в пути.
Надежность (Reliability)	-	определяется интенсивностью ошибок на каждом сетевом соединении.
Количество переходов (Hop count)	-	это количество маршрутизаторов, через которые пакет должен пройти на пути к адресату назначения (число переходов от маршрутизатора к маршрутизатору).
Стоимость (Cost)	-	обобщенный параметр затрат на передачу пакета к адресату назначения. Иногда стоимость имеет произвольное значение, назначенное администратором.

Наиболее известным в сети Internet протоколом вектора расстояния (distance-vector) является Routing Information Protocol (RIP) , который использует в качестве метрики число переходов ( hop count ) на пути к адресату назначения.

Другим простым протоколом вектора расстояния является Interior Gateway Routing Protocol (IGRP ), который был разработан в корпорации Cisco. Для работы в больших сетях на смену ему пришел протокол Enhanced IGRP (EIGRP) , который включает много особенностей протоколов как типа link-state, так и distance-vector. Поэтому он, по сути, является гибридным протоколом. Однако разработчики фирмы Cisco относят его к протоколам distance-vector.

Протоколы вектора расстояния (RIP, IGRP) периодически рассылают обновления маршрутной информации. У протокола RIP этот период равен 30 сек. При этом обновляются таблицы маршрутизации, которые хранят всю информацию о маршрутах в сети. При изменении в сети маршрутизатор , обнаруживший такое изменение, сразу начинает обмен маршрутной информацией с соседними маршрутизаторами. Этот обмен идет последовательно от маршрутизатора к маршрутизатору с некоторой задержкой, определяемой временем модификации таблиц в каждом маршрутизаторе, а также специальным таймером. Поэтому сходимость (конвергенция) сети, когда все маршрутизаторы будут иметь согласованную информацию о сетевых соединениях, происходит медленно , что является недостатком протоколов вектора расстояния.

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

Протокол вектора расстояния RIP использует счетчик переходов ( hop count ) в качестве метрики, чтобы определить расстояние до определенного соединения в составной сети. Если существует несколько путей, то RIP выберет путь с наименьшим числом маршрутизаторов или переходов к адресату назначения. Однако выбранный маршрут не всегда является лучшим путем к адресату, поскольку выбранный маршрут с наименьшим числом устройств может характеризоваться меньшей скоростью передачи (более узкой полосой пропускания, меньшей пропускной способностью) по сравнению с альтернативными маршрутами, созданными другими протоколами. Кроме того, RIP не может направлять пакеты далее 15 переходов, поэтому он рекомендован для работы в малых и средних сетях. Рассылка обновлений протоколом первой версии RIPv1 производится в широковещательном режиме ( адрес 255.255.255.255 ).

Протокол первой версии RIPv1 требует, чтобы все устройства в подсети использовали одинаковую маску подсети, т.к. RIP не включает информацию о маске подсети в обновления маршрутизации. Такой метод получил название маршрутизации на основе классов (classful routing) , что ограничивает применение протокола RIPv1 в современных сетях.

Протокол вектора расстояния второй версии RIPVersion 2 (RIPv2 ) обеспечивает бесклассовую маршрутизацию CIDR (Classless Interdomain Routing ), поскольку в обновления маршрутизации включена информация о маске подсети (о префиксе). При этом внутри одной сети могут существовать подсети с масками переменной длины (Variable-Length Subnet Mask - VLSM ). В обновления также включена адресная информация о шлюзах по умолчанию. Рассылка обновлений протоколом версии RIPv2 производится в многоадресном режиме (

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

Такой метод построения и поддержки маршрутных таблиц существенно упрощает задачу администрирования сетей, в которых могут происходить изменения (например, расширение) или в ситуациях, когда какие-либо маршрутизаторы и/или подсети выходят из строя.

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

Современные протоколы маршрутизации делятся на две группы: протоколы типа «вектор-расстояние» и протоколы типа «состояние канала».

В протоколах типа «вектор-расстояние» каждый маршрутизатор рассылает список адресов доступных ему сетей («векторов»), с каждым из которых связано параметр «расстояния» (например, количество маршрутизаторов до этой сети, значение, основанное на производительности канала и т.п.). Основным представителем протоколов данной группы является протокол RIP (Routing Information Protocol, протокол маршрутной информации).

Протоколы типа «состояние канала» основаны на ином принципе. Маршрутизаторы обмениваются между собой топологической информацией о связях в сети: какие маршрутизаторы с какими сетями связаны. В результате каждый маршрутизатор имеет полное представление о структуре сети (причем это представление будет одинаковым для всех), на основе которого вычисляет собственную оптимальную таблицу маршрутизации. Протоколом этой группы является протокол OSPF (Open Shortest Path First, «открой кратчайший путь первым»).

Протокол RIP.

Протокол RIP (Routing Information Protocol, протокол маршрутной информации) является наиболее простым протоколом динамической маршрутизации. Он относится к протоколам типа «вектор-расстояние».

Под вектором протокол RIP определяет IP-адреса сетей, а расстояние измеряется в переходах («хопах», hope) – количестве маршрутизаторов, которое должен пройти пакет, чтобы достичь указанной сети. Следует отметить, что максимальное значение расстояния для протокола RIP равно 15, значение 16 трактуется особым образом «сеть недостижима». Это определило основной недостаток протокола – он оказывается неприменимым в больших сетях, где Возможны маршруты, превышающие 15 переходов.

Протокол RIP версии 1 имеет ряд существенных для практического использования недостатков. К числу важных проблем относятся следующие:

• Оцен ка расстояния только с учетом числа переходов. Протокол RIP не учитывает реальную производительность каналов связи, что может оказаться неэффективным в гетерогенных сетях, т.е. сетях, объединяющих каналы связи различного устройства, производительности, в которых используются разные сетевые технологии.
• Проблема медленной конвергенции . Маршрутизаторы, спользующие протокол RIP. Рассылают маршрутную информацию каждые 30 с, причем их работа не синхронизирована. В ситуации, когда некоторый маршрутизатор обнаружит, что какая-либо сеть стала недоступной, то в худшем случае (если проблема была выявлена сразу после очередной рассылки) он сообщит об это соседям через 30 с. Для соседних маршрутизаторов все будет происходить также. Это означает, что информация о недоступности какой-либо сети может распространятся маршрутизаторам в достаточно долго, очевидно, что сеть при этом будет находиться в нестабильном состоянии.
• Широковещательная рассылка таблиц маршрутизации . Протокол RIP изначально предполагал, что маршрутизаторы рассылают информацию в широковещательном режиме. Это означает, что отправленный пакет вынуждены получить и проанализировать на канальном, сетевом и транспортном уровне все компьютеры сети, в которую он направлен.

Частично указанные проблемы решаются в версии 2 (RIP2).

Протокол OSPF

Протокол OSPF (Routing (Open Shortest Path First, «открой кратчайший путь первым») является более новым протоколом динамической маршрутизации и относится к протоколам типа «состояние канала».

Функционирование протокола OSPF основано на использовании всеми маршрутизаторами единой базы данных, описывающей, как и с какими сетями связан каждый маршрутизатор. Описывая каждую связь, маршрутизаторы связы
вают с ней метрику – значение, характеризующее «качество» канала. Например, для сетей Ethernet со скоростью обмена 100 Мбит/с используется значение 1, а для коммутируемых соединений 56 Кбит/с – значение 1785. Это позволяет маршрутизаторам OSPF (в отличие от RIP, где все каналы равнозначны) учитывать реальную пропускную способность и выявлять эффективные маршруты. Важной особенностью протокола OSPF является то, что используется групповая, а не широковещательная рассылка.

Указанные особенности, такие как групповая рассылка вместо широковещательной, отсутствие ограничений на длину маршрута, периодический обмен только короткими сообщениями о состоянии, учет «качества» каналов связи позволяют использовать OSPF в больших сетях. Однако такое использование может породить серьезную проблему – большое количество циркулирующей в сети маршрутной информации и увеличение таблиц маршрутизации. А поскольку алгоритм поиска эффективных маршрутов является, с точки зрения объема вычислений, достаточно сложным, то в больших сетях могут потребоваться высокопроизводительные и, следовательно, дорогие маршрутизаторы. Поэтому возможность построения эффективных таблиц маршрутизации может рассматриваться и как достоинство, и как недостаток протокола OSPF.

Введение

Все о чем мы говорили в предыдущей главе, имело отношение к статической маршрутизации. Записи в таблице маршрутизации создавались при конфигурации интерфейса (для интерфейсов подключенных напрямую), добавлялись командой route (обычно из системных загрузочных файлов) или создавались с помощью ICMP перенаправления (при использовании неверных маршрутов).

Все это просто замечательно, если сеть маленькая. А именно, если существует только одна точка подключенияния к другим сетям и не существует запасных маршрутов (запасные маршруты могут быть использованы в случае выхода из строя основных). Если хотя бы одно из трех приведенных выше условий неверно, используется динамическая маршрутизация.

В этой главе рассматриваются протоколы динамической маршрутизации, которыми пользуются маршрутизаторы для общения друг с другом. Мы подробно рассмотрим RIP, протокол обмена информацией о маршрутизации (Routing Information Protocol), широко используемый протокол, который присутствует практически во всех версиях TCP/IP. Затем мы рассмотрим еще два протокола маршрутизации, OSPF и BGP. В конце главы мы познакомимся с новой техникой маршрутизации, которая называтеся безклассовой маршрутизацией между доменами, и которая начинает применяться в Internet для экономии адресов класса B.

Динамическая маршрутизация

Динамическая маршрутизация используется для общения маршрутизаторов друг с другом. Маршрутизаторы передают друг другу информацию о том, какие сети в настоящее время подключены к каждому из них. Маршрутизаторы общаются, используя протоколы маршрутизации. Пользовательский процесс, посредством которого маршрутизаторы могут общаться с соседними маршрутизаторами, называется демоном маршрутизации (routing daemon). Как видно из рисунка 9.1, демон маршрутизации обновляет таблицу маршрутизации в ядре в соответствии с информацией, которую он получает от соседних маршрутизаторов.

Динамическая маршрутизация не меняет способы, с помощью которых ядро осуществляет маршрутизацию на IP уровне, как описано в разделе главы 9. Мы назвали это механизмом маршрутизации (routing mechanism). Ядро точно так же просматривает свою таблицу маршрутизации, отыскивая маршруты к хостам, маршруты к сетям и маршруты по умолчанию. Меняется только способ помещения информации в таблицу маршрутизации - вместо запуска команды route или использования загрузочных файлов маршруты добавляются и удаляются динамически демоном маршрутизации, который работает постоянно.

Как было отмечено ранее, демон маршрутизации отвечает за политику маршрутизации (routing policy) , выбирая, какие маршруты необходимо поместить в таблицу маршрутизации. Если демон обнаружил несколько маршрутов к пункту назначения, он выбирает (каким-либо образом), какой маршрут лучше, и именно этот маршрут (единственный) добавляет в таблицу маршрутизации. Если демон определил, что канал изчез (возможно по причине выхода из строя маршрутизатора или телефонной линии), он может удалить соответствующие маршруты или добавить альтернативные маршруты, чтобы обойти возникшую неисправность.

В Internet, на сегодняшний день, используется множество различных протоколов маршрутизации. Internet организован как сообщество автономных систем (AS - autonomous systems), каждая из которых обычно администрируется независимо от остальных. Например, сеть, построенная в университетском городке, обычно считается автономной системой. Магистраль (backbone) NSFNET с точки зрения Internet это автономная система, потому что все маршрутизаторы на магистрали находятся под единым административным контролем.

Для каждой автономной системы выбирается собственный протокол маршрутизации, с помощью которого осуществляется взаимодействие между маршрутизаторами в этой автономной системе. Такой протокол называется протоколом внутренних маршрутизаторов ( IGP - interior gateway protocol) или протоколом внутридоменной маршрутизации (intradomain routing protocol). Наиболее популярный IGP - это протокол обмена информацией о маршрутизации (RIP - Routing Information Protocol). Более новый IGP это протокол Open Shortest Path First ( OSPF). Он был разработан как замена для RIP. Устаревший IGP, который в настоящее время не используется, HELLO - это IGP, который первоначально использовался на магистрали NSFNET вплоть до 1986 года.

Новые требования к маршрутизаторам Router Requirements RFC [ Almquist 1993] определяют, что маршрутизатор, который реализует любые динамические протоколы маршрутизации, должен поддерживать OSPF и RIP, а также может поддерживать другие IGP.

Существуют протоколы маршрутизации, которые называются протоколами внешних маршрутизаторов ( EGP - exterior gateway protocols) или протоколами междоменной маршрутизации (interdomain routing protocols). Они предназначены для общения между маршрутизаторами, находящихимися в разных автономных системах. Исторически (и к большому сожалению) предшественником всех EGP был протокол с тем же самым именем: EGP. Более новый EGP - протокол пограничных маршрутизаторов ( BGP - Border Gateway Protocol) в настоящее время используется между магистралью NSFNET и некоторыми региональными сетями, которые подключены к магистрали. Планируется, что BGP заменит собой EGP.

Демоны маршрутизации в Unix

В Unix системах обычно запускается демон маршрутизации, называемый routed. Он присутствует практически в каждой версии TCP/IP. Этот демон понимает только протокол RIP. (Мы опишем routed в следующем разделе.) routed предназначен для сетей малого или среднего размеров.

Альтернативная программа - gated. Этот демон поддерживает как IGP, так и EGP. [ Fedor 1988] описывает раннюю реализацию gated. На рисунке 10.1 приведены протоколы маршрутизации, поддерживаемые демоном routed и двуми версиями демона gated. Большинство систем, которые используют демоны маршрутизации, запускают routed, однако если возникает необходимость поддерживать разные протоколы маршрутизации, используется gated.

	Протоколы внутренних маршрутизаторов			Протоколы внешних маршрутизаторов
routed
gated, Version 2
gated, Version 3

Рисунок 10.1 Протоколы маршрутизации, поддерживаемые routed и gated.

Мы опишем RIP Version 1 в следующем разделе, а отличия RIP Version 2, OSPF и BGP соответственно в разделах , и этой главы.

RIP: протокол обмена информацией о маршрутизации

В этом разделе приводится обзор RIP, так как это наиболее широко используемый протокол маршрутизации. Официальная спецификация протокола RIP находится в RFC 1058 [ Hedrick 1988a], однако этот RFC был написан через несколько лет после того, как протокол получил широкое распространение.

Формат сообщения

RIP сообщения передаются в UDP датаграммах, как показано на рисунке 10.2. (Мы рассмотрим UDP в .)

Рисунок 10.2 Инкапсуляция RIP сообщения в UDP датаграмму.

На рисунке 10.3 показан формат RIP сообщения, вместе с IP адресами.

Если поле команда равно 1 - это запрос, если 2 - отклик. Существуют еще две значения поля команды (3 и 4), а также два недокументированных значения: опрос (5) и пункт опроса (6). В запросе находится требование к другой системе послать всю или часть ее таблицы маршрутизации. В отклике содержится вся или часть таблицы маршрутизации отправителя.

Поле версия обычно установлено в 1, однако для RIP Version 2 (раздел ) это значение устанавливается в 2.

Следующие 20 байт сдержат: семейство адресов (которое всегда равно 2 для IP адресов), IP адрес и соответствующий показатель. В следующих разделах мы увидим, что в роли показателя RIP выступает счетчик пересылок.

В RIP сообщении может быть объявлено до 25 маршрутизаторов. Ограничение в 25 определяется полным размером RIP сообщения, 20х25+4=504, меньше чем 512 байт. Из-за ограничения в 25 маршрутизаторов, на один запрос, как правило, требуется послать несколько откликов, чтобы передать всю таблицу маршрутизации.

Рисунок 10.3 Формат RIP сообщения.

Обычное функционирование

Давайте посмотрим, как обычно работает routed с использованием RIP. Номер зарезервированного порта для RIP - UDP порт 520.

• Инициализация. Когда демон стартует, он определяет все активизированные интерфейсы и посылает пакет с запросом на каждый интерфейс, с требованием к удаленным маршрутизаторам послать полные таблицы маршрутизации. В случае канала точка-точка этот запрос отправляется на другой конец канала. Запрос рассылается широковещательными сообщениями, если сеть их поддерживает. Порт назначения - UDP порт 520 (демон маршрутизации на другом маршрутизаторе). Характеристики подобного запроса следующие: поле команды установлено в 1, поле семейство адресов установлено в 0 и показатель установлен в 16. Подобный формат соответствует специальному запросу, в ответ на который требуется послать полную таблицу маршрутизации.
• Запрос принят. В случае специального запроса, который мы только что описали, запрашивающему отправляется полная таблица маршрутизации. Иначе обрабатывается каждый пункт в запросе: если присутствует маршрут на указанный адрес, показатель устанавливается в определенное значение, иначе показатель устанавливается в 16. (Показатель, установленный в 16, это специальное значение, которое означает "бесконечно" (infinity) и сообщает, что маршрута к этому пункту назначения не существует.) Возвращается ответ.
• Ответ принят. Если ответ признан корректным, таблица маршрутизации может быть обновлена. Могут быть добавлены новые записи, существующие записи могут быть модифицированы или удалены.
• Регулярное обновление маршрутизации. Каждые 30 секунд вся или часть таблицы маршрутизации отправляется каждому соседнему маршрутизатору. Таблица маршрутизации распространяется широковещательными сообщениями (в случае Ethernet) или отправляется на другой конец канала точка-точка.
• Незапланированное обновление. Происходит в том случае, если изменяется показатель маршрута. В этом случае нет необходимости посылать таблицу маршрутизации целиком, передается только та запись, которая была изменена.

С каждым маршрутом связан тайм-аут. Если система, использующая RIP, определила, что маршрут не был обновлен в течение трех минут, показатель маршрута устанавливается в состояние "бесконечно" (16) и помечается для удаления. Это означает, что было пропущено шесть 30-секундных обновлений от маршрутизатора, который объявил маршрут. Однако, удаление маршрута из локальной таблицы маршрутизации откладывается еще на 60 секунд, чтобы убедиться что маршрут действительно исчез.

Показатели (metrics)

В качестве показателя в RIP используются счетчик пересылок. Для всех непосредственно подключенных интерфейсов счетчик пересылок равен 1. Рассмотрим маршрутизаторы и сети, показанные на рисунке 10.4. Четыре пунктирные линии показывают широковещательные сообщения RIP.

Рисунок 10.4 Пример маршрутизаторов и сетей.

Маршрутизатор R1 объявляет маршрут к N2 со счетчиком пересылок равным 1, послав широковещательное сообщение на N1. (Бессмысленно объявлять маршрут к N1 в широковещательном сообщении, посланном на N1.) Он также объявляет маршрут к N1 со счетчиком пересылок равным 1, послав широковещательное сообщение на N2. Точно так же, R2 объявляет маршрут к N2 с показателем 1 и маршрут к N3 с показателем 1.

Если смежный с нами маршрутизатор объявил маршрут к удаленной сети со счетчиком пересылок равным 1, то для нас показатель к этой сети будет равен 2, так пакет необходимо послать сначала на наш маршрутизатор, чтобы получить доступ к сети. В примере, приведенном выше, показатель к N1 для R2 равен 2, так же как и показатель к N3 для R1.

Так как каждый маршрутизатор посылает свои таблицы маршрутизации соседям, определяется каждая сеть в каждой автономной системе (AS). Если внутри AS существует несколько путей от маршрутизатора к сети, маршрутизатор выбирает путь с наименьшим количеством пересылок и игнорирует другие пути.

Величина счетчика пересылок ограничена значением 15, что означает, что RIP может быть использован только внутри AS, где максимальное количество пересылок между хостами составляет 15. Специальное значение показателя, равное 16, указывает на то, что на данный IP адрес не существует маршрута.

Проблемы

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

Во-вторых, для RIP требуется очень много времени, чтобы восстановить функционирование сети, после того как вышел из строя маршрутизатор или канал. Время обычно составляет несколько минут. В это время могут возникнуть петли маршрутизации. В современных реализациях RIP существует множество рекомендаций, которые позволяют избавляться от петель маршрутизации и увеличить скорость сходимости сетей. В RFC 1058 [ Hedrick 1988a] подробно описано, как должен быть реализован RIP.

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

Мы воспользуемся программой ripquery, чтобы получить таблицы маршрутизации некоторых маршрутизаторов. ripquery отправляет один из недокументированных запросов (названный "опрос" (poll), при этом поле команда установливается в 5, рисунок 10.3) на маршрутизатор, требуя от него послать полную таблицу маршрутизации. Если ответ не получен в течении 5 секунд, посылается стандартный RIP запрос (поле команда установлено в 1). (Ранее мы говорили, что запрос с полем семейства протоколов установленным в 0 и с показателем установленным в 16 запрашивает полную таблицу маршрутизации маршрутизатора.)

На рисунке 10.5 показаны два маршрутизатора, у которых мы потребуем их таблицы маршрутизации на хосте sun. Мы запустим ripquery с sun, и получим информацию о маршрутизации с маршрутизатора следующей пересылки, netb:

sun % ripquery -n netb
504 bytes from netb (140.252.1.183): первое сообщение содержит 504 байта
тут удалено несколько строк
140.252.1.0, metric 1 верхний Ethernet на рисунке 10.5
140.252.13.0, metric 1 нижний Ethernet на рисунке 10.5
244 bytes from netb (140.252.1.183): второе сообщение с оставшимися 244 байтами
несколько строк удалено

Как мы и ожидали, netb объявляет нашу подсеть с показателем 1. Верхний Ethernet, к которому также подключен netb (140.252.1.0), имеет показатель равный 1. (Флаг -n говорит о необходимости выводить IP адреса в цифровом представлении, вместо того чтобы печатать имена хостов.) В этом примере netb сконфигурирован таким образом, чтобы считать все хосты, находящиеся в подсети 140.252.13, подключенными к нему напрямую - таким образом, netb ничего не знает о тех хостах, которые действительно находятся в подсети 140.252.13. Так как существует только одна точка подключения к подсети 140.252.13, объявление различных показателей для каждого хоста не имеет практического смысла.

Рисунок 10.5 Два маршрутизатора netb и gateway, на которые мы послали запрос об их таблицах маршрутизации.

На рисунке 10.6 показан обмен пакетами, который получен с помощью команды tcpdump. Мы указали SLIP интерфейс с опцией -i sl0.

sun % tcpdump -s600 -i sl0
1 0.0 sun.2879 > netb.route: rip-poll 24
2 5.014702 (5.0147) sun.2879 > netb.route: rip-req 24
3 5.560427 (0.5457) netb.route > sun.2879: rip-resp 25:
4 5.710251 (0.1498) netb.route > sun.2879: rip-resp 12:

Рисунок 10.6 Вывод команды tcpdump при запуске программы ripquery.

Первый отправляемый запрос - это команда опроса RIP (poll) (строка 1). В этом месте отрабатывается тайм-аут в 5 секунд, после чего отправляется обычный RIP запрос (строка 2). Число 24 в конце строк 1 и 2 это размер пакетов запроса в байтах: 4 байта RIP заголовок (с командой и версией), после чего следует один 20-байтовый адрес и показатель.

В строке 3 показан первый отклик, причем число 25 в конце строки указывает, что в сообщении находится 25 пар адресов и показателей, что, как мы рассчитали ранее, составляют 504 байта. Именно эту информацию выдает ripquery. Мы указали опцию -s600 для tcpdump, сообщая о необходимости прочитать из сети 600 байт. Это позволяет принять UDP датаграмму целиком (вместо того чтобы принять только ее первую часть) и затем напечатать содержимое RIP ответа.

В строке 4 показано второе ответное сообщение от маршрутизатора, со следующими 12-ю парами адресов и показателей. Мы можем рассчитать размер этого сообщения, который будет составлять 12х20+4=244, что как раз и печатала ripquery ранее.

Если мы обратимся к маршрутизатору, который находится позади netb, к gateway, то скорее всего получим, что показатель до нашей подсети 140.252.13.0 будет равен 2. Давайте проверим это предположение:

sun % ripquery -n gateway
504 bytes from gateway (140.252.1.4):
несколько строк удалено
140.252.1.0, metric 1 верхний Ethernet на рисунке 10.5
140.252.13.0, metric 2 нижний Ethernet на рисунке 10.5

Здесь показатель для верхнего Ethernet на рисунке 10.5 (140.252.1.0) остался равным 1, так как этот Ethernet непосредственно подключен и к gateway, и к netb, однако наша подсеть 140.252.13.0, как мы и ожидали, имеет показатель равный 2.

Еще один пример

Сейчас мы рассмотрим все обновления RIP, которые происходят в сети Ethernet без получения запросов, и посмотрим, что RIP регулярно отправляет своим соседям. На рисунке 10.7 показаны сети в noao.edu. Для простоты маршрутизаторы названы как Rn, где n - номер подсети. Каналы точка-точка показаны с помощью пунктирных линий с указанием IP адресов для каждого конца канала.

Рисунок 10.7 Сети noao.edu 140.252.

Мы запустили на Solaris 2.x программу snoop, напоминающую программу tcpdump, которую мы запускали на компьютере solaris. Эту программу можно запустить без привилегии суперпользователя, однако только для того, чтобы перехватывать широковещательные пакеты, групповые пакеты или пакеты, посылаемые на хост. На рисунке 10.8 показаны пакеты, пойманные за 60 секунд. Мы заменили большинство официальных имен хостов на наше представление в форме Rn.

solaris % snoop -P -tr udp port 520
0.00000 R6.tuc.noao.edu ->
4.49708 R4.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
6.30506 R2.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
11.68317 R7.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
16.19790 R8.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
16.87131 R3.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
17.02187 gateway.tuc.noao.edu ->
20.68009 R10.tuc.noao.edu ->

29.87848 R6.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
34.50209 R4.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
36.32385 R2.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
41.34565 R7.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
46.19257 R8.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
46.52199 R3.tuc.noao.edu -> 140.252.1.255 RIP R (1 destinations)
47.01870 gateway.tuc.noao.edu -> 140.252.1.255 RIP R (15 destinations)
50.66453 R10.tuc.noao.edu -> BROADCAST RIP R (4 destinations)

Рисунок 10.8 RIP широковещательные сообщения, пойманные на solaris за 60 секунд.

Благодаря флагу -P пакеты ловятся не перемешиваясь, благодаря -tr печатаются соответствующие временные марки, а благодаря port 520 захватываются только UDP датаграммы у которых в качестве порта источника или порта назначения указан порт 520.

Первые 6 пакетов приходят от R6, R4, R2, R7, R8 и R3, в каждом объявляется только одна сеть. Если мы заглянем внутрь пакетов, то увидим, что R6 объявляет маршрут к сети 140.252.6.0 со счетчиком пересылок равным 1, R4 объявляет маршрут к 140.252.4.0 со счетчиком пересылок равным 1, и так далее.

Маршрутизатор gateway, однако, объявил 15 маршрутизаторов. Мы можем запустить snoop с флагом -v и посмотреть содержимое RIP сообщения. (Этот флаг выдает полное содержимое входящего пакета: Ethernet заголовок, IP заголовок, UDP заголовок и RIP сообщение. Мы удалили всю информацию за исключением информации RIP.) На рисунке 10.9 показан вывод.

Сравните объявленные счетчики пересылок для сети 140.252.1 с топологией, приведенной на рисунке 10.7.

Очень странный факт заключается в том, что в выводе на рисунке 10.8 R10 объявляет четыре сети, тогда как на рисунке 10.7 показано только три. Если мы заглянем в RIP пакет с помощью snoop, то мы увидим следующие объявленные маршруты:

RIP: Address Metric
RIP: 140.251.0.0 16 (not reachable)
RIP: 140.252.9.0 1
RIP: 140.252.10.0 1
RIP: 140.252.11.0 1

Маршрут к сети класса В 140.251 фиктивный и не должен объявляться. Он не принадлежит к noao.edu.

solaris % snoop -P -v -tr udp port 520 host gateway
много строк удалено
RIP: Opcode = 2 (route response)
RIP: Version = 1

RIP: Address Metric

RIP: 140.252.101.0 1
RIP: 140.252.104.0 1

RIP: 140.252.51.0 2
RIP: 140.252.81.0 2
RIP: 140.252.105.0 2
RIP: 140.252.106.0 2

RIP: 140.252.52.0 3
RIP: 140.252.53.0 3
RIP: 140.252.54.0 3
RIP: 140.252.55.0 3
RIP: 140.252.58.0 3
RIP: 140.252.60.0 3
RIP: 140.252.82.0 3
RIP: 192.68.189.0 3

RIP: 140.252.57.0 4

Рисунок 10.9 RIP ответ от gateway.

Выражение "BROADCAST" в выводе snoop на рисунке 10.8 для RIP пакета, посланного R10, означает, что IP адрес назначения это ограниченный широковещательный адрес 255.255.255.255 (глава 12, раздел ), а не широковещательный адрес, указывающий на подсеть (140.252.1.255), который используют другие маршрутизаторы.

RFC 1388 определяет новые расширения RIP, которые в целом обычно называются RIP-2. Эти расширения не изменяют протокол, однако добавляют дополнительную информацию в поля, помеченные как "должны быть равны нулю" (must be zero) на рисунке 10.3. RIP и RIP-2 могут взаимодействовать в том случае, если RIP игнорирует поля, которые должны быть установлены в ноль.

На рисунке 10.10 показан формат сообщения RIP-2. Для RIP-2 поле версии устанавливается в 2.

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

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

Маска подсети для каждого пункта соответствует своему IP адресу. IP адрес следующей пересылки - это IP адрес пункта назначения, куда должны посылаться пакеты. Значение 0 в этом поле означает, что пакеты должны отправляться в систему, которая послала RIP сообщение.

Рисунок 10.10 Формат сообщения RIP2.

В RIP-2 предоставляется простая схема аутентификации. Первые 20 байт в RIP сообщении содержащие семейство адресов, которое установлено в 0xffff, а поле route tag, установлено в значение 2. Оставшиеся 16 байт содержат пароль в открытом виде.

И в заключение, RIP-2 поддерживает групповые запросы в дополнение к широковещательным (). При этом уменьшается загрузка хостов, которые не принимают RIP-2 сообщения.

OSPF: "открыть первым наикратчайший маршрут" (Open Shortest Path First)

OSPF это альтернативный RIP протокол внутренних маршрутизаторов. В OSPF сняты все ограничения, присущие для RIP. OSPF Version 2 описывается в RFC 1247 [ Moy 1991].

OSPF - протокол состояния канала (link-state) , тогда как RIP - протокол вектора расстояний (distance-vector) . Термин вектор расстояний означает, что сообщения, посылаемые RIP, содержат вектор расстояний (счетчик пересылок). Каждый маршрутизатор обновляет свою таблицу маршрутизации на основании векторов расстояний, который он получает от своих соседей.

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

С практической точки зрения основное отличие заключается в том, что протокол состояния канала работает значительно быстрее, чем протокол вектора расстояний. Нужно отметить, что в случае протокола состояния канала значительно быстрее осуществляется сходимость сети. Под понятием сходимости (converge) мы подразумеваем стабилизацию сети после каких-либо изменений, как, например, поломки маршрутизатора или выхода из строя канала. В разделе 9.3 [ Perlman 1992] сравниваются между собой два типа протоколов маршрутизации.

OSPF также отличается от RIP (как и многие другие протоколы маршрутизации) тем, что OSPF использует непосредственно IP. Это означает, что он не использует UDP или TCP. OSPF имеет собственную величину, которая устанавливается в поле протокола (protocol) в IP заголовке (рисунок 3.1).

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

1. OSPF может рассчитать отдельный набор маршрутизаторов для каждого типа сервиса IP (type-of-service) (рисунок 3.2). Это означает, что для любого пункта назначения может быть несколько пунктов в таблице маршрутизации, по одному для каждого типа сервиса IP.
2. Каждому интерфейсу назначается цена. Она может быть назначена на основании пропускной способности, времени возврата, надежности или по какому-либо другому параметру. Отдельная цена может быть назначена для каждого типа сервиса IP.
3. Если существует несколько маршрутов к одному пункту назначения с одинаковой ценой, OSPF распределяет траффик (поток данных) поровну между этими маршрутами. Это называется балансом загруженности.
4. OSPF поддерживает подсети: маска подсети соответствует каждому объявленному маршруту. Это позволяет разбить IP адрес любого класса на несколько подсетей различного размера. (Мы показали это в примере в разделе главы 3 и назвали подсетями переменной длины.) Маршруты к хостам объявляются с маской подсети, из всех единичных бит. Маршрут по умолчанию объявляется как IP адрес 0.0.0.0 с маской из всех нулевых битов.
5. Каналы точка-точка между маршрутизаторами не имеют IP адресов на каждом конце. Это называется сетями без адреса (unnumbered). Такой подход позволяет сэкономить IP адреса - очень ценный ресурс в настоящее время!
6. Используется простая схема аутентификации. Может быть указан пароль в виде открытого текста, так же как это делается в схеме RIP-2 (раздел ).
7. OSPF использует групповую адресацию () вместо широковещательной, что уменьшает загруженность систем, которые не распознают OSPF.

Так как большинство поставщиков маршрутизаторов поддерживают OSPF, он начинает постепенно замещать собой RIP в большинстве сетей.

BGP: протокол граничных маршрутизаторов (Border Gateway Protocol)

BGP это протокол внешних маршрутизаторов, предназначенный для связи между маршрутизаторами в различных автономных системах. BGP заменяет собой старый EGP, который использовался в ARPANET. BGP Version 3 определен в RFC 1267 .

RFC 1268 описывает использование BGP в Internet. Практически все, что приведенного ниже, взято именно из этих двух RFC. В дополнение, необходимо отметить, что в 1993 году BGP Version 4 разрабатывался таким образом (RFC 1467 [ Topolcic 1993]), чтобы поддерживать CIDR, который мы опишем в разделе этой главы.

Системы, поддерживающие BGP, обмениваются информацией о доступности сети с другими BGP системами. Эта информация включает в себя полный путь по автономным системам, по которым должен пройти траффик (поток данных), чтобы достичь этих сетей. Эта информация адекватна построению графа соединений AS (автономных систем). При этом возникает возможность легко обходить петли маршрутизации, а также упрощается процесс принятия решений о маршрутизации.

Во-первых, необходимо сказать, что IP датаграмма в AS может принадлежать как к локальному траффику, так и к транзитному траффику. Локальный - это траффик у которого источник и пункт назначения находятся в одной AS. При этом IP адреса источника и назначения указывает на хосты, принадлежащие одной автономной системе. Весь остальной траффик называется транзитным. Основное преимущество использования BGP в Internet заключается в уменьшении транзитного траффика.

Автономная система может принадлежать к следующим категориям:

1. Ограниченная (stub) AS автономная система имеет единственное подключение к одной внешней автономной системе. В такой автономной системе присутствует только локальный траффик.
2. Многоинтерфейсная (multihomed) AS имеет подсоединение к нескольким удаленным автономным системам, однако по ней запрещено прохождение транзитного траффика.
3. Транзитная (transit) AS имеет подключение к нескольким автономным системам и в соответствии с ограничениями может пропускать через себя как локальный, так и транзитный траффик.

Общая топология Internet состоит из транзитных, многоинтерфейсных и ограниченных автономных систем. Ограниченные и многоинтерфейсные автономные системы не нуждаются в использовании BGP - они могут использовать EGP, чтобы обмениваться информацией о доступности с транзитными автономными системами.

BGP позволяет использовать маршрутизацию, основанную на политических решениях (policy-based routing). Все правила определяются администратором автономной системы и указываются в конфигурационных файлах BGP. "Политические решения" не являются частью протокола, однако позволяют делать выбор между маршрутами, когда существует несколько альтернативных, и позволяют управлять перераспределением информации. Решения принимаются в соответствии с вопросами безопасности или экономической целесообразности.

BGP отличается от RIP или OSPF тем, что BGP использует TCP в качестве транспортного протокола. Две системы, использующие BGP, устанавливают TCP соединения между собой и затем обмениваются полными таблицами маршрутизации BGP. Обновления представляются в виде изменений таблицы маршрутизации (таблица не передается целиком).

BGP это протокол вектора расстояний, однако, в отличие от RIP (который объявляет пересылки к пункту назначения), BGP перечисляет маршруты к каждому пункту назначения (последовательность номеров автономных систем к пункту назначения). При этом исчезают некоторые проблемы, связанные с использованием протоколов вектора расстояний. Каждая автономная система идентифицируется 16-битным номером.

BGP определяет выход из строя канала или хоста на другом конце TCP соединения путем регулярной отправки сообщения "оставайся в живых" (keepalive) своим соседям. Рекомендуемое время между этими сообщениями составляет 30 секунд. Сообщение "оставайся в живых", которое используется на уровне приложений, независимо от TCP опций "оставайся в живых" ().

CIDR: бесклассовая маршрутизация между доменами (Classless Interdomain Routing)

В было сказано, что в настоящее время ощущается нехватка адресов класса В, поэтому узлам с несколькими сетями приходится присваивать несколько идентификаторов сетей класса С вместо одного идентификатора сети класса В. С одной стороны, появление адресов класса С решает одну проблему (переполнение количества адресов класса В). С другой стороны, появляется еще одна проблема: каждая сеть класса С требует записи в таблице маршрутизации. Бесклассовая маршрутизация между доменами (CIDR - Classless Interdomain Routing) это способ, который позволяет свести к минимуму рост таблиц маршрутизации в Internet. Этот способ также называется supernetting и описывается в RFC 1518 и в RFC 1519 [ Fuller et al. 1993], обзор можно найти в . CIDR одобрен Internet Architecture Board [ Huitema 1993]. RFC 1467 [ Topolcic 1993] кратко описывает состояние и развитие CIDR в Internet.

Основная концепция, заложенная в CIDR, заключается в том, что несколько IP адресов можно расположить определенным образом, что позволит уменьшить количество записей в таблице маршрутизации. Например, если один узел состоит из 16 адресов класса С, все 16 могут быть расположены таким образом, что они будут суммироваться, поэтому ко всем 16-ти можно будет обратиться через одну запись в таблице маршрутизации. Также, если 8 различных узлов подключены к одному и тому же Internetовскому "поставщику сервиса" через одну и ту же точку подключения к Internet, и если все 8 узлов имеют 8 различных IP адресов, они могут быть суммированы, после чего потребуется только одна запись в таблице маршрутизации, которая будет использоваться в Internet для всех 8 узлов.

Для того чтобы использовать подобное суммирование, необходимо, чтобы выполнялось три условия.

1. Несколько IP адресов, которые будут сложены вместе для маршрутизации, должны иметь в своих адресах одинаковые биты старшего порядка.
2. Таблицы маршрутизации и алгоритмы маршрутизации должны быть расширены таким образом, чтобы решения о маршрутизации принимались с использованием 32-битных IP адресов и 32-битных масок.
3. Протоколы маршрутизации, которые будут использоваться, должны быть расширены таким образом, чтобы позволять передачу 32-битных масок и 32-битных адресов. OSPF (раздел ) и RIP-2 (раздел ) способны передавать 32-битные маски, так же как и BGP Version 4.

В качестве примера скажем, что RFC 1466 [ Gerich 1993] рекомендует, чтобы новые адреса класса С в Европе находились в диапазоне 194.0.0.0 - 195.255.255.255. В шестнадцатиричном представлении эти адреса лежат в диапазоне 0xc2000000 - 0xc3ffffff. Это позволяет использовать 65536 различных идентификаторов сети класса С, однако все они имеют одинаковые 7 бит старшего порядка. В других (неевропейских) странах может быть использована единственная запись в таблице маршрутизации с IP адресом 0xc2000000 и 32-битной маской 0xfe000000 (254.0.0.0), чтобы организовать маршрут ко всем этим идентификаторам сетей класса С (в количестве 65536) через одну точку. Последовательность битов в адресе класса С (это биты, следующие за 194 или 195) может быть расположена в иерархическом порядке, например, по странам или по поставщикам сервиса, чтобы тем самым позволить дополнительное сложение внутри европейских маршрутизаторов с использованием дополнительных битов, стоящих после 7 бит старшего порядка в 32-битной маске.

CIDR также использует технику, которая определяет, что "лучшее совпадение это всегда наиболее длинное совпадение (longest match)": то есть совпадение максимального количества битов в 32-битной маске. Продолжая пример из предыдущего параграфа, нужно отметить следующее. Предположим, что один поставщик сервиса в Европе нуждается в использовании другого маршрутизатора для входа в Internet, чем вся остальная Европа. Если этот поставщик сервиса находится в диапазоне адресов 194.0.16.0 - 194.0.31.255 (16 идентификаторов сетей класса С), записи в таблице маршрутизации для этих сетей должны иметь IP адрес 194.0.16.0 и маску 255.255.240.0 (0xfffff000). Датаграмма, которая маршрутизируется на адрес 194.0.22.1, будет совпадать с этим пунктом таблицы маршрутизации и с одной из сетей класса С в остальной Европе. Однако, так как маска 255.255.240 "длиннее" чем маска 254.0.0.0, будет использован пункт в таблице маршрутизации, который имеет самую длинную маску.

Термин "бесклассовый" используется потому, что решения о маршрутизации принимаются на основе масок, накладываемых на полный 32-битный IP адрес. При этом не существует различия между адресами класса А, В или С.

Первоначально предполагается использовать CIDR в адресах новых сетей класса С. Благодаря внесению подобного изменения, значительно уменьшится рост таблиц маршрутизации в Internet, при этом не потребуется вносить никаких изменений в существующие маршрутизаторы. Хотя надо отметить, что подобное решение является кратковременной мерой. Более значительное улучшение можно получить, если CIDR будет использоваться для всех IP адресов, и существующие IP адреса будут переназначены (при этом все существующие хосты получат новые адреса!) в соответствии с ограничениями по странам, континентам и поставщикам сервисов . Выигрыш будет заключаться в следующем: современная таблица маршрутизации содержит до 10000 записей, тогда как после применения CIDR количество записей уменьшится до 200.

Краткие выводы

Существуют два основных типа протоколов маршрутизации: протоколы внутренних маршрутизаторов (IGP - interior gateway protocol), для маршрутизаторов, находящихся внутри автономной системы (autonomous system), и протоколы внешних маршрутизаторов (EGP - exterior gateway protocol), для маршрутизаторов, которые общаются с маршрутизаторами в других автономных системах.

Наиболее популярный IGP это Routing Information Protocol (RIP), однако постепенно новый IGP - OSPF становится более популярным, и все чаще и чаще начинает заменять собой RIP. Новый и популярный EGP это Border Gateway Protocol (BGP). В этой главе мы рассмотрели RIP и типы сообщений, которые он использует. RIP Version 2 это современное расширение, которое поддерживает разбиение на подсети и другие важные улучшения. Также мы описали OSPF, BGP и бесклассовую маршрутизацию между доменами (CIDR), новую технологию, которая призвана уменьшить размер таблиц маршрутизаций в Internet.

Существует еще два OSI протокола маршрутизации, на которые Вам следует обратить внимание. Протокол междоменной маршрутизации ( IDRP - Interdomain Routing Protocol) появился как версия BGP, модифицированная для использования с OSI адресами вместо IP. Протокол промежуточная система - промежуточная система (IS-IS - Intermediate System to Intermediate System) это OSI стандарт IGP. Он используется как протокол маршрутизации в сетях без соединения ( CLNP - Connectionless Network Protocol), OSI протокол, похожий на IP. IS-IS и OSPF очень похожи.

Динамическая маршрутизация до сих пор остается плодотворной почвой для исследований в области межсетевого взаимодействия. Поэтому выбрать, какой протокол маршрутизации необходимо использовать и какой демон маршрутизации необходимо запустить, довольно сложно. [ Perlman 1992] предоставляет множество подробностей.

Упражнения

1. Обратитесь к рисунку 10.9. По какому маршруту можно пройти от маршрутизатора kpno к маршрутизатору gateway?
2. Представьте, что маршрутизатор имеет 30 маршрутов, которые необходимо объявить с использованием RIP, при этом требуется одна датаграмма на 25 маршрутов и другая на оставшиеся 5. Что произойдет, если один раз в час первая датаграмма с 25-ю маршрутами будет потеряна?
3. В пакете OSPF имеется поле контрольной суммы, а в пакете RIP - нет. Почему?
4. Какой эффект дает балансировка загруженности, которая используется в OSPF. Как это влияет на транспортный уровень?
5. Прочитайте RFC 1058, откуда Вы узнаете дополнительные подробности того как реализуется RIP. На рисунке 10.8 каждый маршрутизатор объявляет только те маршруты, которые он предоставляет, и не объявляет другие маршруты, про которые он знает из широковещательных сообщений от других маршрутизаторов в сети 140.252.1. Как называется подобная технология?
6. В разделе главы 3 мы сказали, что в подсети 140.252.1 существует более чем 100 хостов в дополнение к 8 маршрутизаторам, которые мы показали на рисунке 10.7. Что делают эти 100 хостов с восемью широковещательными сообщениями, которые прибывают каждые 30 секунд (рисунок 10.8)?