BFD를 사용하지 않는 이유가 있습니까?

17

BFD (Bidirectional Forwarding Detection)를 구현할 때 타이머 튜닝, 모든 오버 헤드에 대한 경량 및 전체 응용 프로그램에 대한 유연성 측면에서 매우 유연 해 보입니다.

따라서 예를 들어 이더넷을 통한 링크 실패, 네트워크 에지, IGP 컨버전스, 터널 등의 경우 다중 홉을 통한 MPLS를 감지하는 데 적용 할 수있는 경우- 특정 시나리오에서 사용 되지 않는 다른 대안이있는 이유 알고?

— 매트
소스

18

CPU 요구 사항 인 BFD의 한 가지 문제 만 직접 알고 있습니다. 현재 Cisco 7301의 문제를 조사 중입니다. 피크 시간 동안 다른 시간대와 비교하여 더 많은 트래픽을 푸시 할 때 BFD가 시간 초과되어 다음 링크로 여행을 라우팅하는 경우가 있습니다.

트래픽 양이 많으면 라우터 CPU 사용량이 증가하지만 (이상하지는 않음) 약 40-50 % CPU BFD 패킷이 충분한 리소스를 수신하지 못하는 것 같습니다.

그러나 BFD와 관련된 추가 문제를 제안하는 다음 정보를 발견했습니다 ( 이 NANOG 프리젠 테이션에서 프리젠 테이션에 더 많은 내용이 있으며 좋은 것입니다. 읽어보십시오!)

경고는 무엇입니까?

두 가지 주요 사항 :
1. BFD는 규모에 따라 많은 리소스를 요구할 수 있습니다.
2. BFD는 레이어 2 번들링 프로토콜에는 보이지 않습니다. (이더넷 LAG 또는 POS 번들)

BFD 자원 요구

각 라인 카드 또는 라우터의 BFD 세션 수는 BFD 확장에 영향을 줄 수 있습니다. -각각의 고유 한 플랫폼에는 고유 한 한계가 있습니다.
최소 tx / rx 250ms 또는 2 초를 지원하는 번들 인터페이스가 나타났습니다.
경우에 따라 라우터의 BFD 인스턴스는 구현 (비 인접 기반 BFD 세션)에 따라 경로 프로세서에서 작동해야 할 수도 있습니다.
BFD를 배포하기 전에 먼저 플랫폼을 테스트하십시오. 구성된 설정으로 RP 또는 LC CPU에로드를 시도하십시오. 이 작업은 다음과 같이 수행 할 수 있습니다.
CPU가 많은 명령 실행
대상에서 TTL 로의 플러딩 패킷 만료

BFD 자원 요구 (계속)

어떤 값을 사용해도 안전합니까?
여러 운영자와의 대화를 바탕으로 승수 3 (900ms 감지)의 300ms는 대부분의 장비에서 상당히 잘 작동하는 안전한 값으로 보입니다.
이것은 일부 대안에 비해 크게 개선되었습니다.

BFD 및 L2 링크 번들

BFD는 기본 L2 링크 번들 멤버를 인식하지 못합니다.
4x10GigE L2 번들 (802.3ad)은 단일 L3 인접성으로 나타납니다. BFD 패킷은 4 개의 링크가 아닌 단일 멤버 링크를 통해 전송됩니다.
BFD와의 연결에 실패하면 전체 L3 인접성이 실패합니다.
그러나 일부 시나리오에서는 실패한 멤버 링크로 인해 단일 BFD 패킷 만 삭제 될 수 있습니다. 후속 패킷은 작동중인 멤버 링크를 통해 라우팅 될 수 있습니다.

— jwbensley
소스

1

주목해야 할 또 다른 사항은 일부 플랫폼이 모든 유형의 인터페이스에서 BFD를 지원하지 않는다는 것입니다. 가장 유명한 (나에게) : Cisco 7600은 아주 최근까지 (15. 무언가 필요) SVI (Vlan) 인터페이스에서 BFD를 지원하지 않습니다.

— Sebastian Wiesinger

1

좋은 점은, 내가 작업하고있는 7301 문제인데, 그래도 여전히 원하는대로 매끄럽게 실행되지 않고 있으며 매우 새로운 12 IOS에 있습니다. 다른 7301과 7206은 괜찮습니다. Sebastian은 옳습니다. 우리가 아마도 이러한 공통 하드웨어 플랫폼에 있기를 원할 때만 큼 잘 지원하지 않는다는 것을 언급 할 가치가 있습니다.

— jwbensley 2016 년

1

LAG에서 BFD 실행을 해결하기위한 IETF 초안이 있습니다 : tools.ietf.org/html/draft-mmm-bfd-on-lags . 실제로 어느 곳에서도 구현되지는 않았지만이 문제는 매우 일반적인 시나리오이기 때문에 결국 해결 될 것입니다.

— 다리우스 Jahandarie

5

BFD가 구현되지 않은 두 가지 이유를 보았습니다.

그것에 대한 무지 (한동안 유죄였습니다).
Cisco 매장 인 경우 비용. 조직의 규모에 따라 무시할 수 있지만 BFD를 구현하는 데 필요한 라이센스 비용이 있습니다.

ISR G2 / ASR 기간에 따라 BFD는 더 이상 "IP Base"라이센스 패키지에 없습니다. BFD를 잠금 해제하려면 최소한 "데이터"라이센스 수준으로 업그레이드해야합니다. Cisco 의이 백서 를 참조하십시오 .

다른 기능에 대해 더 높은 라이센스 수준을 이미 구매하고있을 수 있으므로이 라이센스 요구 사항은 문제가되지 않을 수 있지만 알고 있어야합니다.

— 브렛 리 킨스
소스

+1 훌륭합니다. 기술적 인 이유 만 생각하고 있었지만 비용은 분명한 것입니다. 또한 단순히 모르고, 나는 또한 누군가에게 BFD에 대해 이야기 한 최초의 사람이었습니다. 두 가지 큰 포인트!

— jwbensley 2016 년

3

javano의 답변을 마무리 할 몇 가지 사항 :

40g 및 100g 이더넷은 LACP와 동일하지 않지만 4x10, 4x25 및 10x10이지만 번들로 간주 될 수 있습니다.
일부 하드웨어 (예 : 고급 주니퍼의 일부)에서 BFD는 라인 카드에서 처리되므로 이점 (높은 RE로드에서 손실이 없음) 또는 적자 (RE가 사망 할 경우 즉각적인 손실이 없음)
이미 SPOF 인 링크 / 경로에서 BFD를 실행하면 (예 : 단일 파이버 번들) 단순히 캐리어 지연을 업하는 것보다 나쁠 수 있습니다.

— 랩탑 006
소스

2

BFD는 두 피어간에 중간 장치가있을 때 L2 연결 문제를 감지하기 위해 개발 된 기능입니다. BFD는 고장 감지 기능입니다.

L2 스위치 9 또는 다른 L2 클라우드를 통해 서로 연결된 2 개의 라우터가있는 경우 일반적으로 BFD가 필요합니다. 이 경우 단일 라우터가 다운되면 스위치가 링크를 유지하므로 링크 상태가 다른 라우터에 반영되지 않습니다. 라우터 간 P2P 링크 (단일 케이블) 인 경우 피어의 장애가 발생하면 인터페이스가 바로 중단되고 IGP가 1 초 미만의 간격으로 수렴합니다.

따라서 BFD를 사용하지 않는 이유는 다음과 같습니다.-BFD는 상자에서 지원되지 않습니다. -중간 장치가 없으므로 BFD가 필요하지 않습니다 (대신 udld 및 carrier-delay 사용).

— 바실리 M
소스