9. DPDK, Evolution (Tungsten Fabric/CN2) & Vận hành

Mục lục

Section 17 — DPDK vRouter: High-Performance Mode
Section 18 — Contrail Evolution: Tungsten Fabric và CN2
Appendix A — Troubleshooting Playbook
Appendix B — Quick Reference

Section 17 — DPDK vRouter: High-Performance Mode

Mental Model

So sánh với xe tải thông thường vs xe tải chuyên dụng cao tốc:

Kernel vRouter = Xe tải đi đường thường — phải dừng ở mọi trạm kiểm soát (system call, context switch giữa kernel và user space, interrupt).

DPDK vRouter = Xe tải chuyên dụng cao tốc — có làn đường riêng từ NIC thẳng đến user space, không bị interrupt, không dừng trạm nào. Nhanh hơn nhiều nhưng cần "đường cao tốc riêng" (huge pages, CPU dedicated).

Ba Mode Triển khai vRouter

Mode 1: Kernel Module (default)
  vRouter Forwarding Plane = Linux kernel module
  Tương tác với NIC qua kernel network stack
  Advantages: đơn giản, không cần config đặc biệt
  Limitations: sys call overhead, interrupt overhead, kernel context switch

Mode 2: DPDK User-Space (high performance)
  vRouter Forwarding Plane = user-space process (links với DPDK library)
  Tương tác với NIC qua PMD (Poll Mode Driver) — bypass kernel
  Advantages: 10-30x tăng throughput, sub-microsecond latency
  Requirements: huge pages, DPDK-compatible NIC, dedicated CPU cores

Mode 3: SmartNIC Offload
  Forwarding logic offload xuống SmartNIC (e.g., Mellanox ConnectX-6 Dx)
  vRouter agent vẫn chạy user space
  Advantages: giải phóng CPU của host hoàn toàn
  Requirements: SmartNIC hỗ trợ Contrail offload

17.1 Tại Sao DPDK Nhanh Hơn?

Kernel mode packet path:
  NIC → DMA → Kernel ring buffer
      → Hardware interrupt → kernel context switch
      → Network stack (nhiều layers)
      → System call boundary
      → vRouter kernel module

DPDK mode packet path:
  NIC → DMA → DPDK memory pool (huge pages)
      → PMD polling (no interrupt, no context switch)
      → DPDK vRouter (user space)

📝 Suy luận (con số ước lượng): Latency "~1–3µs / ~10M PPS" (kernel) và "~100–300ns / ~30–100M PPS" (DPDK) là ước lượng từ general DPDK benchmarks, không phải số đo từ môi trường Contrail cụ thể. Juniper Day One DPDK book xác nhận DPDK "xử lý nhiều PPS hơn kernel module" nhưng không đưa con số chính xác. Số thực tế phụ thuộc NIC model, CPU, packet size.

17.2 Yêu Cầu DPDK

Huge Pages (bắt buộc):

Vì sao cần huge pages?
  Linux default page size: 4KB
  Network buffer pool cần hàng GB RAM → hàng triệu page entries → TLB miss nhiều
  Huge pages: 1GB hoặc 2MB per page → ít TLB entries hơn → cache hit cao hơn

Cấu hình:
  # Trong /etc/sysctl.conf
  vm.nr_hugepages = 1024  # × 1GB pages = 1TB (điều chỉnh theo RAM)
  
  # Hoặc 2MB pages
  vm.nr_hugepages = 512000  # × 2MB = 1GB

CPU Pinning:

DPDK dùng "busy polling" — core chạy 100% CPU liên tục
  (không sleep giữa các poll cycle — đây là lý do vì sao nhanh)

Cần dedicate CPU cores cho DPDK forwarding:
  isolcpus=2,3,4,5   (trong kernel boot params)
  DPDK_COMMAND_ADDITIONAL_ARGS="--lcores 2,3,4,5"

Typical allocation (compute node 16 cores):
  Core 0-1:  OS, nova, vRouter agent
  Core 2-9:  DPDK vRouter forwarding (8 cores)
  Core 10-15: VM vCPUs

NIC yêu cầu: (NIC list là từ DPDK project docs chung; Contrail-specific compatibility list xem tại Juniper Release Notes)

