App-Aware Routing과의 BFD 프로토콜 관계 이해
소개
이 문서에서는 BFD Hello 패킷과 App-Aware Routing Tunnel 통계 간의 관계에 대해 설명합니다.
사전 요구 사항
요구 사항
Cisco에서는 다음 항목에 대해 알고 있는 것이 좋습니다.
- Cisco Catalyst SD-WAN(Software-Defined Wide Area Network).
- 애플리케이션 인식 라우팅.
- BFD.
사용되는 구성 요소
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
- Cisco Catalyst SD-WAN Manager.
- Cisco IOS® XE Catalyst SD-WAN Edge.
배경 정보
BFD(Bidirectional Forwarding Detection) 프로토콜은 Cisco IOS-XE Catalyst SD-WAN 디바이스 간 모든 데이터 플레인 터널을 통해 실행됩니다. 이 프로토콜은 Loss, Jitter 및 Latency로 보고된 터널 성능과 같은 터널의 라이브니스 및 경로 특성을 모니터링하는 데 사용됩니다.
에지 디바이스는 BFD Hello 프로브를 사용하여 터널의 패킷 손실, 지터 및 레이턴시를 측정합니다. 이러한 통계는 각 BFD Hello 프로브에 대해 계산되며 폴링 간격이라는 슬라이딩 기간에 적용됩니다.
이러한 손실, 레이턴시 및 지터 통계는 애플리케이션 인식 라우팅에서 정책에 설정된 요구 사항(SLA 클래스라고 함)을 기반으로 트래픽을 전달하는 데 사용됩니다. 이 요구 사항에서는 데이터 전달을 위해 선택한 터널에서 허용되는 최대 손실, 지터 및 레이턴시를 결정합니다.
이 때문에 BFD값의 변화가 터널 성능 계산에 어떤 영향을 줄 수 있는지, 원칙적으로 손실을 의미하는지를 파악하는 것이 매우 중요하다. BFD 매개변수는 다음과 같습니다.
| 매개변수 |
기본값 |
범위 |
Use |
| BFD hello 간격 |
1초 |
1~65535초 |
터널 연결의 라이브니스를 탐지하고 터널의 결함을 탐지하기 위한 패킷입니다. |
| 폴링 간격 |
10분 (60만 밀리초) |
1~4,294,967밀리초 |
통계를 제공하기 위해 버킷 측정값을 계산하는 빈도입니다. |
| 승수 |
6 |
1~6 |
평균 손실, 평균 대기 시간 및 평균 지터를 계산하는 시간을 지정하기 위해 폴링 간격을 곱하는 값입니다. |
터널 성능 통계 계산
기본값으로 설정된 BFD 매개변수의 경우 통계 계산은 다음과 같이 수행됩니다.
폴링 간격/BFD Hello 간격 = 600,000ms/1000ms = 버킷당 600BFD Hello.
승수가 6으로 설정되었으므로 6개의 버킷을 사용하여 평균 지연, 지터 및 손실을 계산함을 의미한다. 기본값은 1시간입니다. 이 총 시간을 app-route 간격이라고도 합니다.
앱 경로 간격 = 폴링 간격 * 배수 = 600,000ms x 6 = 3,600,000ms = 1시간 같음.
App-Aware Routing에서는 App-Route 통계를 계산하여 데이터 평면의 변경 사항을 확인합니다. Edge 디바이스가 앱 경로 통계를 활용하려면 허용되는 최대 패킷 지터, 손실 및 레이턴시가 설정된 AAR 정책에 SLA 클래스를 지정해야 합니다. 이러한 SLA 클래스는 SLA에 따라 지정된 애플리케이션에 대한 트래픽을 라우팅하기 위해 AAR 정책에서 사용됩니다.
에지 디바이스에 구성되면 AAR 통계를 사용하여 모든 버킷(전체 앱 경로 간격)으로 계산된 통계에서 제공하는 평균 손실, 평균 레이턴시, 평균 지터와 비교합니다. 또한 SLA는 기본적으로 10분마다 각 폴링 간격 후에 업데이트됩니다.
평균 손실, 평균 지터 및 평균 레이턴시를 구하려면 다음과 같은 방정식을 사용합니다.
평균 손실 = (모든 버킷의 총 손실 * 100) / 총 패킷.
평균 레이턴시 = (모든 버킷의 총 손실)/버킷의 양.
평균 지터 = (모든 버킷의 총 지터)/버킷의 양.
각 버킷의 평균과 함께 이러한 값의 계산은 CLI에서 다음과 같이 검토할 수 있습니다.
vEdge#show app-route stats
cEdge#show sdwan app-route stats
GUI에서는 평균 손실, 평균 레이턴시, 평균 지터만 Monitor(모니터) > Overview(개요) > Application-Aware Routing(애플리케이션 인식 라우팅) 섹션에서 검토할 수 있습니다.
또한 Monitor(모니터) > Devices(디바이스) > Select Device(디바이스 선택) > WAN > Tunnel(터널) 섹션에서 검토할 수 있습니다.
손실과 관련된 BFD 값의 예
BFD Hello는 구성 가능한 값이므로 요구 사항에 따라 수정할 수 있습니다. 그러나 신중하게 고려한 후 수정해야 합니다. 그렇지 않으면 BFD 값에 따라 평균 손실 계산의 정확도가 달라지므로 왜곡된 계산이나 오탐 통계가 수신될 수 있습니다. 예를 들어, 기본값은 다음과 같습니다.
| 매개변수 |
기본값 |
| BFD hello 패킷 |
1초 |
| 폴링 간격 |
(60만 밀리초) 10분 |
| 승수 |
6 |
vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346
remote-system-ip 10.1.1.1
local-color private1
remote-color private1
mean-loss 1
mean-latency 110
mean-jitter 51
sla-class-index 0,2
IPV6 TX IPV6 RX
TOTAL AVERAGE AVERAGE TX DATA RX DATA DATA DATA
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS PKTS PKTS
----------------------------------------------------------------------------
0 596 7 110 50 0 0 0 0
1 596 5 111 50 0 1 0 0
2 597 13 111 53 0 0 0 0
3 594 4 111 53 0 0 0 0
4 596 5 110 50 0 0 0 0
5 594 12 111 50 0 2 0 0
평균 손실 = ((7+5+13+4+5+12)100)/ (596+596+597+594+596+594)
= 4600/3573
= 1.28 ~ 1%
평균 레이턴시 = (110+111+111+111+110+111)/6
= 110.66 ~ 110ms
평균 지터 = (50+50+53+53+50+50) / 6
= 3/6 = 51ms
일반적으로 는 이러한 값을 수정하여 계산 빈도를 높이는 것이 좋지만 큰 영향을 미칠 수 있습니다. 예를 들어 기본값 대신 폴링 간격이 다음과 같이 수정됩니다.
| 매개변수 |
기본값 |
| BFD hello 패킷 |
1초 |
| 폴링 간격 |
(6만 밀리초) 1분 |
| 승수 |
6 |
이 변경은 600이 아닌 1 x 60 = 버킷당 60개의 패킷을 기본값으로 사용함을 의미합니다. 평균 손실의 결과:
vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346
remote-system-ip 10.1.1.1
local-color private1
remote-color private1
mean-loss 3
mean-latency 112
mean-jitter 51
sla-class-index 0,2
IPV6 TX IPV6 RX
TOTAL AVERAGE AVERAGE TX DATA RX DATA DATA DATA
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS PKTS PKTS
----------------------------------------------------------------------------
0 59 1 113 53 0 0 0 0
1 60 3 111 52 0 1 0 0
2 59 1 111 51 0 1 0 0
3 60 3 111 50 0 1 0 0
4 60 2 115 50 0 0 0 0
5 59 1 111 50 0 2 0 0
평균 손실 = ((1+3+1+3+2+1)*100)/(59+60+59+60+60+59)
= (1100)/ 357
= 3.08 ~ 3%
이 시점에서 예를 들어 SLA 클래스가 최대 손실 3으로 설정된 경우 터널이 SLA 위반의 제한에 포함됩니다. 그러나 폴링 간격이 다음과 같이 수정된 경우:
| 매개변수 |
기본값 |
| BFD hello 패킷 |
1초 |
| 폴링 간격 |
(6,000밀리초) 1초 |
| 승수 |
6 |
이 변경은 600이 아니라 버킷당 1 x 6 = 6개의 패킷을 기본값으로 사용함을 의미합니다. 평균 손실의 결과:
vEdge1# show app-route stats
app-route statistics 10.100.100.2 10.200.200.4 ipsec 12366 12346
remote-system-ip 10.1.1.1
local-color private1
remote-color private1
mean-loss 17
mean-latency 110
mean-jitter 0
sla-class-index None
IPV6 TX IPV6 RX
TOTAL AVERAGE AVERAGE TX DATA RX DATA DATA DATA
INDEX PACKETS LOSS LATENCY JITTER PKTS PKTS PKTS PKTS
----------------------------------------------------------------------------
0 5 1 113 2 0 0 0 0
1 6 1 110 1 0 1 0 0
2 6 1 111 2 0 0 0 0
3 6 0 111 0 0 0 0 0
4 6 1 111 0 0 0 0 0
5 6 1 111 0 0 2 0 0
평균 손실 = ((5)100)/(5+6+6+6+6+6)
= (500)/29
= 17.24 ~ 17%
측정에 사용되는 패킷 수를 올바르게 확인하지 않고 폴링 간격을 줄일지 여부, 평균 손실에 영향을 미칠 수 있습니다. 풀 간격을 늘리지 않고 bfd hello-interval을 늘리는 경우에도 마찬가지입니다.
마지막 예에서는 계산을 수행하는 데 사용되는 패킷이 매우 적고 패킷이 하나만 손실되므로 평균 손실에 큰 영향을 줄 수 있습니다. 이러한 계산의 결과는 여러 번의 매우 빈번한 장애 조치가 있는 앱 인식 정책 동작입니다.
이 설명의 목적은, 반대로, 많은 상황에서 그러한 프로브가 수정되어야 하는 이러한 값의 수정을 피하기 위한 것이 아닙니다. 이는 네트워크 요구 사항에 따라 완전히 달라지지만, 이러한 hello 패킷을 줄일 수 있는 정도를 검토하는 것이 매우 중요합니다.
폴링 간격을 전역으로 수정하는 컨피그레이션 명령은 다음과 같습니다.
vEdge(config)# bfd app-route poll-interval 600000
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
02-Feb-2024 |
최초 릴리스 |
피드백