3. Compute Node và vRouter
Mục lục
Section 4 — Compute Node và vRouter
Mental Model
Hãy nghĩ về một bưu cục địa phương.
vRouter Agent = Nhân viên quầy lễ tân. Nhận thông tin từ tổng cục (control node), ghi vào sổ địa chỉ nội bộ. Khi có thư đến lần đầu, nhân viên quyết định nên gửi đến đâu và hướng dẫn cho bộ phận vận chuyển.
vRouter Forwarding Plane = Bộ phận vận chuyển vật lý. Không cần biết lý do, chỉ cần biết địa chỉ và mang thư đến đúng nơi với tốc độ cao nhất. Khi đã có hướng dẫn rồi thì làm tự động, không cần hỏi lại nhân viên quầy.
User Space vs Kernel Space — Phân chia rõ ràng
Đây là điểm cực kỳ quan trọng để hiểu vRouter:
Tại sao tách User Space và Kernel Space?
| Tiêu chí | User Space (Agent) | Kernel Space (FWD) |
|---|---|---|
| Tốc độ | Chậm hơn (context switch) | Nhanh nhất |
| Flexibility | Cao (logic phức tạp, dễ update) | Thấp (stable, ít thay đổi) |
| Safety | Crash không ảnh hưởng kernel | Crash ảnh hưởng toàn server |
| Scope | Control plane decisions | Data plane forwarding |
| First packet | ✓ (policy decision) | Punt lên agent |
| Subsequent packets | Không cần | ✓ (fast path) |
4.1 vRouter Agent — Chi tiết từng chức năng
Chức năng 1: XMPP Client
Agent duy trì kết nối đến 2+ Control Node (active/active). Mỗi Control Node gửi routes và config — agent nhận từ cả hai và tự làm best-selection, giống cách một PE router (Provider Edge — router biên nằm ở rìa mạng nhà cung cấp dịch vụ, nơi tiếp nhận route VPN của khách hàng) nhận route từ nhiều BGP neighbor rồi tự chọn ra route tốt nhất.
vRouter Agent ──── XMPP session 1 ────► Control Node 1
└─── XMPP session 2 ────► Control Node 2
Cả hai sessions đều active. Agent nhận updates từ cả hai.
Nếu Control Node 1 fail → Agent flush state từ node 1,
dùng state từ node 2 (đã có sẵn), reconnect đến node mới.
Chức năng 2: Installs Forwarding State
Agent nhận routing instance config và routes từ Control Node, rồi cài vào kernel module qua system calls/netlink interface.
Control Node (XMPP) ──► Agent ──► System call ──► Kernel FIB
"Route 10.1.1.5/32, "Add route to vRouter FWD
NH=tunnel(Compute2), routing instance A" plane cập nhật
MPLS label=51"
Chức năng 3: First Packet Processing
Flow bắt đầu như thế nào?
Trước khi vào chi tiết, cần hiểu một thuật ngữ sẽ xuất hiện liên tục từ đây trở đi: "punt". Đây là cách gọi trong giới networking khi kernel/hardware gặp packet mà nó không tự xử lý được (thiếu policy, thiếu flow entry...) và phải đẩy packet đó lên tầng phần mềm cao hơn (ở đây là vRouter Agent) để xử lý, thay vì tiếp tục xử lý bằng con đường tốc độ cao thông thường.
Lý do thiết kế này: packet đầu tiên cần policy decision phức tạp (agent). Các packet tiếp theo dùng fast path (kernel) để đạt throughput cao.
Chức năng 4: Proxy Services
Agent proxy các protocol sau để tránh flooding:
| Protocol | Tại sao proxy? | Cách hoạt động |
|---|---|---|
| ARP | Nếu flood ARP → gây BUM storm trong overlay | Agent trả lời ARP trực tiếp dựa vào MAC table từ Control Node |
| DHCP | Cần cung cấp IP đúng cho VM | Agent trả lời DHCP theo config VM từ Control Node |
| DNS | Cần name resolution nhanh | Agent cung cấp dựa vào mapping từ Control Node |
| MDNS | Multicast DNS → tránh flooding | Agent proxy |
Chức năng 5: VM Discovery
Agent phối hợp với OpenStack Nova agent để phát hiện VM mới:
- Nova agent tạo VM (KVM).
- Nova agent notify vRouter Agent về VM mới (IP, MAC, VN).
- vRouter Agent cấu hình VN cho VM (tạo virtual interface, cài routes).
- vRouter Agent advertise VM route lên Control Node qua XMPP.
4.2 vRouter Forwarding Plane — Data Path Chi Tiết
Cấu trúc bảng forwarding
Kernel module duy trì nhiều loại bảng:
┌─────────────────────────────────────────────────────────────┐
│ vRouter Forwarding Tables │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Global IP FIB (underlay) │ │
│ │ Dùng để: route outer packet đến đúng compute server │ │
│ │ Key: IP của compute server │ │
│ │ Value: next-hop (MAC của ToR switch, physical port) │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ MPLS FIB (label → routing instance) │ │
│ │ Dùng để: decap MPLS, route về đúng VM trên server │ │
│ │ Key: MPLS label (locally allocated) │ │
│ │ Value: routing instance + VM interface │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────── Per Virtual Network ─────────────────────┐ │
│ │ Routing Instance VN-A: │ │
│ │ IP FIB: 10.1.1.5/32 → NH(tunnel Compute2, L51) │ │
│ │ IP FIB: 10.1.1.6/32 → NH(tunnel Compute3, L72) │ │
│ │ IP FIB: 10.1.1.7/32 → NH(vif3, local VM) │ │
│ │ MAC FIB: (nếu L2 enabled) │ │
│ │ Flow Table: [src,dst,proto,sport,dport] → action │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Routing Instance VN-B: │ │
│ │ ... (tương tự, hoàn toàn độc lập) │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Packet Processing Pipeline
Packet đến từ VM (egress từ VM, ingress vào vRouter):
1. Virtual interface (vif) binding
└─► Gán vào routing instance đúng (dựa vào vif config)
2. Flow table lookup
├─► Match found → apply action (forward/drop/redirect)
└─► No match → PUNT lên Agent (first packet)
3. FIB lookup (nếu forward)
├─► Destination in same server → send to local vif
└─► Destination on remote server:
a. Lookup IP FIB của routing instance → next-hop tunnel
b. Encapsulate (MPLS label + GRE/UDP header)
c. Lookup global IP FIB → physical next-hop
d. Send to physical NIC
Packet đến từ overlay (ingress từ underlay):
1. Nhận outer packet trên physical NIC
2. Global IP FIB lookup → outer dst = local → decap
3. Decap outer header (GRE or UDP)
4. MPLS FIB lookup bằng label → routing instance + VM interface
5. Decap MPLS header
6. Routing instance FIB lookup → local VM vif
7. Deliver packet đến VM
How to Observe in Production
# Xem tất cả virtual interfaces
vif --list
# Output: vif0/3 OS: tap123abc Type:Virtual VN:VN-A IPaddr:10.1.1.7
# Chi tiết một vif cụ thể (ví dụ vif 3)
vif --get 3
# Output: Type:Virtual Mcast Vrf:2 Flags:PL3L2 RX packets:1204 TX packets:1198
# Xem routing table của một routing instance
rt --dump <vrf-id>
# Ví dụ: rt --dump 2
# Output: 10.1.1.5/32 → NH:34 (label 51)
# Xem next-hop table
nh --get <nh-id>
# Ví dụ: nh --get 34
# Output: Type:Tunnel MPLSoUDP Sip:192.168.1.10 Dip:192.168.1.20
# Xem MPLS FIB
mpls --dump
# Xem label cụ thể: mpls --get 51
# Output: Label:51 NH:64 (routing instance VN-A)
# Xem flow table
flow -l
# Output: Index Source:Port/Destination:Port Proto(V) ... Action:Fwd
# Xem statistics
vif --list | grep -A5 "Tenant"
# Xem encap/decap counters
vif --get <vif-id> # xem RX/TX stats
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
vRouter đã biết cách nhận forwarding state và forward packet ngay trong compute node — nhưng làm sao 2 VM trên 2 server vật lý khác nhau nói chuyện được với nhau qua underlay IP network? Câu trả lời nằm ở overlay encapsulation, chủ đề của phần tiếp theo.
Nguồn tham khảo
- Câu lệnh xem flow table đúng cú pháp là
flow -l(short flag), không phảiflow --list— vRouter Command Line Utilities, Contrail Networking 21, truy cập 08/2026 - Các lệnh
vif,rt,nh,mpls(dump/get) vẫn đúng cú pháp hiện tại — vRouter Command Line Utilities, Contrail Networking 21, truy cập 08/2026