SD-WAN Control Traffic Overhead 사용 설명서

소개

이 문서에서는 SD-WAN 오버레이 구축에서 제어 트래픽 오버헤드를 계산하는 방법에 대해 설명합니다. 다음 문서 지침은 20.10.x 이하 및 IOS-XE SD-WAN 17.10.x 이하(20.10.x /17.10.x부터 Cisco는 데이터 수집을 위해 푸시 모델을 구현함)의 비디오 코드에 사용해야 합니다. 

문제

설계 단계에서 사용자로부터 흔히 받는 질문은 'SD-WAN 솔루션이 브랜치 회로에 얼마나 많은 오버헤드를 발생시키는가'입니다. 답은 몇 가지 변수에 따라 다르다는 것이다.

솔루션

이 사례 연구를 통해 답을 찾을 수 있습니다. 브랜치 역할 아웃 시점의 사용자 대부분은 인터넷 회로를 프로비저닝할 수 있거나 프로비저닝할 수 없습니다. 고객이 제품을 보유하고 있는 경우 일반적으로 그림 1과 같은 형태로 표시됩니다.

그림 1. 인터넷 및 MPLS(Multiprotocol Label Switching) 회로가 모두 포함된 SD-WAN 브랜치.

항상 그렇지는 않을 수 있습니다. 일부 사용자는 대부분 최소한의 변경과 새로운 회로 도입으로 SD-WAN으로 마이그레이션하는 것을 선호합니다. 이는 인터넷 회로가 없는 경우 그림 2와 같이 향후 단계에서 계획할 수 있는 회로를 추가하는 것입니다.

그림 2. MPLS 회로만 있는 SD-WAN 브랜치.

스테이지를 설정하기 위해 100개의 브랜치에 2개의 헤드 엔드가 있고 브랜치와 헤드 엔드 사이에 풀 메시 토폴로지가 제안되어 있는 경우, 사용자는 엄격한 QOS 표준을 사용하며 음성의 경우 LLQ(Low Latency Queue)에 20% 할당됩니다.

SD-WAN으로 마이그레이션하는 경우 이러한 지사에 대해 고려해야 할 오버헤드는 무엇일까요? 좀 더 자세히 살펴보겠습니다.

참고: 이러한 계산은 최대 요구 사항을 포함하여 정상적인 운영 요구 사항에서 고려되어야 합니다. 그러나 모든 가능한 시나리오를 고려하지는 마십시오.

이 수치는 1vManage, 1vBond, 1vSmart, 255BFD 세션으로 수행한 랩 테스트에서 얻은 것입니다. 

표 1. 세션당 대역폭.

1 BFD 세션/네이버	2 x 132 x 8 = 2.2Kbps 2: 잠시 후 최대 2개의 BFD 패킷을 보내고 받습니다. 132: BFD 패킷 크기(B)
vSmart에 대한 DTLS	최대 80Kbps*
vManage 데이터 폴링	최대 1.2Mbps**
DPI 사용	200Kbps

Kbps = 초당 킬로비트

B = 바이트

Mbps = 초당 메가비트

* 정책 및 경로에 따라 다릅니다. 이 계산은 초기 교환 시에만 필요하며 안정적 상태는 약 200B로 훨씬 낮습니다.

** 원격 명령 또는 관리 기술 실행과 같은 사용자 트리거 작업은 고려하지 않습니다. 1.2Mbps가 최고치에 달합니다.

이제 200개의 BFD 세션인 전체 메시 사이트 100개를 모두 고려할 경우(지점당 라우터 2개, 색상 제한이 있는 라우터당 TLOC 2개) 앞서 언급한 표는 .x가 됩니다.

표 2. vSmart 및 vManage 폴링을 포함하는 200BFD 세션[100개 사이트]에 대한 Queue0 대역폭.

200 BFD 세션	440Kbps [2.2 x 200]
vSmart에 대한 DTLS	최대 80Kbps*
vManage 폴링	최대 1.2Mbps**
Total	1.72Mbps