Phải hỗ trợ DPDK PMD:
  Intel: ixgbe (82599), i40e (XL710), ice (E810)
  Mellanox/NVIDIA: mlx5 (ConnectX-4 đến ConnectX-7, BlueField DPU)
  Broadcom: bnxt
  Virtio: virtio-pmd (cho VM-in-VM)

NUMA awareness:
  NIC và DPDK memory pool phải cùng NUMA node với CPU forwarding
  → hugepages allocation phải pin đúng NUMA node

📝 Suy luận: NUMA awareness requirement là suy luận từ DPDK best practices chung, không phải requirement được Contrail docs liệt kê riêng.

17.3 Cấu hình Contrail DPDK

(Các field dưới đây được xác nhận từ Juniper Contrail 19/21 docs — instances.yaml format)

# instances.yaml (Ansible-based provision)
instances:
  compute1:
    provider: bms
    ip: 192.168.1.10
    roles:
      vrouter:
        DPDK_ENABLED: true
        CPU_CORE_MASK: "0xfc"     # binary mask: cores 2,3,4,5,6,7
        HUGE_PAGES: 4096          # số 2MB huge pages
        HUGE_PAGES_DIR: /dev/hugepages
        DPDK_UIO_DRIVER: uio_pci_generic  # hoặc vfio-pci

📝 Suy luận: Ví dụ CPU core allocation "16 cores: 0-1 OS, 2-9 DPDK, 10-15 VM" ở section trên là minh họa điển hình, không phải con số bắt buộc từ Juniper.

So Sánh Kernel vs DPDK

Tiêu chí	Kernel Module	DPDK User-Space
Throughput	~5-10 Mpps per core	~30-100 Mpps per core
Latency	50-200 µs	5-30 µs
CPU usage	Thấp (interrupt-driven)	Cao (busy-poll, 100%)
Huge pages	Không cần	Bắt buộc
DPDK NIC	Không cần	Bắt buộc
Config phức tạp	Thấp	Cao (CPU pinning, hugepages)
Use case	Dev/test, low-traffic	Production NFV, telco cloud
Upgrade vRouter	Reload kernel module	Restart user process

Section 18 — Contrail Evolution: Tungsten Fabric và CN2

Timeline tiến hóa

2012: Juniper mua lại Contrail Systems (startup mới thành lập đầu năm 2012)
      → 2013-2015: Contrail Networking trở thành sản phẩm thương mại chính thức
      → Whitepaper gốc xuất bản 2015, open-standard SDN cho data center

2013: Juniper open-source hóa Contrail dưới tên OpenContrail (Apache 2.0)
      → Chạy song song với bản thương mại Contrail Networking ngay từ đầu,
        không phải một sự kiện tách riêng sau này

2017: Contrail Networking 4.x
      → Tag-based security policy
      → Kubernetes integration (beta)
      → DPDK vRouter
      → IF-MAP và Discovery Service bắt đầu deprecated

2018: OpenContrail đổi tên thành Tungsten Fabric (TF), hoàn tất chuyển giao
      cho Linux Foundation Networking (LFN)
      → Đây là mốc đổi tên/chuyển governance, không phải mốc "open-source hóa"
        (việc đó đã xảy ra từ 2013)
      → Juniper vẫn contribute chính

2020: Contrail Networking 20.x / Tungsten Fabric 20.x
      → Production-grade Kubernetes support
      → BGPaaS improvements

2022: CN2 (Cloud-Native Contrail Networking) ra đời, giới thiệu cùng Contrail 22.1
      → Kiến trúc lại hoàn toàn cho Kubernetes-native
      → CRD-based, GitOps, kubectl-native

2022-2024: CN2 22.x, 23.x, 24.x
      → Hybrid: OpenStack + Kubernetes trên cùng fabric
      → SmartNIC offload
      → Multi-cluster federation

18.1 Tungsten Fabric (Open-Source)

Tungsten Fabric là tên gọi hiện tại của nhánh mã nguồn mở Contrail (bản thân Contrail đã open-source từ 2013 dưới tên OpenContrail; Tungsten Fabric chỉ là tên mới sau khi chuyển giao cho Linux Foundation Networking năm 2018) — cùng codebase, cùng kiến trúc từ Section 1-13.

