Назад | Перейти на главную страницу

Протоколы маршрутизации, вектор расстояния и состояние канала

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

Вектор расстояния

Протоколы чистого вектора расстояния встречаются редко; единственное, что действительно осталось в использовании, это ПОКОЙСЯ С МИРОМ. EIGRP, проприетарный протокол Cisco, технически также является вектором расстояния, но в нем используются несколько оптимизация которые позволяют преодолеть традиционные недостатки протоколов вектора расстояния. Протоколы вектора расстояния не распространяют никакой информации о топологии; они просто объявляют следующий переход к маршруту вместе со стоимостью.

Плюсы:

  • Требуется минимальная конфигурация.
  • Низкая нагрузка на ЦП / память.

Минусы:

  • Склонен к петлям маршрутизации (менее применим к EIGRP).
  • Медленное время сходимости.
  • Различные маршрутизаторы могут по-разному воспринимать «состояние» сети.

Состояние ссылки

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

Два основных используемых протокола состояния канала: OSPF и IS-IS; оба основаны на реализации Алгоритм Дейкстры. OSPF - наиболее известный из двух; IS-IS чаще встречается в сетях поставщиков услуг.

Плюсы:

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

Минусы:

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

Выбор протокола

С точки зрения того, какой тип протокола вы должны использовать, это зависит от ваших требований. В общем случае, если производитель не принуждает вас к этому, RIP использовать не следует. Если вы работаете во всей сети Cisco, EIGRP может быть запущен с очень небольшой ручной настройкой. Если совместимость между поставщиками является требованием, OSPF может быть лучшим выбором. Как упоминалось в другом ответе, если вы собираетесь обмениваться маршрутами с третьей стороной, BGP протокол выбора.

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

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

OSPF - это протокол состояния канала, открытый стандарт.

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

Я на 100% согласен с Джеймсом - используйте протокол маршрутизации на основе требований, а не на основе технологии.

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

Если вам нужна сложная инженерия трафика, и у вас есть сложная сеть с разнообразными маршрутами и очень разными скоростями каналов, и если вы находитесь в среде 100% cisco, вы можете рассмотреть возможность использования eigrp. В противном случае, если у вас сложная сеть и разнообразные маршруты, и вам нужно разумное время конвергенции, у вас действительно есть выбор только OSPF. Думаю, вы могли бы рассмотреть вопрос об ИГИЛ, если хотите гарантированную работу ...

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

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

Я не эксперт, но ... мне кажется, я припоминаю эту старую формулу для таких вещей:

(increasing stabilty) x (decreasing latency) = (weighted score for a route)

Просто вмешиваюсь .02 центов. Надеюсь, это поможет с вашими соображениями.

Из эта страница:

Сравнение алгоритма состояния канала с алгоритмом вектора расстояния

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

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

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

Скорость схождения: реализация LS - это O (| N | 2), для которого требуется сообщение O (| N || E |). Но с алгоритмом DV он может медленно сходиться и иметь петли маршрутизации, пока алгоритм сходится. Кроме того, алгоритм DV также страдает от проблемы счета до бесконечности.

Надежность: Для LS, когда маршрутизатор не работает, он может транслировать неверную стоимость для ближайшего. Кроме того, узел может повредить или отбросить пакет, который он получает в рамках широковещательной рассылки LS. Однако узел LS выполняет вычисления для своей собственной таблицы пересылки, а другой узел выполняет вычисления для себя. Таким образом, это каким-то образом разделяет вычисления внутри LS, что обеспечивает надежность. Для DV неверный путь наименьшей стоимости может быть передан более чем одному или целому узлу, поэтому неправильные вычисления будут обрабатываться во всей сети. Эта проблема DV намного хуже алгоритма LS.

И из эта страница:

Преимущества протоколов Distance Vector

Хорошо поддерживается

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