Есть ли причины не использовать BFD?

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

Так, если, например, его можно применять для обнаружения отказа канала по Ethernet, MPLS по нескольким переходам, на границе сети, для конвергенции IGP, для туннелей и т. Д. И т. Д., - почему бы его не использовать в определенных сценариях, и существуют ли другие появляющиеся альтернативы? быть в курсе?

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

Похоже, что при больших объемах трафика загрузка ЦП маршрутизатора растет (что не редкость), но примерно на 40-50% пакетов BFD ЦП не получает достаточно ресурсов.

Тем не менее, я нашел следующую информацию, которая предлагает дополнительные проблемы с BFD (из этой презентации NANOG есть больше в презентации, она хорошая, прочитайте ее!)

Какие предостережения?

• Два основных:
  1. BFD может иметь высокие потребности в ресурсах в зависимости от вашего масштаба.
  2. BFD не виден протоколам связывания уровня 2. (Ethernet LAG или POS-пакеты)

BFD ресурсные требования

• Количество сеансов BFD на каждой линейной плате или маршрутизаторе может повлиять на то, насколько хорошо BFD масштабируется для вас. - У каждой уникальной платформы есть свои ограничения.
• Были замечены связанные интерфейсы, поддерживающие min tx / rx 250 мс или 2 секунды.
• В некоторых случаях экземпляры BFD на маршрутизаторе, возможно, должны будут работать на процессоре маршрутизации в зависимости от реализации (сеансы BFD на основе несмежности).
• Протестируйте свою платформу перед развертыванием BFD. Попытайтесь поместить нагрузку на процессор RP или LC с вашими настроенными настройками. Это может быть сделано:
• Выполнение ресурсоемких команд
• Пакеты затопления к TTL истекают в месте назначения

Требования к ресурсам BFD (продолжение)

• Какие ценности безопасно попробовать?
• Исходя из разговора с несколькими операторами, 300 мс с множителем 3 (обнаружение 900 мс), по-видимому, являются безопасным значением, которое довольно хорошо работает на большинстве устройств.
• Это значительное улучшение по сравнению с некоторыми альтернативами.

BFD и L2 link-bundling

• BFD не знает о базовых участниках связки L2.
• Пакет 4x10GigE L2 (802.3ad) будет выглядеть как одна смежная L3. Пакеты BFD будут передаваться по одному каналу, а не по всем 4 каналам.
• Сбой соединения с BFD на нем приведет к сбою всей смежности L3.
• Однако в некоторых сценариях отказавший членский канал может привести к удалению только одного пакета BFD. Последующие пакеты могут маршрутизироваться через рабочие членские ссылки.

Я видел две причины, почему BFD не был реализован:

1. Незнание этого (я был виновен в этом в течение некоторого времени).

2. Стоимость, если вы магазин Cisco. Хотя это возможно незначительно в зависимости от размера вашей организации, теперь для реализации BFD существуют связанные с этим расходы на лицензирование.

Начиная с периода ISR G2 / ASR, BFD больше не входит в пакет лицензирования «IP Base». Чтобы разблокировать BFD, вам нужно перейти как минимум до уровня лицензирования «Данные». Смотрите этот документ от Cisco.

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

Несколько вещей, чтобы завершить ответ Явано:

• Помните, что 40 г и 100 г Ethernet могут рассматриваться как связки, хотя и не такие, как LACP, но 4x10, 4x25 и 10x10
• На некоторых аппаратных средствах (например, на некоторых из старших моделей Juniper) BFD обрабатывается на линейной карте, что может быть преимуществом (без потерь при высокой нагрузке RE) или дефицитом (без немедленных потерь при смерти RE)
• Запуск BFD по каналу / пути, который уже является SPOF (например, одиночный оптоволоконный пакет), может быть хуже, чем просто увеличение задержки несущей

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

Обычно нам нужен BFD, если у нас есть 2 маршрутизатора, соединенных через L2-коммутатор 9 или любое другое облако L2). В этом случае, если один маршрутизатор выйдет из строя, состояние соединения не будет отражено на другом маршрутизаторе, так как коммутатор будет поддерживать соединение. Если бы это была просто P2P-связь (одиночный кабель) между маршрутизаторами, интерфейс мог бы выйти из строя сразу же при сбое однорангового узла, и IGP мог бы повторно сойтись через субсекундный интервал.

Итак, причина не использовать BFD: - BFD не поддерживается на коробке [es]; - BFD не нужен, так как у вас нет промежуточного устройства (используйте вместо этого udld и carrier-delay).