Простой и чересчур “болтливый” протокол маршрутизации RIP все еще царствует в небольших ЛВС и WAN-сетях. Но для более крупных инфраструктур требуется уже более серьезный OSPF.
Поскольку протоколы маршрутизации определяют пути следования IP-пакетов, от них напрямую зависит, будет ли пакет доставлен вовремя и будет ли доставлен вообще. Они определяют и эффективность работы протоколов более высокого уровня, например TCP или SMTP, — будут ли те “страдать” от задержек или потери пакетов, дублирования дейтаграмм и прочих казусов, ответственность за возникновение которых несут службы маршрутизации. Проще говоря, успешная работа IP и элементов более высокого уровня зависит от эффективности IP-маршрутизации: если ее базовые службы не справляются со своими задачами, то нарушается работа всей системы. А если нарушается работа всей системы, то онлайновые покупатели не захотят возвращаться на ваш сайт, а ваши бизнес-подразделения не смогут вовремя получить нужную информацию.
Для понимания IP-маршрутизации требуются глубокие знания множества замысловатых протоколов. Хотя для желающих разобраться в процессах IP-маршрутизации написано немало учебников и доступно множество обучающих программ и курсов, мы все же решили осветить основные принципы двух самых часто встречающихся в корпоративных сетях протоколов маршрутизации — RIP (Routing Information Protocol) и OSPF (Open Shortest Path First). Надеемся, наша статья поможет вам сэкономить время и деньги.
Основы RIP
В первое время RIP распространялся вместе с операционной системой BSD и не рассматривался в качестве стандарта для Интернет. Однако впоследствии, подобно множеству других служб BSD, он стал критически важным элементом IP-сетей. В настоящее время в документах IETF закреплено две версии RIP: версия 1 (исходная) — в RFC 1058 и версия 2 — в RFC 1722 (Internet Standard 56). Обе они похожи, но между ними имеются некоторые важные различия.
Протокол RIP основан на алгоритме “длины векторов” (distance-vector), который связывает длину маршрута (число переходов — hops) с его вектором (сетью или хостом назначения). Информацию о маршрутах к тем или иным сетям/хостам устройства RIP получают от соседних маршрутизаторов и затем выбирают маршрут с наименьшим числом переходов. Как только маршрут к месту назначения выбран, он сохраняется в локальной базе данных, а информация обо всех остальных маршрутах к тому же месту назначения стирается. Периодически каждый маршрутизатор сообщает остальным об обнаруженных им маршрутах.
Количество переходов в RIP равно числу маршрутизаторов между отправителем и сетью/хостом назначения. Если маршрутизатор подключен к требуемой сети напрямую, то расстояние до нее — ноль переходов. Если для доступа к нужной сети требуется лишь переслать дейтаграммы через соседний маршрутизатор, то расстояние до нее равно одному переходу. Когда маршрутизатор рассылает информацию о найденном маршруте, он увеличивает число переходов на единицу. Как только эти данные поступают на соседние маршрутизаторы, они сравниваются с информацией их собственных баз данных. Если какой-нибудь из предложенных маршрутов оказывается короче, нежели хранящийся в базе данных, он заносится в локальную таблицу маршрутизации, а маршрутизатор, с которого пришло сообщение, становится первым узлом для пересылки трафика по этому маршруту.
Поясним вышесказанное с помощью схемы (см. рисунок). В нашем примере маршрутизатор А разошлет информацию о маршруте в один переход до Ethernet-сегмента и сети Интернет, к которым он подсоединен напрямую. Маршрутизатор В разошлет информацию о маршрутах длиной в один переход до своей локальной сети Ethernet и WAN-сети, а также о маршрутах с несколькими переходами до удаленных сетей (включая сегмент ЛВС, где находится сервер Z). Вся эта информация будет передаваться с периодичностью 30 с. “Узнав” о маршрутах друг от друга, оба маршрутизатора будут рассылать их дальше.
В соответствии с моделью “длины векторов” маршрутизатор В “увидит”, что расстояние до сегмента с сервером Z равно одному переходу через маршрутизатор А, в то время как маршрутизатор А будет считать расстояние до WAN-сети равным одному переходу через маршрутизатор В. Получив информацию друг от друга, оба маршрутизатора “узнают”, что расстояние до их локальных сегментов Ethernet через соседний маршрутизатор — один переход. Поскольку полученная длина маршрута окажется больше длины маршрута, хранящегося во внутренней базе данных (ЛВС подключены напрямую — ноль переходов), то оба устройства проигнорируют новую информацию о маршруте к сегментам ЛВС.
RIP и нештатные ситуации
Протокол RIP допускает максимум 15 переходов. Любой пункт назначения, который находится далее 15 переходов, считается “недосягаемым”. Если сообщения о каком-нибудь маршруте не приходят в течение 3 мин (180 с), то соответствующее число переходов устанавливается равным 16. Таким образом маршрут признается недействительным, и эта информация в течение 120 с рассылается остальным маршрутизаторам, чтобы они тоже узнали о недоступности данного маршрута.
Проблема возникнет, если в то же самое время устаревшая информация о маршруте поступит от других удаленных маршрутизаторов. Поскольку число переходов будет значиться меньше 16, то маршрутизаторы примут эти неверные данные и станут направлять пакеты в “черную дыру”. Предположим, что в результате сбоя в работе сегмента с сервером Z маршрутизатор А удалил информацию о маршруте к этому сегменту из своей локальной таблицы маршрутизации. Но при следующем обновлении данные о маршруте к сегменту Z, поступившие с маршрутизатора В (с числом переходов, равным двум), могут быть записаны в базу маршрутизатора А как кратчайший путь к месту назначения. В результате маршрутизатор А посчитает, что кратчайший путь к сегменту Z лежит через маршрутизатор В и отошлет трафик для этого сегмента к этому маршрутизатору, а тот, в свою очередь, перенаправит его обратно к маршрутизатору А.
Одним из способов предотвращения подобного зацикливания является использование правила ограничения обновлений (split horizon), которое запрещает отправлять информацию о каком-либо маршруте в обратном направлении, т. е. туда, откуда она пришла. В нашем примере применение этого правила запретит узлу В отсылать на маршрутизатор А информацию о соединении с сегментом Ethernet. При этом маршрутизатор А может потерять из виду сегмент Z, но он никогда не получит информацию о маршруте к этому сегменту от устройства В.
Еще один алгоритм, предотвращающий образование маршрутных петель, — это “отравление” обратного маршрута (poison reverse). Согласно этому алгоритму, значение числа переходов для обратных маршрутов принудительно устанавливается равным 16. В нашем случае маршрутизатор В при рассылке обновлений укажет расстояние до сегмента Z, равным 16 переходам, чтобы этот маршрут не использовался маршрутизатором А. Заметьте, что ни один из этих механизмов не предотвращает возникновение сетевых маршрутных петель, охватывающих много переходов, они позволяют лишь бороться с локальными петлями.
RIP и масштабируемость
Самый большой недостаток RIP заключается в том, что он рассчитан на обработку маршрутов максимум с 15 переходами. Некоторые сети просто-напросто слишком велики и не укладываются в это ограничение. Более того, меньшее и равное число переходов не всегда означает оптимальность маршрута (полосу пропускания каналов связи RIP не учитывает вовсе). Например, от маршрутизатора В до Интернет существует два маршрута с одинаковым числом переходов, и более медленный маршрут через узел D может быть выбран только потому, что сообщение от него пришло раньше. И еще, поскольку каждый маршрутизатор рассылает свои таблицы каждые 30 с, то даже при штатной работе сообщения RIP могут занять значительную часть полосы пропускания WAN-каналов, особенно в больших сетях. Короче говоря, RIP не является оптимальным протоколом маршрутизации для сложных сетей с большим числом распределенных узлов.
Самые большие усовершенствования, появившиеся в RIP 2, — это поддержка масок подсетей переменной длины и агрегация маршрутов. Они позволяют более оптимально распределять сетевые адреса и уменьшают размер маршрутных сообщений. Кроме того, в RIP 2 используется многоадресная рассылка (чтобы снизить нагрузку на не участвующие в процессе маршрутизации локальные системы), а также имеется простенькая аутентификация, обеспечивающая хоть какую-то безопасность в многопользовательских средах.
Но несмотря на все эти доработки, RIP 2 подвержен тем же архитектурным ограничениям, что и RIP 1, и поэтому он все равно непригоден для сложных, многосегментных сетей.
Вместе с тем протокол RIP эффективен для небольших и средних по размеру сетей, особенно в ситуациях, когда его поддержка реализована в рабочих станциях и серверах (при этом, конечно, желательно использовать RIP 2). Поскольку RIP — это относительно простой протокол, он часто реализуется в качестве “слушающей” фоновой программы, которая позволяет устройствам узнавать о состоянии сети и избавляет от необходимости поддерживать статические таблицы маршрутизации. Но в больших сетях, как мы уже говорили, начинают возникать проблемы.
Маршрутизация OSPF
Протокол OSPF появился как ориентированный на IP-сети вариант протокола IS-IS. Он определен в нескольких документах IETF: в RFC 1131 описан OSPF 1 (устаревшая версия), в RFC 1583, — вероятно, самая распространенная версия OSPF 2, и, наконец, в RFC 2328 определен последний вариант OSPF 2 (Internet Standard 54).
При использовании OSPF на каждом маршрутизаторе содержится независимая база данных по административной области маршрутизации, включающая информацию о доступных сетях, маршрутизаторах и стоимости каждого соединения. Когда состояние сети, маршрутизатора или интерфейса изменяется, каждый обнаруживший это маршрутизатор (в пределах области) вносит информацию в локальную базу данных, а затем соответственно перестраивает карты маршрутизации. Выбор маршрута производится с учетом стоимости всех маршрутов к конкретной точке назначения и напрямую не зависит от числа переходов. Другими словами, для выбора оптимальных маршрутов в OSPF применяется алгоритм “стоимости векторов” (cost vector).
Эта модель предоставляет больше возможностей для улучшения маршрутизации (например, быстрее происходит синхронизация изменений), но требует большей вычислительной мощности и большего объема памяти от участвующих в процессе машин. По этой причине на рынке гораздо шире представлены системы с поддержкой RIP, нежели OSPF. Например, хотя во многих серверных ОС имеются те или иные OSPF-демоны, лишь очень небольшое число сетевых клиентов или устройств низшего класса поддерживают OSPF, поскольку даже для пассивного “прослушивания” приходится снабжать устройство полнофункциональным механизмом анализа базы данных OSPF.
В основе архитектуры OSPF лежит концепция административных областей. Маршрутизаторы, работающие в одной области, обмениваются подробной информацией о ней, но маршрутизаторам из удаленных областей передаются только общие сведения. Если имеется несколько областей, то для обмена информацией между ними организуется магистральная (стержневая) область. Через нее пограничные устройства будут обмениваться общей информацией, что означает наличие в OSPF двухуровневой иерархии обмена маршрутной информацией между областями (это относится не ко всему сетевому трафику, а только к сообщениям протоколов маршрутизации).
Областям присваиваются 32-битовые идентификаторы (обычно они представлены в виде адресов IPv4), магистраль же всегда имеет номер 0. Маршрутизаторы могут одновременно присутствовать в нескольких областях, но для каждой из них они должны хранить отдельную базу данных о состоянии соединений. Согласно терминологии OSPF, маршрутизатор, присутствующий одновременно в нескольких областях, называется ABR (Area Border Router), а маршрутизатор, обменивающийся данными с другим протоколом маршрутизации, — ASBR (Autonomous System Border Router).
Расчет стоимости в OSPF
При построении карты маршрутизации устройства OSPF в качестве метрики использует стоимость соединения. Стоимость можно рассчитывать исходя из различных параметров, но в большинстве реализаций таким параметром является доступная полоса пропускания. Расчет стоимости осуществляется делением некоей константы (например, 100 млн) на размер полосы пропускания конкретного интерфейса. Например, деля 100 млн на 10 млн (для 10-Мбит/с интерфейса Ethernet) мы получаем стоимость этого интерфейса, равную 10 единицам. Это в 10 раз выше стоимости 100-Мбит/с интерфейса (его стоимость равна единице). При прочих равных условиях маршрутизатор предпочтет маршрут с меньшей стоимостью, в данном случае через более скоростной интерфейс 100 Мбит/с.
Когда маршрутизаторы OSPF строят карты маршрутизации, то при расчете стоимости вектора (маршрута) используется общая стоимость исходящих интерфейсов между маршрутизатором и известными пунктами назначения. Поскольку в некоторых сетях скорость передачи данных в разных направлениях различна, то и стоимость одного и того же маршрута в разных направлениях может различаться. Собственно говоря, поэтому в расчетах используется только стоимость (пропускная способность) исходящих интерфейсов в направлении точки назначения.
Обратимся опять к нашему рисунку. Маршрутизаторы B, C, и D подсоединены к сети Frame Relay, помеченной как Область 0 (магистраль).
В нашем примере они связаны друг с другом при помощи соединений T1 (1,5 Мбит/с), значит, стоимость каждого сетевого интерфейса равна 64 единицам. Кроме того, маршрутизаторы соединены 128-Кбит/с резервными линиями ISDN (пунктирные линии), стоимость которых — 781 единица.
В соответствии с этой схемой маршрутизатор B, работая в штатном режиме, будет посылать все данные на маршрутизатор C по сети Frame Relay. Но если канал Frame Relay между ними выйдет из строя, он будет отсылать данные на маршрутизатор D, чтобы тот пересылал их маршрутизатору C; общая стоимость такого маршрута будет равна 128 единицам, что дешевле резервной коммутируемой линии (781). Если откажет вся сеть Frame Relay, то только в этом случае маршрутизатор B начнет пересылать данные по резервной линии. При аварии же на прямой резервной линии между узлами B и C маршрутизатор B сможет посылать данные по ISDN-соединению через узел D (общая стоимость такого маршрута равна 1562 единицам).
Посылая данные в Интернет, маршрутизатор C, вероятнее всего, выберет маршрут через узел D, поскольку это соединение обладает наименьшей стоимостью (путь через маршрутизатор B включает еще один дополнительный сегмент — ЛВС Ethernet, с минимальной стоимостью, равной единице). Но маршрутизатор C может отказаться от маршрута через узел B, если RIP-сети в г. Сан-Матео будет присвоена фиксированная стоимость, представляющая эту сеть как высокоскоростной Ethernet-сегмент. В этом случае для маршрутизатора C стоимость двух переходов через г. Манхассет будет равняться 128 единицам (64 + 64), в то время как стоимость двух переходов через г. Сан-Матео — всего лишь 65 единиц (64 + 1) (хотя правильнее было показать реальную стоимость всех трех отдельных сегментов сети — 64 + 1 + 64). Этот пример наглядно иллюстрирует тот факт, что использовать стоимость в качестве метрики эффективно только тогда, когда ее значения присваиваются обдуманно и последовательно.
Поддержание баз данных OSPF
Процессы построения и поддержания баз данных о состоянии каналов — это самая сложная часть OSPF, она требует четкого понимания структуры и механизмов этого протокола. Подробное описание данного предмета выходит за рамки нашей ознакомительной статьи. Однако некоторые основные принципы протокола мы все же постараемся изложить.
Как уже говорилось, в пределах маршрутизируемой области каждый OSPF-узел хранит собственную базу данных для всех сетей, маршрутизаторов и интерфейсов, относящихся к этой области. При нормальной работе сети маршрутизаторы просто обмениваются сообщениями “Hello”, представляющими собой небольшие дейтаграммы, в которых сообщается только о том, что такой-то маршрутизатор все еще присутствует в сети и нормально функционирует. Во время операций синхронизации происходит обмен различными сообщениями LSA (Link-State Advertisement); их специфика зависит от произошедшего события, состояния базы данных и других факторов.
Если всего лишь изменилось состояние интерфейса, то в базы данных маршрутизаторов области вносятся небольшие изменения. Но если в сети появляется новый маршрутизатор OSPF, ему приходится обнаруживать все маршрутизаторы, сети и интерфейсы в пределах области, и этот процесс может сильно загрузить сеть. В сетях с коллективным доступом и поддержкой механизма широковещания можно выделить маршрутизатор, с которого новые маршрутизаторы смогут быстро получать полные копии баз данных, что уменьшит нагрузку на сеть. Но в сетях типа “точка—точка” каждому маршрутизатору приходится самостоятельно получать всю информацию от других маршрутизаторов.
Синхронизация базы данных — это, пожалуй, самое сложное при работе OSPF в большой сети, поскольку успешное завершение долговременных сеансов синхронизации зависит от стабильной работы сети.
Но несмотря на отдельные трудности, протокол OSPF обладает массой полезных свойств, которые делают его отличным выбором для больших и сложных корпоративных сетей. Для небольших же сетей OSPF чересчур громоздок, и здесь лучше использовать протокол RIP.
Автор Эрик Холл
Вязто с Сети и системы связи
One Comment