⚠️ Cập nhật trạng thái dự án: Linux Foundation Networking đã đưa Tungsten Fabric vào trạng thái archived — development chính thức ngừng, tài nguyên dự án (CI, release) chỉ được giữ truy cập đến 01/08/2024. Nội dung bên dưới mô tả kiến trúc dự án ở giai đoạn còn active; vẫn còn cộng đồng dùng và tự maintain fork riêng, nhưng đây không còn là lựa chọn có roadmap/release chính thức cho triển khai mới. Chi tiết ở mục Nguồn tham khảo cuối bài.

Khác biệt so với Contrail thương mại (giai đoạn còn active):
  + Miễn phí, community support
  + Không cần Juniper license
  - Không có Juniper commercial support
  - Release cycle có thể chậm hơn

Repository: github.com/tungstenfabric
Docker images: tungstenfabric/contrail-*

Cùng components:
  contrail-controller    → Config + Control + Analytics
  contrail-vrouter-agent → vRouter Agent
  contrail-vrouter-dpdk  → DPDK vRouter

18.2 CN2 — Cloud-Native Contrail Networking

CN2 là bước tiến hóa lớn nhất: thiết kế lại hoàn toàn để native với Kubernetes.

Khác biệt kiến trúc so với Contrail cổ điển:

Khía cạnh	Contrail Classic	CN2
Orchestration	OpenStack (Neutron plugin)	Kubernetes (CRD-native)
Configuration	REST API (Contrail GUI/API)	kubectl / YAML manifests
Storage	Cassandra	etcd (qua K8s)
Coordination / ID allocation	ZooKeeper	Kubernetes Service + etcd watch
RBAC	Contrail RBAC	Kubernetes RBAC
GitOps	Không native	✓ (manifest-driven)
vRouter	Kernel module / DPDK	Kernel module / DPDK (giống)

CN2 Components:

cn2-controller:
  Thay thế cho Config Node + Control Node
  Runs as K8s Deployment (multiple replicas)
  Stores state in etcd (K8s native)

cn2-vrouter-agent:
  Runs as DaemonSet trên mọi worker node
  Giống vRouter Agent cổ điển nhưng managed bởi K8s

Custom Resource Definitions (CRDs):
  VirtualNetwork     → thay vì REST API call
  VirtualMachineInterface → port definition
  NetworkPolicy      → security policy
  FloatingIP         → NAT configuration
  BGPRouter          → BGP peering

GitOps workflow với CN2:

# Tạo VN qua kubectl apply
apiVersion: core.contrail.juniper.net/v1alpha1
kind: VirtualNetwork
metadata:
  name: web-tier
  namespace: production
spec:
  v4SubnetReference:
    apiVersion: core.contrail.juniper.net/v1alpha1
    kind: Subnet
    name: web-subnet
  routeTargetList:
    routeTarget:
      - "target:65000:100"

Hybrid deployment (OpenStack + Kubernetes):

CN2 hỗ trợ cả hai orchestrators trên cùng một vRouter fabric:
  
  Compute nodes với OpenStack VMs:
    nova-compute + vRouter agent (classic mode)
    
  Compute nodes với K8s pods:
    kubelet + cn2-vrouter-agent
    
  Cùng Control Plane:
    cn2-controller quản lý cả hai
    Routes shared qua BGP (cùng route target space)
    
Use case: Data center đang migrate từ VM-based sang container-based
  → Không cần tách riêng overlay fabric
  → VM và Pod có thể nói chuyện với nhau

Common Pitfalls khi Migrate sang CN2

📝 Suy luận: Phần này được suy luận từ sự khác biệt kiến trúc (Cassandra vs etcd, REST vs CRD) và kinh nghiệm chung về migration giữa hai kiến trúc khác nhau. Chưa tìm được nguồn Juniper migration guide chính thức xác nhận từng point.

1. Cassandra → etcd: Data migration cần tool riêng
   (không thể in-place upgrade Contrail Classic → CN2)

2. CRD naming: K8s namespace scope ảnh hưởng đến tenant isolation
   (trong Classic: tenant = project trong Contrail DB)
   (trong CN2: tenant = K8s namespace)

3. API backward compat: Contrail REST API không available trong CN2
   (phải dùng kubectl hoặc Kubernetes API)

4. Monitoring: Sandesh → K8s-native observability (Prometheus, Jaeger)

Appendix A — Troubleshooting Playbook

A.1 VM vừa tạo không ping được VM khác cùng VN

Symptoms:
  • VM mới tạo xong, ping VM khác trong cùng VN fail
  • Ping ra ngoài VN cũng fail