* 정책 및 경로에 따라 다릅니다. 이 계산은 초기 교환 시에만 필요하며 안정적 상태는 약 200B로 훨씬 낮습니다.

** 원격 명령 또는 관리 기술 실행과 같은 사용자 트리거 작업은 고려하지 않습니다. 1.2Mbps가 최고치에 달합니다.

이러한 모든 트래픽이 Queue0 LLQ에 도달한다는 점을 염두에 두십시오. 이 제어 트래픽에는 항상 일류 시민 우선 순위가 지정됩니다. 즉, 이 트래픽은 LLQ에서 폴리싱할 마지막 트래픽입니다.

QoS 설계 시 음성 트래픽이 LLQ(Queue0)에 배치되는 경우가 많으며, SD-WAN용 Tloc을 사용하는 풀 메시 100개 브랜치에는 1.72Mbps가 필요합니다. 저대역폭 회로 브랜치를 사용하는 LLQ에서 폴리싱/드롭을 확인할 수 있습니다.

이제 Queue0에 기여하지는 않지만 전체 용량 요구 사항을 구성하는 Tloc 확장 오버헤드를 고려할 때

표 3. Tloc 확장을 통해 트래픽을 제어하는 방법을 고려한 후 전반적인 대역폭 요구 사항.

Queue0 요구 사항	1.72Mbps
Tloc 확장 [Encrypted] 비 Queue0에 대한 200 BFD 세션	520Kbps [440 + 80*]                [BFD + DTLS]
Total	2.24Mbps

* 정책 및 경로에 따라 다릅니다. 이 계산은 초기 교환 시에만 필요하며 안정적 상태는 약 200B로 훨씬 낮습니다.

색상 제한이 있는 TLOC 확장이 포함된 전체 100개 브랜치에 대해 최대 2.5Mbps의 용량 계획을 고려할 때, 다시 실시간 명령을 수집할 수 있습니다. 이전에 언급된 계산에서는 admin tech가 고려되지 않으며 정상적인 운영 상황에서는 이를 고려합니다. 

시나리오 1.

Queue0에 대한 제어 트래픽 요구 사항을 수용해야 하고 브랜치에 10Mbps 회로만 있는 경우, 음성 및 제어 트래픽 모두에 대해 20% LLQ의 QoS 정책만으로 SD-WAN 오버레이에 온보딩해야 합니다. vManage에서 최대 폴링 시점에 성능이 저하된 환경을 확인할 수 있습니다. 이 경우 허브 및 스포크 솔루션은 여전히 약 1.28Mbps를 소비하므로 도움이 되지 않을 수 있습니다.

표 4. 허브 및 스포크 큐0 대역폭 요구 사항.

헤드엔드에 대한 4BFD 세션	8.8Kbps [2.2 x 4]
vSmart에 대한 DTLS	최대 80Kbps*
vManage 폴링	최대 1.2Mbps**
Total	1.28Mbps

* 정책 및 경로에 따라 다릅니다. 이 계산은 초기 교환 시에만 필요하며 안정적 상태는 약 200B로 훨씬 낮습니다.

** 원격 명령 또는 관리 기술 실행과 같은 사용자 트리거 작업은 고려하지 않습니다. 1.2Mbps가 최고치에 달합니다.

시나리오 2.

~2Mbps 추가 대역폭 요구 사항을 수용하기 위해 QoS 정책을 재설계하기로 결정한 경우 QoS LLQ를 20%에서 40%로 늘릴 수 있습니다. 그러나 이는 더 큰 대역폭 회로에 부정적인 영향을 미칩니다.

그림 3. QoS에 대한 일반적인 20% Queue0 할당.

