7. Use Cases, So sánh MPLS VPN & End-to-End Walkthrough

Mục lục

• Section 11 — Use Cases quan trọng
  • 11.1 Multi-Tenant Virtualized Data Center
  • 11.2 Connect Tenant to Internet/VPN
  • 11.3 Data Center Interconnect (DCI)
  • 11.4 NFV — Service Provider Networks
• Section 12 — So sánh với MPLS VPN
• Section 13 — End-to-End System Walkthrough

---

Section 11 — Use Cases quan trọng

11.1 Multi-Tenant Virtualized Data Center

Vấn đề cần giải quyết:

Requirement	VLAN (cũ)	Contrail Overlay
Số tenant tối đa	4096	Hàng triệu (MPLS label + Route Target, không giới hạn 24-bit)
IP overlap giữa tenants	Không thể	✓ (VRF isolation)
Tự động provisioning	Khó	✓ API-driven
VM mobility	Phức tạp	✓ (route update only)

Two deployment models:

Multi-tier DC network:
  VM ─► ToR ─► Aggregation ─► Core ─► Gateway

Single-tier DC network (Clos Fabric):
  VM ─► ToR ─► Spine ─► ToR ─► VM
  (Juniper QFabric, Leaf-Spine)

Contrail hoạt động tốt với cả hai. Với overlay solution, underlay nên là L3 network (IP) thay vì L2 — scale tốt hơn, không phụ thuộc spanning tree.

11.2 Connect Tenant to Internet/VPN

┌──────────────────────────────────────────────────────┐
│               Data Center                            │
│                                                      │
│  Tenant A VMs ──► vRouter ──► Gateway Router ──►Internet│
│                                     │                │
│  Tenant B VMs ──► vRouter ──► Gateway Router ──►VPN  │
│                                                      │
└──────────────────────────────────────────────────────┘

Gateway Router:
  - BGP session với Control Node (nhận routes của VMs)
  - BGP session với Internet/VPN provider
  - Export VM routes ra ngoài; import external routes vào

Gateway function có thể là:

• Physical router (MX Series) — cần BGP + NETCONF với Control Node.
• Virtual router (VM) — hoạt động như vRouter bình thường.

11.3 Data Center Interconnect (DCI)

DC1 (Hà Nội)                      DC2 (Hồ Chí Minh)
  Tenant A: VMs 10.1.1.0/24  ◄──────────►  Tenant A: VMs 10.1.1.0/24
  vRouter ─► DC Gateway ──── WAN ────── DC Gateway ◄── vRouter
               BGP ◄──────────────────────► BGP

VM của cùng một tenant trên hai DC khác nhau nhìn nhau như cùng VN. Contrail đặt tất cả vào cùng routing instance (cùng route target).

DCI challenges:

• IP overlap: Contrail handle bằng VRF isolation.
• Bandwidth: WAN băng hẹp → traffic engineering.
• VM migration: Khi VM di chuyển từ DC1 sang DC2, route update truyền qua BGP.

11.4 NFV — Service Provider Networks

Virtual CPE (vCPE)

Truyền thống:

Subscriber → [CPE device vật lý] → BNG → Internet
CPE device: router vật lý tại nhà khách hàng
BNG (Broadband Network Gateway): thiết bị của nhà mạng, nơi tập trung
  kết nối thuê bao, xử lý authentication, gán IP, áp policy băng thông

vCPE với Contrail:

Subscriber → [đơn giản hóa CPE, chỉ L2/L3 basic] → BNG
                                                      │
                                                      ▼
                                               [vCPE VM trong DC]
                                               (firewall, NAT, QoS,
                                                parental control...)
                                                      │
                                                      ▼
                                                   Internet

Contrail orchestrate vCPE VMs, tạo service chain per subscriber.

---

Section 12 — So sánh với MPLS VPN

Mental Model

Contrail là "MPLS VPN được phần mềm hóa".

Trong MPLS VPN truyền thống: PE router là phần cứng đắt tiền của Juniper/Cisco, chạy BGP với nhau qua Route Reflector, nhận config từ NMS thủ công.

Trong Contrail: vRouter chính là PE router — nhưng chạy trên Linux kernel của bất kỳ server x86 nào. Control Node là Route Reflector. Config Node là NMS được tự động hóa hoàn toàn. Underlay switches (chỉ cần IP forwarding) thay thế P router MPLS.

Nói cách khác: Contrail lấy toàn bộ kiến trúc MPLS VPN, thay hardware bằng software, thay manual config bằng API, và chạy trong data center thay vì WAN.

Bảng so sánh đầy đủ