Debug approach:

Step 1: Check vRouter Agent status trên compute của VM mới
  contrail-status | grep agent
  → Phải thấy: contrail-vrouter-agent  active  running

Step 2: Check vif đã được tạo chưa
  vif --list | grep <vm-name>
  → Phải thấy vif với VM's IP

Step 3: Check route đã được install chưa
  rt --dump <vrf-id>
  → Phải thấy /32 route cho VM mới
  Nếu thiếu: agent chưa cài route → check XMPP connection

Step 4: Check XMPP connection
  curl http://localhost:8085/Snh_AgentXmppConnectionStatusReq
  → Phải thấy state: Established
  Nếu không: check network connectivity đến control node

Step 5: Check route đã propagate đến compute của VM nguồn
  (Login vào compute của VM nguồn)
  rt --dump <vrf-id>
  → Phải thấy /32 route cho VM mới với tunnel next-hop
  Nếu thiếu: control node chưa distribute → check control node logs

Step 6: Check flow table
  flow -l | grep <src-ip>
  → Nếu thấy flow với action=drop: check security group rules
  → Nếu không thấy flow: packet không reach vRouter → check VM OS

A.2 Traffic chậm bất thường (high latency)

Symptoms:
  • Ping có reply nhưng latency cao (>10ms trong cùng rack)
  • Throughput thấp hơn mong đợi

Possible causes:

Cause 1: First packet chậm (agent processing)
  → Bình thường: first packet bị punt lên agent
  → Check: sau vài giây latency có giảm không?
  → Nếu LUÔN chậm → xem Cause 2

Cause 2: ECMP không work (all traffic qua 1 path)
  → Check encapsulation type: dùng MPLSoGRE không có entropy
  → Fix: đổi sang MPLSoUDP hoặc VXLAN
  
Cause 3: Control node overloaded
  → vRouter nhận state update chậm
  → Check control node CPU/memory

Cause 4: Underlay congestion
  → Outer IP packet bị queue/drop trên switch
  → Check interface counters trên switch

A.3 Control Node không nhận routes từ vRouter

Symptoms:
  • vRouter agent running nhưng routes không propagate
  • VM tạo mới không reach được từ nơi khác

Debug:

1. Check XMPP state trên vRouter
   curl http://localhost:8085/Snh_AgentXmppConnectionStatusReq

2. Check BGP state trên control node
   contrail-introspect --host <control-node> --port 8083 \
     BgpNeighborReq

3. Check route table trên control node
   contrail-introspect --host <control-node> --port 8083 \
     ShowRouteReq table=<vrf-name>

4. Check RabbitMQ/Cassandra connectivity (control → config) — thay cho check IF-MAP cũ
   # Trên control node, soi log contrail-control tìm lỗi kết nối RabbitMQ/Cassandra
   grep -i "rabbitmq\|cassandra" /var/log/contrail/contrail-control.log

A.4 Service Chain không hoạt động

Symptoms:
  • Traffic từ VN-A đến VN-B fail khi có service chain
  • Hoặc traffic bypass service chain (không qua FW)

Debug:

1. Check Service Instance status
   contrail-status | grep svc

2. Check routing instances được tạo đúng chưa
   rt --dump <ri-fw-left-vrf-id>
   rt --dump <ri-fw-right-vrf-id>

3. Check next-hop-self trên leaked routes
   rt --dump <ri-web-tier-vrf-id>
   → Routes đến app-tier phải có NH = fw VM's compute, không phải app VM's compute

4. Check service VM đang running và có traffic
   vif --list (trên compute của service VM)
   → Phải thấy left và right vif với traffic counters

5. Check flow table trên source compute
   flow -l | grep "10.1.2."
   → Xem action: forward hay drop
   → Xem next-hop: phải là fw VM's compute

Appendix B — Quick Reference

Ports và Protocols

Service	Port	Protocol
Config Node REST API	8082	HTTPS
Config Node IF-MAP²	8443	HTTPS
Control Node BGP	179	TCP
Control Node XMPP	5269	TCP
Analytics REST API	8081	HTTP
Analytics Collector	8086	TCP (Sandesh)
vRouter Agent Introspect	8085	HTTP
vRouter Forwarding Introspect	8102	HTTP
vRouter Agent ↔ Nova-compute	9090	TCP
VXLAN	4789	UDP
MPLSoUDP	51234¹	UDP

