5. Service Chaining & Control/Management Protocols
Mục lục
Section 7 — Service Chaining (NFV)
Mental Model
Hãy nghĩ về quy trình thông quan hàng hóa xuất khẩu.
Hàng hóa (traffic) từ kho (src VN) muốn ra cảng (dst VN). Nhưng phải đi qua:
- Kiểm tra an ninh (Firewall)
- Kiểm dịch (IDS)
- Đóng gói lại (Load Balancer)
Contrail Service Chaining = hệ thống hướng hàng hóa đi đúng quy trình này, dù các trạm kiểm tra có thể nằm ở các server khác nhau trong DC.
Simple Explanation
Service chaining cho phép traffic đi qua một chuỗi dịch vụ mạng ảo (VM) theo thứ tự, trước khi đến đích. Mỗi "dịch vụ" là một VM chạy software như:
- Firewall (iptables, pfSense, Palo Alto VM-Series)
- DPI / IDS (Snort, Suricata)
- Load balancer (HAProxy, NGINX)
- WAN optimizer
Policy Language
allow any src-vn → dst-vn svc-1, svc-2, svc-3
Traffic từ src-vn đến dst-vn phải đi qua svc-1 → svc-2 → svc-3 theo thứ tự.
Cơ chế hoạt động: Routing Instance Manipulation
Đây là phần kỹ thuật quan trọng nhất của service chaining.
Không có service chain (traffic direct):
ri-src (VN A) ─────────────────────────────► ri-dst (VN B)
VM-A1 VM-B1
Có service chain (traffic phải qua service VM):
Control plane: Route leaking được manipulate theo thứ tự ngược lại
ri-dst (VN B) ──export──► ri-s2 (Service 2 VN) ──export──► ri-s1 (Service 1 VN) ──export──► ri-src (VN A)
Data plane: Traffic theo đúng thứ tự xuôi chiều
ri-src (VN A) ──────► ri-s1 (Service 1 VN) ──────► ri-s2 (Service 2 VN) ──────► ri-dst (VN B)
VM-A1 service VM-s1 service VM-s2 VM-B1
Packet Walk trong Service Chain
Scenario: VM-A1 (10.1.1.3) gửi traffic đến VM-B1 (10.2.1.3). Chain: Firewall → DPI.
BƯỚC 1: VM-A1 gửi packet đến 10.2.1.3
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
vRouter Compute1 lookup IP FIB VN-A:
10.2.1.3/32 → leaked route from VN-B
Nhưng next-hop bị manipulate: → Tunnel đến Compute-FW (service VM-s1)
với MPLS label = label của ri-s1 trên Compute-FW
BƯỚC 2: Packet đến Firewall VM (Compute-FW)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Compute-FW decap → routing instance ri-s1
FW VM nhận packet, kiểm tra rules, allow → gửi lại ra interface kia của FW VM
BƯỚC 3: Tiếp tục đến DPI VM
━━━━━━━━━━━━━━━━━━━━━━━━━━━
Egress interface của FW VM thuộc ri-s2.
ri-s2 FIB: 10.2.1.3/32 → next-hop bị manipulate → Tunnel đến Compute-DPI
MPLS label = label của ri-s2-egress trên Compute-DPI
BƯỚC 4: DPI kiểm tra xong → forward
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Egress từ DPI VM → ri-s2-egress
FIB: 10.2.1.3/32 → next-hop = actual VM-B1 (Compute2)
Encap → Compute2 → decap → ri-dst → VM-B1
Cơ chế next-hop-self trong service routing instance
Khi route được leaked từ ri-dst sang ri-s2:
- Gốc: 10.2.1.3/32, next-hop = actual Compute2
- Sau khi ri-s2 export: 10.2.1.3/32, next-hop = service VM-s2's ingress interface (next-hop-self), MPLS label mới
Điều này buộc traffic phải đi qua service VM — không thể bypass. Traffic đến service VM's compute server, kernel decap đến routing instance của service VM, VM xử lý, rồi tiếp tục chain.
Service VM Types
| Mode | Số interface | Mô tả |
|---|---|---|
| In-network | 3 (left, right, mgmt) | Traffic đi vào left interface, ra right interface. Service VM biết topology. |
| Transparent | 2 (left, right) | Service VM không biết địa chỉ IP — chỉ inspect/modify L2. |
| In-network NAT | 2 (left, right) | Tương tự in-network nhưng có thể NAT địa chỉ. |
Section 8 — Control và Management Plane Protocols
Mental Model
Hãy nghĩ về hệ thống liên lạc trong một tòa nhà văn phòng lớn.
RabbitMQ + Cassandra = Hệ thống email nội bộ giữa phòng kế hoạch (Config Node) và trung tâm điều phối (Control Node). Phòng kế hoạch gửi thông báo qua email (RabbitMQ) mỗi khi có thay đổi — với thông báo dạng "tạo mới/xóa" thì đính kèm luôn toàn bộ nội dung, còn thông báo dạng "cập nhật" thì chỉ ghi "có thay đổi, tự vào tủ hồ sơ chung (Cassandra) mà xem". Trung tâm không cần liên tục hỏi "có gì mới không?".
XMPP = Bộ đàm (walkie-talkie) giữa trung tâm điều phối và từng tài xế (vRouter). Hai chiều, real-time. Trung tâm đẩy lệnh xuống; tài xế báo cáo vị trí lên.
BGP = Đường dây điện thoại với bưu cục bên ngoài (gateway router, DC khác). Chuẩn hóa, có thể nói chuyện với bất kỳ ai dùng cùng chuẩn BGP.
Sandesh = Hộp thư đen + hệ thống giám sát: mọi bộ phận liên tục gửi trạng thái về phòng báo cáo (Analytics Node).
8.1 RabbitMQ + Cassandra — Từ Config đến Control
Từ Contrail Controller 4.0, Config Node không còn dùng IF-MAP để đẩy config xuống Control Node nữa — thay vào đó là cặp RabbitMQ (kênh thông báo thay đổi) + Cassandra (kho lưu object thật). Config API Server ghi mọi object vào Cassandra, đồng thời publish một message thông báo lên RabbitMQ mỗi khi có thay đổi. Control Node subscribe RabbitMQ, nhận thông báo, rồi tùy loại thao tác mà xử lý khác nhau:
Config API Server Control Node
│ │
│──── RabbitMQ: "CREATE obj X" ─────►│ (kèm luôn toàn bộ nội dung object,
│ │ không cần đọc thêm Cassandra)
│ │
│──── RabbitMQ: "UPDATE obj X" ─────►│ (chỉ báo ID + loại thay đổi)
│ │
│ ├──► đọc lại object X mới nhất
│ │ trực tiếp từ Cassandra
│ │
│──── RabbitMQ: "DELETE obj X" ─────►│ (kèm ID object bị xóa)
Với CREATE/DELETE, message trên RabbitMQ đã mang đủ nội dung nên Control Node xử lý ngay không cần hỏi thêm. Chỉ riêng UPDATE mới cần thêm một bước đọc Cassandra để lấy phiên bản mới nhất của object — vì message UPDATE cố tình không mang theo toàn bộ nội dung (tránh payload quá lớn khi object phức tạp).
8.2 XMPP — Backbone giữa Control và vRouter
XMPP (Extensible Messaging and Presence Protocol) là giao thức XML-based, gốc từ instant messaging (Jabber), được Contrail tái dụng.
Tại sao XMPP?
- Đã có pub/sub mechanism sẵn.
- Extensible: thêm schema mới không cần thay đổi giao thức.
- Real-time: push model, không polling.
XMPP trong Contrail kết hợp 2 chức năng của MPLS VPN:
| Chức năng | Trong MPLS VPN | Trong Contrail |
|---|---|---|
| Route distribution | IBGP (PE ↔ RR) | XMPP (vRouter ↔ Control Node) |
| Config push | DMI / NETCONF | XMPP (routing instance, policy) |
Hai hướng XMPP:
Control Node ──► vRouter Agent (push):
• Route updates (new VM comes up)
• Routing instance config
• Security policy updates
vRouter Agent ──► Control Node (push):
• Route advertisements (local VM routes)
• Proxy requests (ARP resolution)
• Statistics and events
8.3 BGP — Kết nối với thế giới vật lý
BGP được dùng cho:
1. Inter-control-node synchronization:
Control-Node-1 ──── IBGP ────► Control-Node-2
(full mesh or RR topology)
Mỗi control node có toàn bộ state. IBGP sync state giữa chúng.
2. Gateway router integration:
Control Node ──── BGP (L3VPN AF) ────► MX Gateway Router
──── NETCONF ────────────►
BGP mang route, còn NETCONF (Network Configuration Protocol — giao thức chuẩn để push config lên thiết bị mạng qua XML, thay cho việc gõ tay CLI) lo phần cấu hình còn lại trên gateway router (tạo routing instance, policy...). Gateway router import/export routes từ/đến physical L3VPN.
8.4 Sandesh — Internal Telemetry Protocol
| Thuộc tính | Giá trị |
|---|---|
| Format | XML |
| Direction | Bidirectional (async + sync) |
| Used for | Logs, events, traces, operational state queries |
| Endpoints | Every component → Analytics Node |
| Storage | NoSQL database (time-series optimized) |
Đã hiểu cách các thành phần giao tiếp với nhau qua protocol — giờ đến câu hỏi vận hành: điều gì xảy ra khi 1 node chết? Và dữ liệu cấu hình được tổ chức ra sao bên dưới? Phần tiếp theo bàn về High Availability và Data Model — nền tảng giúp Contrail scale và tự phục hồi.
Nguồn tham khảo
- IF-MAP Server đã bị deprecated từ Contrail Controller 4.0; cơ chế thay thế là Config API Server ghi object vào Cassandra và publish notification qua RabbitMQ (exchange
vnc_config.object-update) — message CREATE/DELETE mang theo toàn bộ nội dung object, message UPDATE chỉ báo ID rồi Control Node tự đọc lại object mới nhất từ Cassandra — tf-specs: Control-node gets configuration from Cassandra; Juniper Contrail 4.0 Release Notes, truy cập 08/2026