10Mbps 회로의 경우 Queue0은 20%에서 2Mbps를 얻습니다. 이것이 회사의 일반적인 QoS 표준이라고 가정합니다. SD-WAN 채택을 위해서는 풀 메시(full-mesh)가 필요하므로, 사용자가 QoS 할당을 그림과 같이 40%로 늘리기로 결정하면 Queue0에 대한 2Mbps 오버헤드를 수용하기 위해 Queue0 할당을 늘려야 합니다.

한 회선에 대한 Queue0의 양이 너무 많으면 다른 대기열에 대한 리소스가 제거됩니다. 그러나 그 차이는 더 큰 대역폭 회로에 더 많이 있습니다.

제어 트래픽에 대한 고정 할당과 음성 트래픽에 대한 또 다른 대기열을 가지려면 LLQ가 있는 것이 이상적이지만 둘 다 우선순위 대기열이 필요합니다. Cisco 라우터는 스플릿 LLQ라는 두 가지 수준의 우선순위 큐를 지원합니다. 이는 최소 요구 사항이 충족되면 최소 대역폭 요구 사항 문제를 해결하지 못합니다. 스플릿 LLQ가 기본 QoS 설계가 됩니다

LLQ 분할:

 

 

Split LLQ를 사용하면 필요한 대역폭을 Queue에 추가하고 우선순위 큐를 계속 유지할 수 있습니다.

스플릿 LLQ는 현재 추가 CLI에서만 지원됩니다. 스플릿 LLQ에서는 두 가지 레벨의 우선순위 대기열이 포함될 수 있으며, 샘플 컨피그레이션은 여기에 표시된 것과 같습니다. 컨피그레이션은 변수를 사용하여 사용자 정의할 수 있습니다. 이 코드 조각은 제어 트래픽에 4Mbps를 예약하고 대기열의 나머지 부분을 할당된 대역폭 백분율로 예약합니다.

분할 대기열의 예:

policy-map GBL_edges_qosmap_rev1

class Queue0

  priority level 1

  police cir 2000000 bc 250000

   conform-action transmit

   exceed-action drop

  !

!

class Queue1

  bandwidth remaining ratio 16

  random-detect precedence-based

!

class class-default

  bandwidth remaining ratio 8

  random-detect precedence-based

!

class Queue3

  bandwidth remaining ratio 16

  random-detect precedence-based

!

class Queue4

  bandwidth remaining ratio 32

  random-detect precedence-based

!

class Queue5

  bandwidth remaining ratio 8

  random-detect precedence-based

!

class Queue6

  priority level 2

  police rate percent 20

  !

!

!

참고: 이러한 컨피그레이션은 17.3.x 및 20.3.x의 컨트롤러를 실행하는 ISR/ASR에서 테스트됩니다.

간접비 계산을 위한 일반적인 지침

이 표를 통해 SD-WAN 제어 오버헤드의 회로당 용량을 계획할 수 있습니다.

표 5. 일반 가이드라인 계산(색상 제한이 있는 것으로 가정)

오버헤드 계산의 예

여기에 표시된 것과 유사한 사이트 100개에 대한 MPLS 회로의 오버헤드를 계산해야 하는 경우 각 색상의 제한이 활성화된 것으로 가정할 수 있습니다.

사이트 수 = 100

WAN Tloc = 2에서 사이트에 대한 BFD 수

표 6. 100개 사이트 구축에 대한 MPLS 오버헤드를 계산합니다.

프로토콜/세션	필요한 대역폭
큐0	2.2 x [100 x 2] + 80 + 1200 BFD 크기 x [ 사이트 수 x WAN Tloc에서 사이트로 연결되는 BFD 수] + DTLS +vManage = 1.72Mbps
TLOC를 통한 트래픽 제어	2.2 x [100 x 2] + 80 BFD 크기 x [사이트 x TLOC/라우터당] + DTLS = 520Kbps
Total	1,720Kbps + 520Kbps = 2.24Mbps

Queue0 오버헤드는 1.72Mbps이고 총 오버헤드는 2.24Mbps입니다.