Czy są jakieś powody, aby nie używać BFD?

Przy wdrażaniu funkcji dwukierunkowego wykrywania przekierowania (BFD) wydaje się być bardzo elastyczna pod względem strojenia timera, lekka pod względem kosztów ogólnych, a elastyczność pod względem ogólnego zastosowania wydaje się imponująca.

Więc jeśli na przykład można go zastosować do wykrywania awarii łącza przez Ethernet, MPLS na wielu przeskokach, na brzegu sieci, do konwergencji IGP, do tuneli itp. - dlaczego może nie być stosowany w niektórych scenariuszach i czy istnieją inne pojawiające się alternatywy być świadomym?

Jestem tylko bezpośrednio świadomy jednego problemu z BFD, którym jest zapotrzebowanie na procesor. Obecnie badam problemy z Cisco 7301, który zwiększając ruch w godzinach szczytu, w porównaniu do reszty dnia, czasami BFD limituje czas i kieruje wycieczki do następnego łącza.

Wydaje się, że przy dużym natężeniu ruchu wykorzystanie procesora routera rośnie (co nie jest niczym niezwykłym), ale przy około 40-50% pakietów BFD procesora nie otrzymuje wystarczających zasobów.

Znalazłem jednak następujące informacje, które sugerują dodatkowe problemy z BFD (z tej prezentacji NANOG, jest więcej w prezentacji, jest dobra, przeczytaj!)

Jakie są zastrzeżenia?

• Dwa główne:
  1. BFD może mieć wysokie zapotrzebowanie na zasoby w zależności od skali.
  2. BFD nie jest widoczny dla protokołów pakietowania warstwy 2. (Ethernet LAG lub pakiety POS)

Żądania zasobów BFD

• Liczba sesji BFD na każdej karcie liniowej lub routerze może mieć wpływ na to, jak dobrze BFD skaluje się dla Ciebie. -Każda unikalna platforma ma swoje ograniczenia.
• Widoczne są dołączone interfejsy obsługujące min tx / rx wynoszące 250 ms lub 2 sekundy.
• W niektórych przypadkach instancje BFD na routerze mogą wymagać obsługi procesora trasy w zależności od implementacji (sesje BFD oparte na braku przylegania).
• Najpierw przetestuj platformę przed wdrożeniem BFD. Spróbuj załadować procesor RP lub LC za pomocą skonfigurowanych ustawień. Można to zrobić przez:
• Wykonywanie poleceń obciążających procesor
• Pakiety zalewające do TTL wygasają w miejscu docelowym

Żądania zasobów BFD (ciągdalszy)

• Jakie wartości można bezpiecznie wypróbować?
• Opierając się na rozmowie z kilkoma operatorami, 300ms z mnożnikiem 3 (wykrywanie 900ms) wydaje się być bezpieczną wartością, która działa dość dobrze na większości urządzeń.
• Jest to znacząca poprawa w porównaniu z niektórymi alternatywami.

Pakietowanie łączy BFD i L2

• BFD nie wie o podstawowych członkach pakietu linków L2.
• Pakiet 4x10GigE L2 (802.3ad) pojawiłby się jako pojedyncze przyleganie L3. Pakiety BFD byłyby przesyłane pojedynczym łączem członka, a nie ze wszystkich 4 łączy.
• Awaria łącza z BFD na nim spowodowałaby awarię całego sąsiedztwa L3.
• Jednak w niektórych scenariuszach nieudane łącze członka może spowodować odrzucenie tylko jednego pakietu BFD. Kolejne pakiety mogą być kierowane przez działające łącza członków.

Widziałem dwa powody, dla których BFD nie został wdrożony:

1. Nieznajomość tego (przez jakiś czas byłem tego winien).

2. Koszt, jeśli jesteś sklepem Cisco. Chociaż może być nieistotny w zależności od wielkości organizacji, wiążą się z tym koszty licencji związane z wdrożeniem BFD.

Od czasu ISR G2 / ASR BFD nie znajduje się już w pakiecie licencyjnym „IP Base”. Aby odblokować BFD, musisz uaktualnić przynajmniej do poziomu licencji „Dane”. Zobacz tę białą księgę od Cisco.

Ten wymóg licencyjny może nie stanowić problemu, ponieważ możesz już kupować wyższy poziom licencjonowania dla innych funkcji, ale należy o tym wiedzieć.

Kilka rzeczy do uzupełnienia odpowiedzi javano:

• Pamiętaj, że pakiety 40 gi 100 g sieci Ethernet można uznać za pakiety, choć nie takie same jak LACP, ale 4x10, 4x25 i 10x10
• Na niektórych urządzeniach (na przykład niektórych wyższej klasy jałowca) BFD jest obsługiwany na karcie linii, co może być zaletą (brak strat przy dużym obciążeniu RE) lub deficytem (brak natychmiastowej straty, jeśli RE umrze)
• Uruchomienie BFD na łączu / ścieżce, która jest już SPOF (np. Pakiet z pojedynczym włóknem), może być gorsze niż zwiększenie opóźnienia operatora

BFD to funkcja, która została opracowana w celu wykrywania problemu z połączeniem L2, gdy pomiędzy dwoma urządzeniami znajduje się jakieś urządzenie pośredniczące. BFD jest więc funkcją wykrywania awarii.

Zwykle potrzebujemy BFD, jeśli mamy 2 routery połączone przez przełącznik L2 9 lub dowolną inną chmurę L2). W takim przypadku, jeśli pojedynczy router ulegnie awarii, stan łącza nie zostanie odzwierciedlony na innym routerze, ponieważ przełącznik utrzyma połączenie. Gdyby to było tylko łącze P2P (pojedynczy kabel) między routerami, interfejs uległby awarii w przypadku awarii peera, a IGP ponownie zbiegałby się w odstępach poniżej sekundy.

Powodem, dla którego nie należy używać BFD, jest: - BFD nie jest obsługiwany w polu [es]; - BFD nie jest potrzebny, ponieważ nie masz pośredniego urządzenia (zamiast tego użyj udld i przewoźnika-opóźnienia).