¹ 51234 là port legacy/mặc định mà vRouter dùng khi gửi gói MPLSoUDP. IANA sau đó chính thức gán port 6635 cho MPLS-in-UDP (RFC 7510) — vRouter hiện tại nhận được cả hai port nhưng vẫn giữ 51234 làm port gửi mặc định để tương thích ngược. Xem Nguồn tham khảo.

² Port 8443 chỉ phục vụ IF-MAP Server — cơ chế này đã bị deprecated từ Contrail 4.0, thay bằng RabbitMQ + Cassandra (không dùng port riêng theo kiểu network peer trên Config Node nữa). Giữ dòng này lại để tra cứu tài liệu/log cũ, không phải cấu hình còn hoạt động ở bản hiện tại. Xem Nguồn tham khảo.

Useful Introspect URLs

# vRouter Agent
http://compute:8085/Snh_AgentXmppConnectionStatusReq  # XMPP status
http://compute:8085/Snh_VrfListReq                    # VRF/Routing instances
http://compute:8085/Snh_RouteListReq                  # Route table
http://compute:8085/Snh_FlowRecordsReq                # Flow entries
http://compute:8085/Snh_VnListReq                     # Virtual Networks

# Control Node
http://control:8083/Snh_BgpNeighborReq               # BGP neighbors
http://control:8083/Snh_ShowRouteReq                  # Route table
http://control:8083/Snh_XmppConnectionInfo            # XMPP sessions

# Config Node
http://config:8082/virtual-networks                   # All VNs
http://config:8082/virtual-machine-interfaces         # All ports

Terminology Quick Reference

Term	Nghĩa
VN (Virtual Network)	Mạng ảo của một tenant/ứng dụng. Tương tự VRF trong MPLS VPN.
Routing Instance	Triển khai kỹ thuật của VN trên vRouter. Mỗi VN = 1+ routing instance.
Route Target	BGP community dùng để kiểm soát route import/export giữa routing instances.
VNI	VXLAN Network Identifier. Identifies L2 segment.
vif	Virtual Interface. Kết nối giữa VM và vRouter.
Encap	Encapsulation type: MPLSoGRE, MPLSoUDP, VXLAN.
FIB	Forwarding Information Base. Bảng routing/forwarding.
Flow Table	Per-flow entries với match criteria và action.
XMPP	Protocol giữa Control Node và vRouter Agent.
RabbitMQ + Cassandra	Kênh notify + kho lưu object giữa Config Node và Control Node — thay thế IF-MAP từ Contrail 4.0.
IF-MAP	Protocol pub/sub cũ giữa Config Node và Control Node — đã deprecated từ Contrail 4.0.
Sandesh	Protocol telemetry giữa tất cả component và Analytics Node.
Schema Transformer	Component "compile" high-level config thành low-level config.
Headless mode	vRouter forwarding plane chạy không có agent (sau khi agent crash).

Lời kết

Từ mental model "tòa nhà văn phòng" ở phần 1 đến DPDK datapath và CN2 CRD ở phần này, series đã đi qua toàn bộ kiến trúc Contrail: hai thành phần Controller/vRouter, ba loại node bên trong Controller, cách packet được encapsulate và forward qua overlay, service chaining, các protocol nền tảng, cơ chế HA, data model, use case thực tế, và các tính năng network service (Security Group, Floating IP, BGPaaS). Điểm mấu chốt cần nhớ: Contrail tách biệt hoàn toàn control plane (nơi quyết định routing) khỏi data plane (nơi forward packet) — kiến trúc này vẫn sống tiếp dưới tên Tungsten Fabric (open-source) và CN2 (cloud-native, Kubernetes), dù bản thân sản phẩm Contrail gốc đã ngừng phát triển.

Nguồn tham khảo

Các điểm dưới đây được đính chính/bổ sung so với nhận định ban đầu trong whitepaper 2015/docs cũ:

Tungsten Fabric ("Contrail open-sourced") — dự án đã được Linux Foundation Networking đưa vào trạng thái archived, development chính thức ngừng, tài nguyên chỉ giữ truy cập đến 01/08/2024 — The New Stack, LF Networking – TungstenFabric Archives, truy cập 07/2026
MPLSoUDP destination port — 51234 vẫn đúng là port legacy mà vRouter dùng để gửi, nhưng IANA đã chính thức gán port 6635 cho MPLS-in-UDP theo RFC 7510; vRouter hiện nay chấp nhận nhận cả hai port — Juniper OpenStack Bug #1420900, truy cập 07/2026
Control Node XMPP port 5269 — xác nhận đúng; ngoài ra còn có biến thể TLS-based XMPP trên port 5222 — Juniper/contrail-controller Wiki — Roles Daemons Ports, truy cập 07/2026
Vendor/sở hữu sản phẩm CN2 — HPE đã hoàn tất mua lại Juniper Networks; CN2 hiện là sản phẩm thuộc "HPE Juniper Networking", vẫn active và được các nhà mạng lớn (BT, Deutsche Telekom, Etisalat, Saudi Telecom) sử dụng cho telco cloud — HPE Juniper Networking — CN2 product page, truy cập 07/2026
Juniper mua lại Contrail Systems — tháng 12/2012 (~176 triệu USD); Contrail Networking trở thành sản phẩm thương mại chính thức cuối 2013, whitepaper gốc xuất bản 2015 — Yahoo Finance, AllThingsD, truy cập 07/2026
CN2 ra đời — tháng 5/2022, giới thiệu cùng Contrail 22.1 — RCR Wireless, SDxCentral, truy cập 07/2026
Port bổ sung — port 9090 dùng cho giao tiếp vRouter Agent ↔ Nova-compute, chưa có trong bảng gốc — Juniper/contrail-controller Wiki, truy cập 07/2026
CRD apiVersion: core.contrail.juniper.net/v1alpha1 — xác nhận đúng, dùng cho VirtualNetwork/Subnet CRD trong CN2 — Juniper CN2 docs, truy cập 07/2026
DPDK NIC list — Intel ixgbe/i40e/ice và Mellanox mlx5 đều đúng; mlx5 hiện hỗ trợ thêm ConnectX-7 và dòng NVIDIA BlueField DPU — DPDK mlx5 docs, DPDK ice docs, truy cập 07/2026
Contrail open-source hóa lần đầu năm 2013 dưới tên OpenContrail (Apache 2.0), chạy song song bản thương mại Contrail Networking ngay từ đầu; tên gọi Tungsten Fabric và việc chuyển giao cho Linux Foundation Networking chỉ xảy ra năm 2018 — đây là mốc đổi tên/chuyển governance, không phải mốc open-source hóa lần đầu — Juniper Networks Launches Production-Ready SDN Solution, OpenContrail is Now 'Tungsten Fabric,' Completes Move to The Linux Foundation, truy cập 08/2026
Lệnh xem flow table đúng cú pháp là flow -l (short flag), không phải flow --list — vRouter Command Line Utilities, Contrail Networking 21, truy cập 08/2026
Introspect endpoint IFMapPeerServerInfoReq trên Control Node đã bị gỡ khỏi source tree sau khi IF-MAP deprecated (Contrail 4.0) — chỉ còn lại một field trạng thái (ifmap_info) nhúng trong UVE BgpRouterState, không còn là một request introspect độc lập; port 8443 (Config Node IF-MAP Server) tương ứng cũng không còn phục vụ network peer nào — Juniper/contrail-controller — control_node.sandesh, tag R1919 so với v2.0; tungstenfabric/tf-controller, truy cập 08/2026

Mục lục​

Section 17 — DPDK vRouter: High-Performance Mode​

Mental Model​

Ba Mode Triển khai vRouter​

17.1 Tại Sao DPDK Nhanh Hơn?​

17.2 Yêu Cầu DPDK​

17.3 Cấu hình Contrail DPDK​

So Sánh Kernel vs DPDK​

Section 18 — Contrail Evolution: Tungsten Fabric và CN2​

Timeline tiến hóa​

18.1 Tungsten Fabric (Open-Source)​

18.2 CN2 — Cloud-Native Contrail Networking​

Common Pitfalls khi Migrate sang CN2​

Appendix A — Troubleshooting Playbook​

A.1 VM vừa tạo không ping được VM khác cùng VN​

A.2 Traffic chậm bất thường (high latency)​

A.3 Control Node không nhận routes từ vRouter​

A.4 Service Chain không hoạt động​

Appendix B — Quick Reference​

Ports và Protocols​

Useful Introspect URLs​

Terminology Quick Reference​

Lời kết​

Nguồn tham khảo​