Khái niệm MPLS VPN	Tương đương Contrail	Giải thích
P router (Provider Core)	Underlay switches	Chỉ forward outer IP, không biết tenant. Không cần MPLS.
PE router (Provider Edge)	vRouter (per compute node)	Có multiple routing instances, import/export routes.
CE router (Customer Edge)	VM	Endpoint của tenant. Không cần PE-CE routing protocol.
MPLS over MPLS tunnel	MPLSoGRE / MPLSoUDP / VXLAN	Data plane encapsulation. Không cần MPLS trên underlay.
IBGP (PE ↔ PE via RR)	XMPP (vRouter ↔ Control Node)	Route distribution giữa PE/vRouter.
BGP Route Reflector	Control Node	Centralized route distribution.
DMI (Config push to PE)	XMPP (config routing instance)	Push routing instance, policies xuống vRouter.
NMS (Network Mgmt System)	Configuration Node	High-level config và orchestration.
MPLS L3VPN	L3 overlay	Per-tenant routing isolation (VRF).
MPLS EVPN	L2 overlay	Per-tenant L2 bridging domain.

---

Section 13 — End-to-End System Walkthrough

Đây là phần tổng hợp — theo dõi một scenario đầy đủ từ lúc tạo VN đến lúc traffic chạy.

Scenario: Triển khai ứng dụng 2-tier với service chain

Setup cần thiết:

• Tenant "VNG"
• VN "web-tier" (10.1.1.0/24) với 2 web VMs
• VN "app-tier" (10.1.2.0/24) với 2 app VMs
• Service chain: web-tier → Firewall VM → app-tier
• Gateway router kết nối web-tier ra Internet

Phase 1: Infrastructure Setup (Config Node)

Admin tạo objects qua GUI/API:

1. Tạo Tenant "VNG"
   Config Node → Schema Transformer → (no network objects yet)

2. Tạo Project "production"
   Config Node → Schema Transformer → (no network objects yet)

3. Tạo VN "web-tier" (10.1.1.0/24)
   Schema Transformer tạo:
   ├── Route Target: target:65000:100 (auto-generated)
   ├── VNI: 1001 (auto-assigned)
   ├── Routing Instance: ri-web-tier
   │   export: target:65000:100
   │   import: target:65000:100
   └── RabbitMQ notify → Control Node đọc lại từ Cassandra

4. Tạo VN "app-tier" (10.1.2.0/24)
   Schema Transformer tạo:
   ├── Route Target: target:65000:101
   ├── VNI: 1002
   ├── Routing Instance: ri-app-tier
   └── RabbitMQ notify → Control Node đọc lại từ Cassandra

5. Tạo Service Template "firewall-template" (in-network, 3 interfaces)
6. Tạo Service Instance "fw-1" từ template
   Schema Transformer tạo:
   ├── Routing Instance ri-fw-left (ingress VN side)
   ├── Routing Instance ri-fw-right (egress app-tier side)
   └── Route manipulations cho chaining

7. Tạo Network Policy: web-tier → [fw-1] → app-tier
   Schema Transformer cập nhật route targets:
   ├── ri-app-tier export → ri-fw-right import
   ├── ri-fw-right export → ri-fw-left import (next-hop-self)
   └── ri-fw-left export → ri-web-tier import (next-hop-self)

Phase 2: Control Node Propagation

Control Node nhận tất cả low-level objects qua RabbitMQ notify + đọc từ Cassandra:

1. Tạo routing instances locally
2. Setup BGP route target communities
3. Không có gì để advertise yet (chưa có VMs)
4. Chờ vRouter agents connect và advertise VM routes

Phase 3: VM Creation (OpenStack Nova)

Admin tạo VM "web-01" trong VN "web-tier", Compute1:

1. Nova API → scheduler chọn Compute1
2. Nova gọi Contrail Neutron Plugin:
   "Cần port cho web-01 trong web-tier"
3. Config Node: allocate IP 10.1.1.3, MAC aa:bb:cc:01
4. Nova Agent tạo VM "web-01" trên Compute1
5. Nova Agent notify vRouter Agent:
   "VM web-01, tap1, IP=10.1.1.3, VN=web-tier"
6. vRouter Agent:
   a. Tạo vif (virtual interface) cho web-01
   b. Bind vif → routing instance ri-web-tier
   c. Install local route: 10.1.1.3/32 → vif1
   d. Advertise qua XMPP: "10.1.1.3/32 at Compute1, label=50"
7. Control Node nhận advertisement:
   a. Lưu route
   b. Distribute đến tất cả vRouter trong ri-web-tier
   (Hiện tại chưa có VM nào khác, nên không distribute gì)

[Tương tự cho web-02, app-01, app-02, fw-1 VM]

OpenStack components liên quan:

Component	Vai trò trong Contrail integration
Nova	Orchestrate VM lifecycle. Triggers vRouter Agent khi VM created/deleted.
Neutron	Network API. Contrail cung cấp Neutron plugin để nhận requests.
Contrail Neutron Plugin	Translate Neutron API calls → Contrail Config Node REST API calls.
Nova Agent (Compute)	Local agent trên compute server. Notify vRouter Agent về VM changes.

Phase 4: Route Distribution

Sau khi tất cả VMs được tạo:

