تكوين ميزة تحسين TCP على Cisco IOS&Reg؛ موجهات XE SD-WAN CEdge
المحتويات
المقدمة
يصف هذا المستند ميزة تحسين بروتوكول التحكم في الإرسال (TCP) على موجهات Cisco IOS® XE SD-WAN، والتي تم تقديمها في الإصدار 16.12 في أغسطس 2019. الموضوعات المشمولة هي المتطلبات الأساسية ووصف المشكلة والحل والاختلافات في خوارزميات تحسين بروتوكول TCP بين نظام التشغيل Viptela OS (vEdge) و XE SD-WAN (cEdge) والتكوين والتحقق وقائمة المستندات ذات الصلة.
المتطلبات الأساسية
المتطلبات
لا توجد متطلبات خاصة لهذا المستند.
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى برنامج Cisco IOS® XE SD-WAN.
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
المشكلة
يتسبب زمن الوصول العالي على إرتباط شبكة WAN بين جهتي SD-WAN في أداء تطبيق سيئ. لديك حركة مرور TCP بالغة الأهمية، والتي يجب تحسينها.
الحل
عند إستخدام ميزة تحسين TCP، يمكنك تحسين متوسط خرج TCP لتدفقات TCP الهامة بين موقعين SD-WAN.
ألق نظرة على النظرة العامة والاختلافات بين تحسين بروتوكول TCP على النطاق الترددي لازدحام الخوادم cEdge والرحلة المستديرة (BBR) وتقنية vEdge (CUBE)
يتم إستخدام خوارزمية وقت النشر السريع ل BBR في تنفيذ XE SD-WAN (على cEdge).
إن Viptela OS (vEdge) به خوارزمية مختلفة، قديمة، تسمى CUBE.
ويأخذ المكعب بشكل رئيسي فقدان حزم البيانات في الاعتبار ويتم تنفيذه على نطاق واسع عبر أنظمة تشغيل العملاء المختلفة. فأنظمة التشغيل Windows و Linux و MacOS و Android تحتوي بالفعل على وحدات مكعبة مدمجة. في بعض الحالات، حيث يكون لديك عملاء قدامى يعملون على تشغيل مكدس TCP بدون المكعب، يؤدي تمكين تحسين TCP على vEdge إلى إجراء تحسينات. يتمثل أحد الأمثلة التي إستفاد منها تحسين المكعب عبر بروتوكول TCP vEdge في إستخدام الغواصات التي تستخدم أجهزة مضيفة قديمة للعملاء ووصلات شبكات الاتصال واسعة النطاق تتعرض لتأخيرات/حالات سقوط كبيرة. لاحظ أن vEdge 1000 و vEdge 2000 فقط يدعمان TCP Cube.
ويركز تقرير ما بعد التصرف بصفة رئيسية على وقت الذهاب والعودة وزمن الوصول. غير موجود على فقدان الحزمة. إذا قمت بإرسال حزم من الولايات المتحدة الغربية إلى الساحل الشرقي أو حتى إلى أوروبا عبر الإنترنت العامة، في معظم الحالات لا ترى أي فقدان للحزمة. في بعض الأحيان قد تكون شبكة الإنترنت العامة جيدة للغاية من حيث فقدان الحزم. ولكن، ما ترونه هو تأخير/زمن وصول. وهذه المشكلة يعالجها بي آر، التي طورتها جوجل في عام 2016.
وباختصار، تقوم قاعدة بيانات إعادة التوجيه (BBR) بوضع نماذج للشبكة والنظر في كل إقرار (ACK) وتحديث الحد الأقصى للنطاق الترددي (BW) والحد الأدنى لوقت الذهاب والعودة (RTT). ثم يستند إرسال عنصر التحكم إلى النموذج: البحث عن الحد الأقصى من وزن bw و الحد الأدنى ل RTT، وبدل السرعة قرب تقدير وزن الجسم، وابق التدفق قرب منتج تأخير عرض النطاق الترددي (BDP). والهدف الرئيسي هو ضمان إنتاجية عالية مع قائمة انتظار صغيرة ذات إعاقة.
هذه الشريحة من مارك كلايبول تظهر المنطقة، حيث يعمل المكعب:
يعمل بي آر في مكان أفضل، وهو ما يظهر في هذه الشريحة أيضا من مارك كلايبول:
إذا كنت ترغب في قراءة المزيد حول خوارزمية BBR، يمكنك العثور على العديد من المنشورات حول BBR المرتبطة في أعلى الصفحة الرئيسية لقائمة BBR-dev البريدية هنا.
باختصار:
| النظام الأساسي والخوارزمية |
معلمة إدخال المفتاح | حالة الاستخدام |
| Edge (XE SD-WAN): بي آر | زمن وصول/زمن وصول RTT | حركة مرور بيانات TCP الحرجة بين موقعي SD-WAN |
| vEdge (نظام التشغيل Viptela): CUBICP | فقدان الحزمة | العملاء القدامى بدون أي تحسين TCP |
الأنظمة الأساسية المدعومة لشبكة WAN XE SD
في الإصدار 16. 12. 1d من برنامج XE SD-WAN SW، تدعم أنظمة Edge الأساسية هذه الإعدادات من TCP:
- ISR4331
- ISR4351
- CSR1000v مع 8 vCPU والحد الأدنى. ذاكرة وصول عشوائي (RAM) سعة 8 جيجابايت
التحذيرات
- لا يتم حاليا دعم جميع الأنظمة الأساسية التي تحتوي على ذاكرة وصول عشوائي (RAM) سعة أقل من 8 جيجابايت من DRAM.
- لا يتم حاليا دعم جميع الأنظمة الأساسية التي تحتوي على 4 مراكز بيانات أو أقل.
- لا يدعم تحسين TCP MTU 2000.
- حاليا - لا يوجد دعم لحركة مرور IPv6.
- لا يتم دعم تحسين حركة مرور DIA إلى خادم BBR من جهة خارجية. يجب أن يكون لديك موجهات cEdge SD-WAN على كلا الجانبين.
- في سيناريو مركز البيانات حاليا، يتم دعم عقدة خدمة (SN) واحدة فقط لكل عقدة تحكم (CN) واحدة.
- حالة الاستخدام المدمجة مع الأمان (حاوية UTD) وتحسين TCP على نفس الجهاز غير مدعومة على الإصدار 16.12. يتم دعم حالة الاستخدام المشتركة بدءا من 17.2. ترتيب العملية هو إختيار TCP أولا، ثم الأمان. سيتم إختبار الحزمة على حاوية تحسين TCP ثم يتم تقييد الخدمة (بدون علامة ترقيم ثانية) إلى حاوية أمان UTD. يتم تحسين TCP للتدفق الكامل، وليس للعدد الأول من وحدات البايت. إذا انخفض UTD، يتم إسقاط الاتصال الكامل.
يلخص هذا طاولة تحذير لكل إطلاق ويبرز منصة جهاز مدعوم:
| السيناريوهات |
حالات الاستخدام |
16.12.1 |
17.2.1 |
17.3.1 |
17.4.1 |
التعليقات |
| الاتصال من فرع إلى إنترنت |
دي أي |
لا |
نعم |
نعم |
نعم |
في 16.12.1 لم يتم تمكين FIA AppQoE على واجهة الإنترنت |
| ساس |
لا |
نعم |
نعم |
نعم |
في 16.12.1 لم يتم تمكين FIA AppQoE على واجهة الإنترنت |
|
| من الفرع إلى التيار المستمر |
موجه أحادي الحافة |
لا |
لا |
لا |
نعم |
الحاجة إلى دعم SN متعدد |
| الموجهات الطرفية المتعددة |
لا |
لا |
لا |
نعم |
يحتاج إلى تناظر التدفق أو مزامنة تدفق AppNav. 16.12.1 لم يتم إختباره مع |
|
| SNs متعددة |
لا |
لا |
لا |
نعم |
تحسين vManage لقبول العديد من بروتوكولات IP الخاصة بشبكة SN |
|
| من فرع إلى فرع |
شبكة كاملة (تحدث إلى) |
نعم |
نعم |
نعم |
نعم |
|
| توب أند تكإي (تكلمي-Hub-Speaker) |
لا |
نعم |
نعم |
نعم |
||
| دعم BBR |
إختيار TCP مع BBR |
جزئي | جزئي |
ثنائي |
ثنائي |
|
| الأنظمة الأساسية |
النظم الأساسية المدعومة |
فقط 4300 و CSR |
الكل باستثناء ISR1100 |
الكل |
الكل |
التكوين
يتم إستخدام مفهوم SN و CN لتحسين TCP:
- SN هو برنامج تشغيل مسؤول عن تحسين تدفقات TCP فعليا.
- تعرف CN باسم وحدة التحكم في التطبيق وهي مسؤولة عن تحديد حركة المرور والنقل إلى/من SN.
يمكن تشغيل SN و CN على الموجه نفسه أو فصله كعقد مختلفة.
وهناك حالتان رئيسيتان للاستعمال:
- حالة إستخدام الفرع مع تشغيل SN و CN على نفس موجه ISR4k.
- حالة إستخدام مركز البيانات، حيث يتم تشغيل CN على ASR1k و SN على موجه CSR1000V ظاهري منفصل.
يتم وصف حالتي الاستخدام في هذا القسم.
أستخدم الحالة 1. تكوين تحسين TCP على فرع (الكل في cEdge واحد)
تظهر هذه الصورة البنية الداخلية العامة لخيار واحد مستقل في فرع:
الخطوة 1. لتكوين تحسين TCP، يلزمك إنشاء قالب ميزة لتحسين TCP في vManage. انتقل إلى التكوين > قوالب > قوالب الميزات > قوالب أخرى > AppQoE كما هو موضح في الصورة.
الخطوة 2. أضف قالب ميزة 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 لها:
فيما يلي معاينة CLI لسياسة vSmart:
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. قم بتكوين تحسين TCP في مركز البيانات باستخدام SN خارجي
الفرق الرئيسي في حالة إستخدام الفرع هو الفصل المادي بين SN و CN. في حالة إستخدام الفرع متعدد الإمكانات، يتم إجراء الاتصال داخل الموجه نفسه باستخدام واجهة مجموعة المنافذ الظاهرية. في حالة إستخدام مركز البيانات، يوجد نفق مغلف ب AppNav GRE بين ASR1k الذي يعمل ك CN و CSR1k خارجي يعمل ك SN. لا حاجة إلى إرتباط مخصص أو اتصال عكسي بين CN و SN خارجي، يكفي الوصول البسيط إلى IP.
يوجد نفق AppNav (GRE) واحد لكل SN. للاستخدام المستقبلي، حيث يتم دعم العديد من شبكات SN، يوصى باستخدام الشبكة الفرعية /28 للشبكة بين CN و SN.
يوصى باستخدام بطاقتي واجهة شبكة (NIC) على بطاقة CSR1k تعمل كبطاقة واجهة شبكة (NIC) ثانية لوحدة التحكم SD-WAN مطلوبة إذا كان يلزم تكوين/إدارة SN بواسطة vManage. إذا كان سيتم تكوين/إدارة SN يدويا، فعندئذ تكون بطاقة واجهة الشبكة (NIC) الثانية إختيارية.
تظهر هذه الصورة Data Center ASR1k قيد التشغيل كCN و CSR1KV كعقدة خدمة SN :
يتم عرض مخطط حالة إستخدام مركز البيانات مع ASR1k و CSR1k الخارجي هنا:
يظهر قالب ميزة AppQoE هذا ASR1k الذي تم تكوينه كوحدة تحكم:
يتم عرض CSR1k الذي تم تكوينه كعقدة خدمة خارجية هنا:
حالة تجاوز الفشل
تجاوز الفشل في حالة إستخدام مركز البيانات مع CSR1k التي تعمل ك SN، في حالة فشل CSR1k خارجي:
- يتم فقد جلسات عمل TCP الموجودة بالفعل لأن جلسة TCP على SN يتم إنهاؤها.
- يتم إرسال جلسات عمل TCP الجديدة إلى الوجهة النهائية، ولكن لا يتم تحسين حركة مرور TCP (الالتفافية).
- لا تعتيم على حركة المرور المثيرة للاهتمام في حالة فشل SN.
يعتمد اكتشاف تجاوز الأعطال على نبضات القلب من AppNav، والتي تبلغ 1 نبضة في الثانية. بعد 3 أو 4 أخطاء، يتم إعلان النفق على أنه أسفل.
يكون تجاوز الفشل في حالة إستخدام الفرع مماثلا - في حالة فشل SN، يتم إرسال حركة مرور البيانات غير المحسنة مباشرة إلى الوجهة.
التحقق من الصحة
استخدم هذا القسم لتأكيد عمل التكوين بشكل صحيح.
تحقق من تحسين TCP على CLI باستخدام أمر CLI هذا وارجع ملخص التدفقات المحسنة:
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 معين.
تم أخذ جميع الأمثلة من صورة IOS XE SD-WAN 17.2.1 التي تعمل على ISR4431.
- اعثر على معرف VRF (والذي لا يتوافق مع اسم VRF). في هذه الحالة نرى في الإخراج أدناه، أن خدمة VPN (VRF) 1 لها معرف VRF رقم 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 الخاصة بالخدمة - نرى هنا 4 تدفقات مختلفة بين عميلين في نظام التشغيل Windows باستخدام مشاركة SMB عبر منفذ TCP رقم 445:
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 للتدفق المناسب:
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#
- يمكنك الاطلاع أيضا على حالات TCP OPT العامة، والتي تعرض أيضا 4 تدفقات محسنة:
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#
إستخدام TCPOpt مع ميزات أخرى من AppQoE / UTD بدءا من 17.2
في 16.12، تكون حالة الاستخدام الأساسية ل TCPOpt هي من فرع إلى فرع. هناك إعادة توجيه منفصلة لوكيل TCP وإعادة توجيه منفصلة إلى حاوية UTD في 16.12، ولهذا السبب لا يعمل TCP Opt مع الأمان في 16.12
في 17.2، يتم تنفيذ مسار سياسة مركزي، مما سيكشف عن الحاجة لبروتوكول TCP Opt and Security.
سيتم إعادة توجيه الحزم التي تم إعادة إصدارها إلى مستوى الخدمة (Punted) مرة واحدة فقط.
خيارات تدفق مختلفة ممكنة بدءا من 17.2:
- TCP إختياري فقط
- UTD فقط
- TCP Opt -> UTD
- TCP OPT -> وكيل SSL -> UTD
معلومات ذات صلة
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
1.0 |
29-Jan-2020
|
الإصدار الأولي |
التعليقات