4. Forwarding Plane — Overlay Encapsulation & Multicast
Mục lục
- Section 5 — Forwarding Plane: Overlay Encapsulation
- Section 6 — L2 Overlay, Fallback Switching và Multicast
Section 5 — Forwarding Plane: Overlay Encapsulation
Mental Model
Hãy nghĩ về việc gửi kiện hàng quốc tế.
Kiện hàng gốc của bạn = inner packet (VM traffic).
Bạn phải đóng kiện hàng này vào một hộp lớn hơn (outer packet) để gửi qua mạng lưới chuyển phát quốc tế (underlay). Hộp lớn có địa chỉ của server đích (outer IP). Bên trong còn có mã bưu kiện đặc biệt (MPLS label hoặc VNI) để khi đến nơi, nhân viên biết phải giao cho ai.
Các loại "hộp" khác nhau (MPLSoGRE, VXLAN, MPLSoUDP) có ưu/nhược điểm khác nhau.
Tại sao cần Overlay?
Underlay switches trong data center không biết gì về VM hay tenant. Chúng chỉ biết forward IP giữa các server vật lý.
Overlay cho phép:
- Gói VM traffic (inner) vào IP packet (outer) mà underlay hiểu.
- Mỗi VM packet được "vận chuyển" từ server này sang server khác.
- Khi đến đích, bỏ outer header ra để lấy VM traffic gốc.
5.1 Ba Loại Encapsulation — So sánh chi tiết
MPLS over GRE (MPLSoGRE)
Packet format:
┌──────────┬─────────────────┬─────┬──────┬────────────────────┐
│ Ethernet │ Outer IP │ GRE │ MPLS │ Inner Packet │
│ header │ src=Compute1 │ │label │ (VM traffic L3-L7) │
│ │ dst=Compute2 │ │ │ │
└──────────┴─────────────────┴─────┴──────┴────────────────────┘
Giải thích từng field:
Outer IP dst = Compute2: Underlay dùng field này để route đến đúng server.GRE: Header đơn giản, báo "bên trong có MPLS".MPLS label: Locally allocated bởi vRouter Compute2 cho routing instance đích. Compute2 dùng label này để biết VM nào nhận packet.Inner packet: Traffic gốc của VM.
Ưu điểm:
- Đơn giản, được hỗ trợ rộng rãi.
- Không cần gì đặc biệt trên underlay ngoài IP forwarding.
Nhược điểm:
- GRE header không có entropy → ECMP load balancing kém.
- Tất cả packet của một flow có cùng outer IP src/dst → underlay hash cùng path → không tận dụng được multiple paths.
VXLAN
Packet format:
┌──────────┬──────────┬──────────────┬─────────┬────────────────────┐
│ Ethernet │ Outer IP │ UDP │ VXLAN │ Inner Ethernet │
│ header │src=Comp1 │sport=hash() │ VNI │ frame (L2-L7) │
│ │dst=Comp2 │dport=4789 │(24 bits)│ │
└──────────┴──────────┴──────────────┴─────────┴────────────────────┘
Key insight — source port = entropy:
Trước khi vào chi tiết, cần nắm 2 khái niệm sẽ dùng xuyên suốt phần so sánh này:
- ECMP (Equal-Cost Multi-Path): khi có nhiều đường đi cùng chi phí (cost) đến một đích, switch/router chia traffic ra nhiều đường thay vì chỉ dùng một, tận dụng hết băng thông thay vì để phần lớn link rảnh rỗi.
- Entropy: trong ngữ cảnh ECMP, entropy là "độ đa dạng" của giá trị mà switch dùng để hash và chọn đường — hash trên càng nhiều giá trị khác nhau giữa các flow (source port, ví dụ) thì switch càng phân đều được traffic ra nhiều path; hash trên giá trị cố định (như outer IP giống nhau ở mọi flow) thì mọi flow đi chung một đường, ECMP vô dụng.
UDP source port = hash(inner src IP, inner dst IP, inner src port, inner dst port)
Mỗi flow có hash khác nhau → source port khác nhau → underlay ECMP có thể phân tải các flow ra các path khác nhau.
Contrail VXLAN khác IETF VXLAN standard như thế nào:
- Không dùng flood-and-learn (dùng XMPP control plane để phân phối MAC/route thay vì học qua flooding).
- VNI được gán theo từng Virtual Network và nhất quán trên toàn mạng (không phải flood-and-learn tự học như VXLAN thuần) — khác với MPLS label trong MPLSoGRE/MPLSoUDP, vốn mới thực sự là "locally significant" (mỗi vRouter tự cấp phát label cục bộ, không cần coordinate).
- Không cần multicast group trong underlay cho traffic unicast — vẫn cần cân nhắc riêng cho BUM traffic (xem Section 6).
Ưu điểm: ECMP tốt, hỗ trợ L2 overlay. Nhược điểm: Chỉ dùng cho L2 overlay (Ethernet frame), không native cho L3-only.
MPLS over UDP (MPLSoUDP) — Recommended
Packet format:
┌──────────┬──────────┬──────────────┬──────┬────────────────────┐
│ Ethernet │ Outer IP │ UDP │ MPLS │ Inner Packet │
│ header │src=Comp1 │sport=hash() │label │ (L2 or L3) │
│ │dst=Comp2 │dport=51234 │ │ │
└──────────┴──────────┴──────────────┴──────┴────────────────────┘
Đây là sự kết hợp tốt nhất:
- MPLS label (từ MPLSoGRE): locally significant, hỗ trợ cả L2 và L3, không cần coordinate.
- UDP outer với entropy (từ VXLAN): ECMP tốt trên underlay.
Tại sao không dùng MPLS over MPLS (như MPLS VPN truyền thống)?
- Data center switches thường không hỗ trợ MPLS label switching.
- Ngay cả khi hỗ trợ, operator không muốn thêm độ phức tạp.
- Data center bandwidth được overprovision → không cần traffic engineering.
So sánh ba loại encapsulation
| Tiêu chí | MPLSoGRE | VXLAN | MPLSoUDP |
|---|---|---|---|
| ECMP/multipath | ❌ Kém (no entropy) | ✓ Tốt (UDP src port) | ✓ Tốt (UDP src port) |
| L2 overlay | ✓ | ✓ | ✓ |
| L3 overlay | ✓ | ❌ (Ethernet only) | ✓ |
| Label significance | Local | Global (IETF) / Local (Contrail) | Local |
| Overhead (bytes) | IP(20)+GRE(4)+MPLS(4) = 28 | IP(20)+UDP(8)+VXLAN(8) = 36 | IP(20)+UDP(8)+MPLS(4) = 32 |
| Underlay requirement | IP forwarding only | IP forwarding only | IP forwarding only |
| Multicast in underlay | Không cần | Không cần (Contrail) | Không cần |
| Khuyến nghị | Legacy | L2-focused deployment | Modern deployment |
5.2 L3 Unicast Forwarding — Packet Walk chi tiết
Scenario: VM1a (10.1.1.3, trên Compute1) gửi HTTP request đến VM2a (10.1.1.5, trên Compute2).
BƯỚC 1: VM1a gửi packet
━━━━━━━━━━━━━━━━━━━━━━━━
VM1a cần gửi packet đến 10.1.1.5.
VM1a có default route → 169.254.1.1 (link-local gateway).
VM1a gửi ARP request cho 169.254.1.1.
BƯỚC 2: ARP Proxy
━━━━━━━━━━━━━━━━━
Kernel vRouter intercept ARP request.
Punt lên vRouter Agent.
Agent trả lời ARP với MAC của vRouter (không flood).
VM1a học được MAC → gửi IP packet qua vRouter.
BƯỚC 3: Vào vRouter Forwarding Plane
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Packet từ VM1a → virtual interface (vif3) → gán vào routing instance VN-A.
BƯỚC 4: Flow Table lookup
━━━━━━━━━━━━━━━━━━━━━━━━
Flow [src=10.1.1.3, dst=10.1.1.5, proto=TCP, sport=X, dport=80]
→ Không có entry (first packet)
→ PUNT lên Agent
BƯỚC 5: Agent quyết định policy
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Agent kiểm tra security group rules, network policy.
Giả sử allow.
Agent cài flow entry: "forward, không NAT".
Agent re-inject packet vào kernel.
BƯỚC 6: FIB lookup trong routing instance VN-A
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Destination: 10.1.1.5/32
FIB entry: next-hop = Tunnel(dst=Compute2-IP, MPLS-label=51)
BƯỚC 7: Encapsulate (MPLSoUDP ví dụ)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Trước encap:
[TCP][IP: src=10.1.1.3, dst=10.1.1.5]
Sau encap:
[Ethernet outer]
[IP: src=Compute1(192.168.1.10), dst=Compute2(192.168.1.20)]
[UDP: src=hash(inner), dst=51234]
[MPLS: label=51, TTL=64]
[IP: src=10.1.1.3, dst=10.1.1.5]
[TCP: sport=X, dport=80]
BƯỚC 8: Global IP FIB lookup
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Outer dst = 192.168.1.20 (Compute2)
FIB entry: via ToR switch (next-hop MAC = ToR's MAC)
→ Gửi ra physical NIC
BƯỚC 9: Underlay transport
━━━━━━━━━━━━━━━━━━━━━━━━━
Packet đi qua ToR → Spine → ToR2 (L3 routed hoặc L2 switched)
Underlay chỉ thấy outer IP, không biết bên trong là gì.
BƯỚC 10: Compute2 nhận packet
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Outer IP dst = Compute2 → local → decap UDP/IP outer
MPLS label = 51 → MPLS FIB lookup → routing instance VN-A trên Compute2
Decap MPLS → inner IP packet lộ ra
BƯỚC 11: Routing instance lookup trên Compute2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Inner dst = 10.1.1.5 → IP FIB VN-A → local vif (VM2a's interface)
→ Deliver packet đến VM2a
Verification Commands
# === Trên Compute1 (source) ===
# Xem routing instance của VN-A (giả sử vrf-id=2)
rt --dump 2
# Output: 10.1.1.5/32 → NH:34 (label 51)
# Xem next-hop 34
nh --get 34
# Output: Type:Tunnel, MPLSoUDP, Sip:192.168.1.10, Dip:192.168.1.20
# Xem flow entry sau khi có traffic
flow -l | grep "10.1.1.3.*10.1.1.5"
# === Trên Compute2 (destination) ===
# Xem MPLS label 51
mpls --get 51
# Output: NH:64 (routing instance VN-A)
# Xem NH 64
nh --get 64
# Output: Type:Encap, Oif:7 (VM2a's vif)
# Xem virtual interface 7
vif --get 7
# Output: Type:Virtual, IPaddr:10.1.1.5, VMname:vm2a
Section 6 — L2 Overlay, Fallback Switching và Multicast
Mental Model
L3 overlay = như gửi thư có địa chỉ IP rõ ràng — bưu điện chỉ cần biết địa chỉ IP để giao.
L2 overlay = như gửi thư trong cùng khu phố — cần biết số nhà (MAC address), không cần biết phố (IP route).
Fallback Switching = nhân viên bưu điện thông minh: thử địa chỉ IP trước, nếu không có thì tìm theo số nhà.
6.1 L2 Unicast
Forwarding hoàn toàn giống L3 nhưng FIB chứa MAC address thay vì IP prefix.
| Điểm khác biệt | L3 Overlay | L2 Overlay |
|---|---|---|
| FIB key | IP prefix (/32 hoặc /24) | MAC address |
| ARP | Proxy (agent trả lời) | Không dùng trong overlay |
| Sử dụng ARP ở đâu | Underlay (giữa servers) | Underlay (giữa servers) |
| Tunneling | MPLSoGRE/UDP hoặc VXLAN | Tương tự |
| Flooding | Không (control plane) | Không (control plane) |
Quan trọng: Contrail không flood-and-learn cho cả L2 và L3. MAC table được điền bằng control plane (XMPP từ Control Node). Nếu destination MAC không biết → drop (không flood).
6.2 Fallback Switching — Hybrid Mode
Routing instance có cả IP FIB lẫn MAC FIB. Lookup order:
Packet đến (từ VM)
│
▼
Step 1: Lookup IP FIB
├── Found → Forward theo IP route (L3 path)
└── Not found
│
▼
Step 2: Lookup MAC FIB (Fallback)
├── Found → Forward theo MAC (L2 path)
└── Not found → Drop
Fallback Switching vs IRB (Integrated Routing and Bridging):
| Fallback Switching | IRB (truyền thống) | |
|---|---|---|
| Lookup order | Route first → Bridge second | Bridge first → Route second |
| Ưu tiên | L3 routing | L2 bridging |
| Use case | Hybrid overlay với L3 dominance | Traditional campus/DC L2 network |
Mental model cho Multicast: Unicast = gửi thư cho một người, một bản sao. Multicast = phát thanh radio, một nguồn nhiều người nghe. Vấn đề: làm thế nào để radio reach được nhiều người nghe mà không phải gửi N bản riêng lẻ (bandwidth lãng phí) hay yêu cầu cơ sở hạ tầng đặc biệt? Contrail đề xuất hai cách giải quyết: dùng chính các vRouter làm điểm replication (overlay tree), hoặc dùng multicast của underlay network (underlay tree).
6.3 Overlay Multicast Trees
vRouter tại nguồn (root) không gửi N copies đến tất cả listener. Thay vào đó, nó tạo cây phân phối — gửi N copies đến N vRouter "trung gian", mỗi trung gian lại gửi tiếp đến các nhánh của mình.
vRouter-Source
/ | \
/ | \
vRouter-A vRouter-B vRouter-C
/ \ | / \
VM1 VM2 VM3 VM4 VM5
Số lượng nhánh N không cần giống nhau ở mọi cấp. Signaling qua XMPP để program các FIB entry.
Ingress Replication (trường hợp đặc biệt):
vRouter-Source
/ | | \
/ | | \
vRouter-A VR-B VR-C VR-D (N direct copies)
│ │ │ │
VM1 VM2 VM3 VM4
Source gửi N copies trực tiếp đến từng listener vRouter. Signaling đơn giản hơn nhiều (chỉ cần biết list of listeners), nhưng burden bandwidth gần source.
6.4 Underlay Multicast Trees
Dùng PIM (Protocol Independent Multicast) trong underlay. Mỗi multicast group trong overlay map với một multicast group trong underlay.
Overlay multicast group (tenant A, group 239.1.1.1)
→ maps to →
Underlay multicast group (e.g., 239.255.1.1)
→ implemented by →
Physical switches/routers running PIM
6.5 So sánh Overlay vs Underlay Multicast
| Tiêu chí | Overlay Tree | Underlay Tree |
|---|---|---|
| Underlay requirement | Unicast IP only | IP Multicast + PIM |
| Number of groups | Không giới hạn | Bị giới hạn bởi hardware TCAM |
| CPU burden | vRouter (software) | Hardware switches |
| Control plane state | Control Node quản lý | PIM state trên mỗi switch |
| Bandwidth near source | Có thể duplicate traffic | Không duplicate |
| Complexity | Thấp | Cao (PIM config) |
| Contrail preference | ✓ Ưu tiên | Fallback nếu cần |
Tại sao Contrail ưu tiên overlay multicast?
- Merchant silicon switches có giới hạn multicast group TCAM (Ternary Content-Addressable Memory — vùng nhớ tốc độ cao chuyên dùng để lookup trong switch/router, đắt và có dung lượng nhỏ hơn nhiều so với RAM thường) nhỏ.
- Operator không muốn chạy PIM trong data center (phức tạp, khó debug).
- Với Clos fabric (kiến trúc mạng nhiều tầng spine-leaf, thiết kế để có băng thông "full non-blocking" giữa mọi cặp server — phổ biến trong data center hiện đại), duplicate traffic near source ít ảnh hưởng.
6.6 BUM Traffic trong L2
BUM = Broadcast, Unknown unicast, Multicast
| Loại traffic | Contrail xử lý như thế nào | Lý do |
|---|---|---|
| Unknown unicast | Drop | Không có trong control plane → báo hiệu lỗi hệ thống |
| Broadcast (ARP, DHCP) | Proxy tại vRouter Agent | Tránh flooding |
| L2 Broadcast/Multicast còn lại | Tạo distribution tree per VN | Overlay hoặc underlay |
Common Pitfalls
- Nhầm lẫn: Unknown unicast bị drop trong Contrail, không flood. Nếu thấy connectivity issue với VM mới, check xem Control Node đã distribute MAC/route chưa.
- Nhầm lẫn: ARP trong overlay được proxy — VM không thực sự flood ARP. Nếu ARP proxy fail → VM không học được MAC → không gửi được traffic.
Encapsulation giải quyết bài toán forward packet qua overlay — cả unicast lẫn multicast. Nhưng Contrail còn phải điều phối traffic đi qua chuỗi network function (firewall, load balancer...) và đồng bộ toàn bộ các node qua đúng giao thức. Phần tiếp theo đi vào service chaining và các protocol nền tảng: IF-MAP, XMPP, BGP, Sandesh.
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ũ:
- 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
- VXLAN destination port 4789 — xác nhận đúng theo chuẩn IANA/RFC 7348, không thay đổi
- 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 - MPLSoUDP vẫn là encapsulation mặc định/khuyến nghị hiện tại của Contrail (kể cả trên DPDK vRouter và CN2), không có thay đổi sang phương án mới (như Geneve) — Configuring Encapsulation Methods, Contrail Networking 21, truy cập 08/2026
- VNI trong tùy chọn encapsulation "VXLAN" của Contrail được gán theo từng Virtual Network và nhất quán trên toàn mạng, không phải "tự chọn cục bộ ở từng vRouter"; đặc tính "locally significant, không cần coordinate" đúng với MPLS label khi dùng MPLSoGRE/MPLSoUDP, không phải với VNI của VXLAN — EVPN, Juniper/contrail-controller wiki, truy cập 08/2026