Чи є причини не використовувати BFD?

У плані реалізації двонаправленого виявлення переадресації (BFD) це здається дуже гнучким у налаштуванні таймеру, невелика вага щодо будь-яких накладних витрат та гнучкість щодо загального застосування виглядає дуже вражаючою.

Так, якщо, наприклад, це може бути застосовано для виявлення відмови по каналах через Ethernet, MPLS через декілька стрибків, на межі мережі, для конвергенції IGP, для тунелів тощо тощо - чому б це не було використано в певних сценаріях, можливо, і чи є інші альтернативи, що виникають бути проінформованим про?

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

Здається, що при великих обсягах трафіку використання процесора роутера зростає (що не є незвично), але приблизно 40-50% процесорних пакетів BFD не отримують достатньої кількості ресурсів.

Однак я знайшов наступну інформацію, яка говорить про додаткові проблеми з BFD (З цієї презентації NANOG, в презентації є більше, вона хороша, дайте їй прочитати!)

Що таке застереження?

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

Попит на ресурси BFD

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

Попит на ресурси BFD (продовження)

• Які значення можна безпечно спробувати?
• На основі розмови з декількома операторами, 300 мс з множником 3 (виявлення 900 мс) є безпечним значенням, яке працює на більшості обладнання досить добре.
• Це суттєве покращення порівняно з деякими альтернативами.

BFD і L2-зв'язок

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

Я бачив дві причини, через які BFD не було впроваджено:

1. Незнання цього (я певний час був винен у цьому).

2. Вартість, якщо ви магазин Cisco. Хоча це можливо незначно залежно від розміру вашої організації, зараз існує пов'язана вартість ліцензування для впровадження BFD.

За строком дії ISR G2 / ASR, BFD вже не входить в пакет ліцензування "База IP". Щоб розблокувати BFD, потрібно оновити принаймні рівень ліцензування "Дані". Дивіться цю білу книжку від Cisco.

Ця вимога щодо ліцензування може не бути проблемою, оскільки ви, можливо, вже купуєте більш високий рівень ліцензування для інших функцій, але варто пам’ятати про це.

Кілька речей, щоб закреслити відповідь javano:

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

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

Зазвичай BFD нам потрібен, якщо у нас є два маршрутизатори, з'єднані через комутатор L2 9 або будь-яку іншу хмару L2). У цьому випадку, якщо один маршрутизатор знизиться, стан посилання не відображатиметься на іншому маршрутизаторі, оскільки перемикач підтримуватиме зв'язок. Якби тільки маршрутизатор P2P (одиночний кабель) між маршрутизаторами, інтерфейс пішов би вниз прямо при збої однорангової програми, і IGP відновлюється через інтервал під секунду.

Отже, причиною не використовувати BFD є: - BFD не підтримується у вікні [и]; - BFD не потрібен, оскільки у вас немає проміжного пристрою (замість цього використовуйте udld і затримку оператора).