Использование задержки для расчета показателей OSPF

Можно ли настроить OSPF для использования задержки в расчетах стоимости / метрики канала. Идея заключается в том, чтобы включить маршрутизацию на основе производительности, при которой самые быстрые и наименее перегруженные ссылки в сети будут выбираться динамически, а не полагаться на поведение по умолчанию OSPF, что приводит к тому, что ссылки со скоростью 100 Мбит / с имеют такую ​​же стоимость, что и ссылки со скоростью 1 Гбит / с.

Можно ли настроить OSPF для использования задержки в расчетах стоимости / метрики канала. Идея заключается в том, чтобы включить маршрутизацию на основе производительности, при которой самые быстрые и наименее перегруженные ссылки в сети будут выбираться динамически, а не полагаться на поведение по умолчанию OSPF, что приводит к тому, что ссылки со скоростью 100 Мбит / с имеют такую ​​же стоимость, что и ссылки со скоростью 1 Гбит / с.

Краткий ответ: нет, не только с OSPF

Длинный ответ:

Единственный способ для OSPF динамически рассчитывать пути на основе задержки / перегрузки - это использовать MPLS Traffic Engineering с автономной оптимизацией затрат MPLS TE на основе ваших критериев ; MPLS TE использует LSA OSPF для передачи информации о путях с коммутацией по меткам . Тем не менее, MPLS Traffic Engineering является тяжелым молотом, и многие сетевые операции не могут справиться с дополнительным рабочим процессом, введенным в обеспечение или устранение неполадок MPLS TE.

Другой ответ предполагает, что вам не следует корректировать затраты на соединение в зависимости от пропускной способности и использовать роль узла для затрат. Я не могу говорить за его сеть, но это руководство во многих случаях не нужно, поскольку путь с наименьшей стоимостью в правильно спроектированной топологии автоматически следует через ядро ​​сети. Я бы не стал настраивать неэффективную топологию с затратами на соединение ... просто естественным образом сделайте поток трафика через ядро ​​и убедитесь, что OSPF видит 1GE как лучший путь, чем канал FastEthernet. Это, естественно, произойдет, если вы правильно разметите топологию и будете использовать эталонную полосу пропускания с автоматической оплатой в рамках процесса OSPF. Убедитесь, что вы используете это на всех маршрутизаторах OSPF, чтобы они одинаково понимали стоимость канала.

Вы не должны полагаться на показатели / стоимость по умолчанию, а не на IGP или STP. Мой вопрос в одном вопросе о том, была ли разработана ЛВС, состоит в том, чтобы спросить, какая ссылка блокируется, если инженер не может ответить, не глядя, это убедительный признак того, что сеть не была разработана.

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

Я очень предпочитаю стандарт метрик на основе ролей , где PP, P-PE, PE-PE и т. Д. Каждый имеет одинаковое значение метрики, независимо от полосы пропускания или задержки. То есть я знаю, куда я хочу, чтобы мой трафик шел, для меня не имеет значения, что такое задержка или какая емкость, если мне не хватает пропускной способности, где я хочу, чтобы трафик проходил, я обновлю ссылки.

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

Независимо от того, как вы разрабатываете свой метрический стандарт, он будет полностью статичным и не будет знать о реальных условиях канала, таких как потеря пакетов, задержка, дрожание, емкость и т. Д. Если вы хотите, чтобы сеть реагировала более динамично (спрос, который я склонен считать, часто возникает из-за плохого планирования ) Чтобы изменить условия сети, вам нужно посмотреть в RSVP или даже SDN.

Другой вариант, если использовать PfR или OER, то есть маршрутизаторы, использовать активные зонды или данные сетевого потока для динамического выбора пути. Или, конечно, очень простой вариант - жестко кодировать значения затрат OSPF.

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

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