Cisco IOS®에서 TCP 최적화 기능 구성 XE SD-WAN cEdge Router
소개
이 문서에서는 2019년 8월 16.12 릴리스에 도입된 Cisco IOS® XE SD-WAN 라우터의 TCP(Transmission Control Protocol) 최적화 기능에 대해 설명합니다. 지원되는 항목은 사전 요구 사항, 문제 설명, 해결 방법, vEdge(Viptela OS)와 cEdge(XE SD-WAN) 간의 TCP 최적화 알고리즘 차이, 구성, 확인 및 관련 문서 목록입니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서의 정보는 Cisco IOS® XE SD-WAN을 기반으로 합니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
문제
두 SD-WAN 측 간의 WAN 링크에서 레이턴시가 높으면 애플리케이션 성능이 저하됩니다. 중요한 TCP 트래픽이 있으며, 이를 최적화해야 합니다.
솔루션
TCP 최적화 기능을 사용하면 두 SD-WAN 사이트 간의 중요한 TCP 흐름에 대한 평균 TCP 처리량을 개선할 수 있습니다.
cEdge 병목 대역폭 및 BBR(Round-trip)과 vEdge(CUBIC)에서 TCP 최적화의 개요와 차이점을 살펴보십시오
빠른 BBR 전파 시간 알고리즘은 XE SD-WAN 구현(cEdge)에서 사용됩니다.
Viptela OS(vEdge)에는 CUBIC이라는 다른 이전 알고리즘이 있습니다.
CUBIC은 주로 패킷 손실을 고려하며 다양한 클라이언트 운영 체제 전반에 걸쳐 광범위하게 구현됩니다. Windows, Linux, MacOS, Android에는 이미 CUBIC이 내장되어 있습니다. CUBIC 없이 TCP 스택을 실행하는 이전 클라이언트가 있는 경우 vEdge에서 TCP 최적화를 활성화하면 성능이 향상되는 경우도 있습니다. vEdge TCP CUBIC 최적화가 도움이 되는 예제 중 하나는 오래된 클라이언트 호스트 및 WAN 링크를 사용하는 잠수함에서 상당한 지연/드랍이 발생하는 경우입니다. vEdge 1000 및 vEdge 2000만 TCP CUBIC을 지원합니다.
BBR은 주로 왕복 시간과 레이턴시에 중점을 두고 있습니다. 패킷 손실이 아닙니다. 미국 서부에서 동부 해안까지 또는 심지어 공용 인터넷을 통해 유럽까지 패킷을 전송하는 경우, 대다수의 경우 패킷 손실이 표시되지 않습니다. 공용 인터넷은 패킷 손실 측면에서 너무 좋은 경우가 있습니다. 하지만 지연/지연 시간이 표시됩니다. 그리고 이 문제는 2016년 구글이 개발한 BBR로 해결된다.
간단히 말해, BBR은 네트워크를 모델링하고 각 승인(ACK)을 확인하고 최대 대역폭(BW) 및 최소 RTT(Round Trip Time)를 업데이트합니다. 그런 다음 제어 전송은 모델을 기반으로 합니다. 최대 BW 및 최소 RTT에 대한 프로브, 예상 BW에 가까운 속도 조절, BDP(Bandwidth-Delay-Product)에 가까운 기내 수신 유지 주요 목표는 작은 병목 현상 대기열로 높은 처리량을 보장하는 것입니다.
Mark Claypool의 이 슬라이드는 CUBIC이 작동하는 영역을 보여줍니다.
BBR은 Mark Claypool의 다음 슬라이드에 나와 있는 더 나은 환경에서 작동합니다.
BBR 알고리즘에 대한 자세한 내용을 읽고 싶다면, bbr-dev 메일링 리스트 홈 페이지 상단에 링크된 BBR에 대한 여러 간행물을 찾을 수 있습니다.
요약하면,
| 플랫폼 및 알고리즘 |
키 입력 매개 변수 | 사용 사례 |
| Edge(XE SD-WAN): BBR | RTT/레이턴시 | 두 SD-WAN 사이트 간의 중요한 TCP 트래픽 |
| vEdge(Viptela OS): 칸막이 | 패킷 손실 | TCP 최적화가 없는 이전 클라이언트 |
지원되는 XE SD-WAN 플랫폼
XE SD-WAN SW 릴리스 16.12.1d에서 다음 cEdge 플랫폼은 TCP 최적화 BBR을 지원합니다.
- ISR4331
- ISR4351
- CSR1000v, vCPU 8개 및 최소 8GB RAM
경고
- DRAM이 8GB RAM 미만인 모든 플랫폼은 현재 지원되지 않습니다.
- 4개 이하의 데이터 코어가 있는 모든 플랫폼은 현재 지원되지 않습니다.
- TCP 최적화는 MTU 2000을 지원하지 않습니다.
- 현재 - IPv6 트래픽을 지원하지 않습니다.
- 서드파티 BBR 서버에 대한 DIA 트래픽 최적화는 지원되지 않습니다. 양쪽에 cEdge SD-WAN 라우터가 있어야 합니다.
- 현재 데이터 센터 시나리오에서는 하나의 CN(Control Node)당 하나의 SN(Service Node)만 지원됩니다.
- 동일한 디바이스에서 보안(UTD 컨테이너) 및 TCP 최적화를 함께 사용하는 활용 사례는 16.12 릴리스에서 지원되지 않습니다. 17.2부터 통합 활용 사례가 지원됩니다. 작동 순서는 TCP Opt(TCP 옵트), Security(보안)입니다. 패킷은 TCP 최적화 컨테이너에 펀트된 다음 UTD 보안 컨테이너에 서비스 체인으로 연결됩니다(두 번째 펀트 없음). TCP 최적화는 처음 몇 바이트가 아닌 전체 흐름에 대해 수행됩니다. UTD가 삭제되면 전체 연결이 삭제됩니다.
이 표에는 릴리스별 주의 사항이 요약되어 있으며 지원되는 하드웨어 플랫폼에 대한 밑줄이 나와 있습니다.
| 시나리오 |
활용 사례 |
16.12.1 |
17.2.1 |
17.3.1 |
17.4.1 |
의견 |
| 지사-인터넷 |
DIA |
아니요 |
예 |
예 |
예 |
16.12.1에서 AppQoE FIA가 인터넷 인터페이스에서 활성화되지 않았습니다. |
| 사스 |
아니요 |
예 |
예 |
예 |
16.12.1에서 AppQoE FIA가 인터넷 인터페이스에서 활성화되지 않았습니다. |
|
| 지사-DC |
단일 엣지 라우터 |
아니요 |
아니요 |
아니요 |
예 |
여러 SN을 지원해야 함 |
| 다중 에지 라우터 |
아니요 |
아니요 |
아니요 |
예 |
흐름 대칭 또는 Appnav 흐름 동기화가 필요합니다. 16.12.1 테스트 안 함 |
|
| 여러 SN |
아니요 |
아니요 |
아니요 |
예 |
여러 SN IP를 허용하는 vManage 개선 사항 |
|
| 브랜치-투-브랜치 |
풀 메시 네트워크 (스포크 투 스포크) |
예 |
예 |
예 |
예 |
|
| 허브 앤 스포크 (스포크-허브-스포크) |
아니요 |
예 |
예 |
예 |
||
| BBR 지원 |
BBR을 사용하는 TCP Opt |
부분 | 부분 |
전체 |
전체 |
|
| 플랫폼 |
지원되는 플랫폼 |
4300 및 CSR만 |
ISR1100 제외 |
모두 |
모두 |
구성
TCP 최적화를 위해 SN 및 CN의 개념이 사용됩니다.
- SN은 TCP 흐름의 실제 최적화를 담당하는 데몬입니다.
- CN은 AppNav Controller라고 하며 트래픽 선택 및 SN과의 전송을 담당합니다.
SN과 CN은 동일한 라우터에서 실행되거나 서로 다른 노드로 분리될 수 있습니다.
두 가지 주요 활용 사례가 있습니다.
- 동일한 ISR4k 라우터에서 실행되는 SN 및 CN의 지사 활용 사례.
- CN이 ASR1k에서 실행되고 SN이 별도의 CSR1000v 가상 라우터에서 실행되는 데이터 센터 활용 사례.
이 섹션에서는 두 가지 사용 사례에 대해 설명합니다.
활용 사례 1. 브랜치에서 TCP 최적화 구성(모두 하나의 cEdge)
이 그림에서는 브랜치의 단일 독립형 옵션에 대한 전반적인 내부 아키텍처를 보여줍니다.
1단계. TCP 최적화를 구성하려면 vManage에서 TCP 최적화를 위한 기능 템플릿을 생성해야 합니다. 그림과 같이 Configuration > Templates > Feature Templates > Other Templates > AppQoE로 이동합니다.
2단계. Additional Templates(추가 템플릿)에서 적절한 디바이스 템플릿에 AppQoE 기능 템플릿을 추가합니다.
다음은 템플릿 컨피그레이션의 CLI 미리 보기입니다.
service-insertion service-node-group appqoe SNG-APPQOE
service-node 192.3.3.2
!
service-insertion appnav-controller-group appqoe ACG-APPQOE
appnav-controller 192.3.3.1
!
service-insertion service-context appqoe/1
appnav-controller-group ACG-APPQOE
service-node-group SNG-APPQOE
vrf global
enable
! !
interface VirtualPortGroup2
ip address 192.3.3.1 255.255.255.0
no mop enabled
no mop sysid
service-insertion appqoe
!
3단계. 최적화를 위해 관심 있는 TCP 트래픽을 정의하여 중앙 집중식 데이터 정책을 생성합니다.
예를 들어, 이 데이터 정책은 소스 및 대상 주소를 포함하는 IP 접두사 10.0.0.0/8과 일치하며, 이에 대한 TCP 최적화를 활성화합니다.
vSmart 정책의 CLI 미리 보기는 다음과 같습니다.
policy
data-policy _vpn-list-vpn1_TCPOpt_1758410684
vpn-list vpn-list-vpn1
sequence 1
match
destination-ip 10.0.0.0/8
!
action accept
tcp-optimization
!
!
default-action accept
!
lists
site-list TCPOpt-sites
site-id 211
site-id 212
!
vpn-list vpn-list-vpn1
vpn 1
!
!
!
apply-policy
site-list TCPOpt-sites
data-policy _vpn-list-vpn1_TCPOpt_1758410684 all
!
!
활용 사례 2. 외부 SN을 사용하여 데이터 센터에서 TCP 최적화 구성
브랜치 활용 사례의 주요 차이점은 SN과 CN의 물리적 분리입니다. 올인원 브랜치(all-in-one branch) 활용 사례에서는 가상 포트 그룹 인터페이스(Virtual Port Group Interface)를 사용하여 동일한 라우터 내에서 연결이 이루어집니다. 데이터 센터 활용 사례에서는 CN으로 작동하는 ASR1k와 SN으로 실행되는 외부 CSR1k 간에 AppNav GRE 캡슐화 터널이 있습니다. CN과 외부 SN 간에 전용 링크나 교차 연결이 필요 없으며 간단한 IP 연결만으로도 충분합니다.
SN당 하나의 AppNav(GRE) 터널이 있습니다. 여러 SN이 지원되는 향후 사용을 위해 CN과 SN 간의 네트워크에 /28 서브넷을 사용하는 것이 좋습니다.
SN으로 작동하는 CSR1k에는 두 개의 NIC가 권장됩니다. vManage에서 SN을 구성/관리해야 하는 경우 SD-WAN 컨트롤러용 두 번째 NIC가 필요합니다. SN을 수동으로 구성/관리하려는 경우 두 번째 NIC는 선택 사항입니다.
이 그림에서는 CN으로 실행되는 데이터 센터 ASR1k와 서비스 노드 SN으로 실행되는 CSR1kv를 보여줍니다.
ASR1k 및 외부 CSR1k의 데이터 센터 활용 사례에 대한 토폴로지는 다음과 같습니다.
이 AppQoE 기능 템플릿은 컨트롤러로 구성된 ASR1k를 표시합니다.
외부 서비스 노드로 구성된 CSR1k는 다음과 같습니다.
장애 조치 사례
CSR1k가 SN으로 작동하는 데이터 센터 활용 사례의 장애 조치(외부 CSR1k 장애 시):
- SN의 TCP 세션이 종료되었으므로 이미 있는 TCP 세션이 손실됩니다.
- 새 TCP 세션이 최종 대상으로 전송되지만 TCP 트래픽은 최적화되지 않습니다(우회).
- SN 장애 시 흥미로운 트래픽에 대한 블랙홀이 없습니다.
장애 조치 감지는 초당 1비트인 AppNav 하트비트를 기반으로 합니다. 3~4개의 오류가 발생하면 터널이 down으로 선언됩니다.
브랜치 활용 사례의 장애 조치는 유사합니다. SN 장애가 발생하면 트래픽이 최적화되지 않은 상태로 목적지로 직접 전송됩니다.
다음을 확인합니다.
구성이 올바르게 작동하는지 확인하려면 이 섹션을 활용하십시오.
이 CLI 명령을 사용하여 CLI에서 TCP 최적화를 확인하고 최적화된 흐름의 요약을 확인합니다.
BR11-CSR1k#show plat hardware qfp active feature sdwan datapath appqoe summary TCPOPT summary ---------------- optimized flows : 2 expired flows : 6033 matched flows : 0 divert pkts : 0 bypass pkts : 0 drop pkts : 0 inject pkts : 20959382 error pkts : 88
BR11-CSR1k#
이 출력은 최적화된 흐름에 대한 자세한 정보를 제공합니다.
BR11-CSR1k#show platform hardware qfp active flow fos-to-print all
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
GLOBAL CFT ~ Max Flows:2000000 Buckets Num:4000000
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Filtering parameters:
IP1 : ANY
Port1 : ANY
IP2 : ANY
Port2 : ANY
Vrf id : ANY
Application: ANY
TC id: ANY
DST Interface id: ANY
L3 protocol : IPV4/IPV6
L4 protocol : TCP/UDP/ICMP/ICMPV6
Flow type : ANY
Output parameters:
Print CFT internal data ? No
Only print summary ? No
Asymmetric : ANY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
keyID: SrcIP SrcPort DstIP DstPort L3-Protocol L4-Protocol vrfID
==================================================================
key #0: 192.168.25.254 26113 192.168.25.11 22 IPv4 TCP 3
key #1: 192.168.25.11 22 192.168.25.254 26113 IPv4 TCP 3
==================================================================
key #0: 192.168.25.254 26173 192.168.25.11 22 IPv4 TCP 3
key #1: 192.168.25.11 22 192.168.25.254 26173 IPv4 TCP 3
==================================================================
key #0: 10.212.1.10 52255 10.211.1.10 8089 IPv4 TCP 2
key #1: 10.211.1.10 8089 10.212.1.10 52255 IPv4 TCP 2
Data for FO with id: 2
-------------------------
appqoe: flow action DIVERT, svc_idx 0, divert pkt_cnt 1, bypass pkt_cnt 0, drop pkt_cnt 0, inject pkt_cnt 1, error pkt_cnt 0, ingress_intf Tunnel2, egress_intf GigabitEthernet3
==================================================================
key #0: 10.212.1.10 52254 10.211.1.10 8089 IPv4 TCP 2
key #1: 10.211.1.10 8089 10.212.1.10 52254 IPv4 TCP 2
Data for FO with id: 2
-------------------------
appqoe: flow action DIVERT, svc_idx 0, divert pkt_cnt 158, bypass pkt_cnt 0, drop pkt_cnt 0, inject pkt_cnt 243, error pkt_cnt 0, ingress_intf Tunnel2, egress_intf GigabitEthernet3
==================================================================
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Number of flows that passed filter: 4
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
FLOWS DUMP DONE.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
BR11-CSR1k#
문제 해결
다음 CLI는 특정 TCP 흐름의 문제를 식별하는 데 도움이 됩니다.
모든 예는 ISR4431에서 실행되는 IOS XE SD-WAN 17.2.1 이미지에서 가져왔습니다.
- VRF ID(VRF 이름과 같지 않음)를 확인합니다. 이 경우 아래 출력에서 볼 수 있듯이 해당 서비스 VPN(VRF) 1에는 VRF ID 2가 있습니다.
AppQoE_R2#show vrf detail
VRF 1 (VRF Id = 2); default RD 1:1; default VPNID <not set>
New CLI format, supports multiple address-families
Flags: 0x180C
Interfaces:
Gi0/0/3
…
- 서비스 vpn에서 클라이언트에 적절한 flow-id를 확인합니다. 여기서는 TCP 포트 445를 통한 SMB 공유를 사용하는 두 Windows 클라이언트 간의 4가지 플로우를 살펴봅니다.
AppQoE_R2#show sdwan appqoe flow vpn-id 2 client-ip 192.168.200.50
Optimized Flows
---------------
T:TCP, S:SSL, U:UTD
Flow ID VPN Source IP:Port Destination IP:Port Service
15731593842 2 192.168.200.50:49741 192.168.100.50:445 T
17364128987 2 192.168.200.50:49742 192.168.100.50:445 T
25184244867 2 192.168.200.50:49743 192.168.100.50:445 T
28305760200 2 192.168.200.50:49744 192.168.100.50:445 T
AppQoE_R2#
- 적절한 플로우에 대해서는 TCP Opt 통계를 참조하십시오.
AppQoE_R2#show sdwan appqoe flow flow-id 15731593842
VPN: 2 APP: 0 [Client 192.168.200.50:49741 - Server 192.168.100.50:445]
TCP stats
---------
Client Bytes Received : 14114
Client Bytes Sent : 23342
Server Bytes Received : 23342
Server Bytes Sent : 14114
TCP Client Rx Pause : 0x0
TCP Server Rx Pause : 0x0
TCP Client Tx Pause : 0x0
TCP Server Tx Pause : 0x0
Client Flow Pause State : 0x0
Server Flow Pause State : 0x0
TCP Flow Bytes Consumed : 0
TCP Client Close Done : 0x0
TCP Server Close Done : 0x0
TCP Client FIN Rcvd : 0x0
TCP Server FIN Rcvd : 0x0
TCP Client RST Rcvd : 0x0
TCP Server RST Rcvd : 0x0
TCP FIN/RST Sent : 0x0
Flow Cleanup State : 0x0
TCP Flow Events
1. time:2196.550604 :: Event:TCPPROXY_EVT_FLOW_CREATED
2. time:2196.550655 :: Event:TCPPROXY_EVT_SYNCACHE_ADDED
3. time:2196.552366 :: Event:TCPPROXY_EVT_ACCEPT_DONE
4. time:2196.552665 :: Event:TCPPROXY_EVT_CONNECT_START
5. time:2196.554325 :: Event:TCPPROXY_EVT_CONNECT_DONE
6. time:2196.554370 :: Event:TCPPROXY_EVT_DATA_ENABLED_SUCCESS
AppQoE_R2#
- 또한 4개의 최적화된 흐름을 보여주는 일반 TCP Opt 통계를 참조하십시오.
AppQoE_R2#show tcpproxy statistics
==========================================================
TCP Proxy Statistics
==========================================================
Total Connections : 6
Max Concurrent Connections : 4
Flow Entries Created : 6
Flow Entries Deleted : 2
Current Flow Entries : 4
Current Connections : 4
Connections In Progress : 0
Failed Connections : 0
SYNCACHE Added : 6
SYNCACHE Not Added:NAT entry null : 0
SYNCACHE Not Added:Mrkd for Cleanup : 0
SYN purge enqueued : 0
SYN purge enqueue failed : 0
Other cleanup enqueued : 0
Other cleanup enqueue failed : 0
Stack Cleanup enqueued : 0
Stack Cleanup enqueue failed : 0
Proxy Cleanup enqueued : 2
Proxy Cleanup enqueue failed : 0
Cleanup Req watcher called : 135003
Total Flow Entries pending cleanup : 0
Total Cleanup done : 2
Num stack cb with null ctx : 0
Vpath Cleanup from nmrx-thread : 0
Vpath Cleanup from ev-thread : 2
Failed Conn already accepted conn : 0
SSL Init Failure : 0
Max Queue Length Work : 1
Current Queue Length Work : 0
Max Queue Length ISM : 0
Current Queue Length ISM : 0
Max Queue Length SC : 0
Current Queue Length SC : 0
Total Tx Enq Ign due to Conn Close : 0
Current Rx epoll : 8
Current Tx epoll : 0
Paused by TCP Tx Full : 0
Resumed by TCP Tx below threshold : 0
Paused by TCP Buffer Consumed : 0
Resumed by TCP Buffer Released : 0
SSL Pause Done : 0
SSL Resume Done : 0
SNORT Pause Done : 0
SNORT Resume Done : 0
EV SSL Pause Process : 0
EV SNORT Pause Process : 0
EV SSL/SNORT Resume Process : 0
Socket Pause Done : 0
Socket Resume Done : 0
SSL Pause Called : 0
SSL Resume Called : 0
Async Events Sent : 0
Async Events Processed : 0
Tx Async Events Sent : 369
Tx Async Events Recvd : 369
Tx Async Events Processed : 369
Failed Send : 0
TCP SSL Reset Initiated : 0
TCP SNORT Reset Initiated : 0
TCP FIN Received from clnt/svr : 0
TCP Reset Received from clnt/svr : 2
SSL FIN Received -> SC : 0
SSL Reset Received -> SC : 0
SC FIN Received -> SSL : 0
SC Reset Received -> SSL : 0
SSL FIN Received -> TCP : 0
SSL Reset Received -> TCP : 0
TCP FIN Processed : 0
TCP FIN Ignored FD Already Closed : 0
TCP Reset Processed : 4
SVC Reset Processed : 0
Flow Cleaned with Client Data : 0
Flow Cleaned with Server Data : 0
Buffers dropped in Tx socket close : 0
TCP 4k Allocated Buffers : 369
TCP 16k Allocated Buffers : 0
TCP 32k Allocated Buffers : 0
TCP 128k Allocated Buffers : 0
TCP Freed Buffers : 369
SSL Allocated Buffers : 0
SSL Freed Buffers : 0
TCP Received Buffers : 365
TCP to SSL Enqueued Buffers : 0
SSL to SVC Enqueued Buffers : 0
SVC to SSL Enqueued Buffers : 0
SSL to TCP Enqueued Buffers : 0
TCP Buffers Sent : 365
TCP Failed Buffers Allocations : 0
TCP Failed 16k Buffers Allocations : 0
TCP Failed 32k Buffers Allocations : 0
TCP Failed 128k Buffers Allocations : 0
SSL Failed Buffers Allocations : 0
Rx Sock Bytes Read < 512 : 335
Rx Sock Bytes Read < 1024 : 25
Rx Sock Bytes Read < 2048 : 5
Rx Sock Bytes Read < 4096 : 0
SSL Server Init : 0
Flows Dropped-Snort Gbl Health Yellow : 0
Flows Dropped-Snort Inst Health Yellow : 0
Flows Dropped-WCAPI Channel Health Yellow : 0
Total WCAPI snd flow create svc chain failed : 0
Total WCAPI send data svc chain failed : 0
Total WCAPI send close svc chain failed : 0
Total Tx Enqueue Failed : 0
Total Cleanup Flow Msg Add to wk_q Failed : 0
Total Cleanup Flow Msg Added to wk_q : 0
Total Cleanup Flow Msg Rcvd in wk_q : 0
Total Cleanup Flow Ignored, Already Done : 0
Total Cleanup SSL Msg Add to wk_q Failed : 0
Total UHI mmap : 24012
Total UHI munmap : 389
Total Enable Rx Enqueued : 0
Total Enable Rx Called : 0
Total Enable Rx Process Done : 0
Total Enable Rx Enqueue Failed : 0
Total Enable Rx Process Failed : 0
Total Enable Rx socket on Client Stack Close : 0
Total Enable Rx socket on Server Stack Close : 0
AppQoE_R2#
17.2부터 다른 AppQoE/UTD 기능과 함께 TCPOpt 사용
16.12에서 TCPOpt의 주요 활용 사례는 Branch-to-Branch입니다. 16.12에서는 TCP 프록시로 리디렉션하고 UTD 컨테이너로 리디렉션하는 것이 별개이므로 16.12에서는 TCP 옵트가 보안과 함께 작동하지 않습니다
17.2에서는 중앙 집중식 정책 경로가 구현되어 TCP Opt and Security의 필요성을 감지합니다.
해제된 패킷은 서비스 플레인(펀트)으로 한 번만 리디렉션됩니다.
17.2부터 다양한 플로우 옵션을 사용할 수 있습니다.
- TCP 옵트만
- UTD만
- TCP Opt(TCP 옵트) -> UTD
- TCP Opt(TCP 옵트) -> SSL Proxy(SSL 프록시) -> UTD
관련 정보
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
29-Jan-2020 |
최초 릴리스 |
피드백