Control Node:
  web-tier routes: 10.1.1.3/32 (Compute1), 10.1.1.4/32 (Compute2)
  app-tier routes: 10.1.2.3/32 (Compute3), 10.1.2.4/32 (Compute4)
  fw-1: vif-left (Compute5), vif-right (Compute5)

Route leaking (vì có network policy):
  ri-web-tier import: 
    - routes từ ri-fw-left (next-hop = fw-1's left vif, label=X)
    - (để web VMs biết cách đến app-tier: phải đi qua fw)
  
  ri-fw-left import:
    - routes từ ri-fw-right (next-hop-self = fw VM's interface)
    - (để fw VM chuyển traffic sang right side)
    
  ri-app-tier import:
    - routes từ ri-fw-right (direct)
    - (app VMs nhận traffic từ fw)

Kết quả FIB trên Compute1 (có web-01):
  ri-web-tier FIB:
    10.1.1.3/32 → local vif (web-01)
    10.1.1.4/32 → tunnel(Compute2, label=51) [direct same VN]
    10.1.2.3/32 → tunnel(Compute5, label=60) [via fw-1's left vif]
    10.1.2.4/32 → tunnel(Compute5, label=60) [via fw-1's left vif]

Phase 5: Traffic Flow — web-01 → app-01 (với service chain)

web-01 (10.1.1.3) → app-01 (10.1.2.3)

STEP 1: web-01 gửi packet
  src=10.1.1.3, dst=10.1.2.3
  → Default route → vRouter Agent (ARP proxy)
  → vRouter Agent trả lời ARP với vRouter MAC

STEP 2: Packet vào vRouter FWD (Compute1)
  vif1 (web-01) → routing instance ri-web-tier
  Flow table: first packet → punt to agent
  Agent: security group check → allow
  Agent: cài flow entry → forward
  re-inject

STEP 3: FIB lookup ri-web-tier
  dst=10.1.2.3 → next-hop: tunnel(Compute5, MPLS label=60)
  (Compute5 là nơi chạy fw-1 VM)

STEP 4: Encapsulate (MPLSoUDP)
  [Eth][IP:src=Compute1, dst=Compute5][UDP:sport=hash][MPLS:label=60][IP:src=10.1.1.3,dst=10.1.2.3][TCP]

STEP 5: Underlay transport: Compute1 → ToR → Spine → ToR → Compute5

STEP 6: Compute5 nhận
  Outer dst = local → decap UDP/IP
  MPLS label=60 → routing instance ri-fw-left
  Deliver đến fw-1's left vif

STEP 7: Firewall VM xử lý
  Nhận packet: 10.1.1.3 → 10.1.2.3
  Check rules → allow
  Gửi ra right vif của fw-1

STEP 8: Right vif → routing instance ri-fw-right
  FIB: 10.1.2.3 → tunnel(Compute3, label=71) (actual app-01)
  Encapsulate lại
  [Eth][IP:src=Compute5, dst=Compute3][UDP:sport=hash2][MPLS:label=71][IP:src=10.1.1.3,dst=10.1.2.3][TCP]

STEP 9: Underlay: Compute5 → Compute3

STEP 10: Compute3 decap
  MPLS label=71 → routing instance ri-app-tier
  FIB: 10.1.2.3 → local vif (app-01)
  Deliver đến app-01

[Reply: app-01 → web-01, ngược lại, cũng qua fw-1]

Phase 6: Monitoring (Analytics)

Trong suốt quá trình:

vRouter agents gửi qua Sandesh:
  → Flow records (src/dst/bytes/packets)
  → Interface stats (RX/TX per vif)
  → Tunnel events (new tunnel established)
  → Error events (drop reasons)

Control nodes gửi qua Sandesh:
  → BGP state changes
  → Route additions/deletions
  → XMPP session status

Query qua Analytics REST API:
  # Xem all flows qua fw-1
  curl http://analytics:8081/analytics/query -d '{
    "table": "FlowSeriesTable",
    "select": ["sourceip", "destip", "bytes", "packets"],
    "where": [{"name": "vrouter", "value": "compute5"}]
  }'

Đã thấy Contrail vận hành trong một kịch bản đầy đủ — nhưng 2 mảng tính năng quan trọng vẫn chưa nhắc tới: bảo mật/kiểm soát traffic ở tầng tenant, và kết nối tenant ra bên ngoài. Phần tiếp theo đi vào Security Group, Network Policy, Floating IP, SNAT và BGPaaS.

---

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 — tf-specs: Control-node gets configuration from Cassandra; Juniper Contrail 4.0 Release Notes, truy cập 08/2026
• Encapsulation mặc định của Contrail là MPLS-over-GRE/UDP dùng MPLS label 20-bit, không phải VXLAN VNI 24-bit; scale đa tenant thực tế đến từ BGP Route Target chứ không bị giới hạn bởi độ rộng của một trường VNI cố định — VXLAN Encapsulation in Juniper Contrail, truy cập 08/2026