Route Troubleshooting: Destination Matching and Selection
Tại sao Route Troubleshooting Khó
Các quyết định routing thường không rõ ràng. Packet có thể:
- Đi đến sai đích (chọn sai route).
- Không đến được đích (không tìm thấy route).
- Đi theo đường dài hơn (route không tối ưu).
- Bị lệch latency (đường về khác đường đi - asymmetric routing).
GCP áp dụng thuật toán gồm 11 bước (11-step algorithm) kết hợp nhiều yếu tố tiebreaker để chọn route. Hiểu rõ thuật toán này là điều bắt buộc khi debug các sự cố routing.
Cơ chế bên trong: Thuật toán Chọn Route 11 bước
Khi gói tin được gửi tới IP đích, forwarding engine của GCP sẽ đánh giá các route theo thuật toán có cấu trúc sau:
Thuật toán 11 bước
GCP áp dụng các quy tắc theo thứ tự này. Quy tắc đầu tiên chọn ra một route duy nhất sẽ chiến thắng:
Các đường truyền đặc biệt (Special routing paths) (các system route không thể xóa bỏ)
- Các route như
169.254.169.254/32(metadata server). - Không thể xóa, luôn luôn tồn tại.
- Các route như
Policy-based routes (được đánh giá theo priority từ 0-32767)
- Các custom route đi kèm điều kiện (ví dụ: "nếu destination port là 8080, route qua proxy").
- Nếu khớp điều kiện, áp dụng lập tức.
Subnet routes (local, peering, NCC)
- Các route đến các connected subnets.
- Route cụ thể nhất (highest specificity) sẽ chiến thắng.
Khớp Destination cụ thể nhất (Most specific destination matching)
- So sánh CIDR, dải IP nhỏ nhất (cụ thể nhất) sẽ chiến thắng.
- Ví dụ:
10.240.1.0/24ưu tiên hơn10.240.0.0/16.
Chọn loại Custom Route tối ưu nhất (Most favorable custom route type)
- Static custom routes được ưu tiên hơn so với dynamic routes (BGP).
Ưu tiên VPC Network đơn lẻ (Single VPC network preference) (cho các peering routes)
- Nếu có nhiều peering có cùng route, ưu tiên direct peering (peering trực tiếp).
Loại bỏ các Next Hop không khả dụng (Unusable next hops)
- Bỏ qua các route có next-hop đang bị down hoặc unhealthy.
Bỏ các Route có độ ưu tiên thấp (Low priority routes)
- Nếu có nhiều route có cùng độ cụ thể, so sánh priority để chọn.
Chọn VPC Network routing đơn lẻ (Single routing VPC network) (cho NCC)
- Ưu tiên single NCC connector đơn lẻ.
Chọn Danh mục Ưu tiên nhất (Most favorable preference category)
- Ưu tiên các route có metrics tốt hơn.
Quyết định Gửi hoặc Drop (Send or drop decision)
- Nếu không tìm thấy route nào sau tất cả các bước, drop gói tin (destination unreachable).
Khớp Destination (Bước 4)
Đây là bước quan trọng nhất đối với hầu hết các kịch bản thực tế.
Định nghĩa: IP đích của packet có nằm trong dải CIDR của route hay không?
Ví dụ:
IP đích của Packet: 10.240.1.50
Các Route hiện có:
Route A: 10.240.0.0/16
Route B: 10.240.1.0/24
Route C: 10.240.1.32/28
Đánh giá khớp:
- Route A: 10.240.1.50 có nằm trong 10.240.0.0/16? CÓ
- Route B: 10.240.1.50 có nằm trong 10.240.1.0/24? CÓ
- Route C: 10.240.1.50 có nằm trong 10.240.1.32/28? KHÔNG (10.240.1.50 nằm ngoài dải)
Các route khớp: A, B
Cụ thể nhất: Route B (dải 10.240.1.0/24 cụ thể hơn dải 10.240.0.0/16)
Được chọn: Route BQuy tắc CIDR Specificity:
/32là cụ thể nhất,/0là ít cụ thể nhất.- Luôn ưu tiên dải khớp cụ thể nhất.
- Không quan trọng priority của route là bao nhiêu, rule khớp cụ thể nhất (most specific) luôn chiến thắng.
Các loại Route và Next Hops
Các route có thể trỏ đến các next hop khác nhau:
1. Subnet Routes (Do hệ thống tạo)
Trỏ đến các subnet nội bộ trong VPC.
gcloud compute routes list --filter="destination_range=10.0.1.0/24"
# Output:
# destination_range: 10.0.1.0/24
# next_hop_gateway: projects/my-project/global/gateways/default-internet-gateway
# next_hop_type: gateway (hoặc network đối với internal)Hành vi: Traffic gửi đến 10.0.1.0/24 sẽ được chuyển trực tiếp trong nội bộ VPC.
2. Peering Routes (Do hệ thống tạo)
Trỏ đến các peered VPC.
# Peering route được tự động tạo
# destination_range: 10.1.0.0/16 (từ peer VPC)
# next_hop_peering: projects/peer-project/global/networks/peer-network
# next_hop_type: peeringHành vi: Traffic gửi đến 10.1.0.0/16 được forward qua cổng peering.
3. Custom Routes
Do Administrator tự tạo, trỏ đến nhiều đích khác nhau.
Static Custom Routes
Chỉ định trực tiếp next hop:
# Định tuyến ra internet qua NAT gateway
gcloud compute routes create route-to-nat \
--destination-range=0.0.0.0/0 \
--next-hop-instance=nat-instance \
--next-hop-instance-zone=us-central1-aDynamic Custom Routes (BGP)
Được tạo tự động thông qua Cloud Router, nhận dạng từ on-premises qua Cloud Interconnect hoặc Cloud VPN.
gcloud compute routers create my-router \
--asn=65000 \
--network=my-network \
--region=us-central1
# BGP quảng bá các route một cách tự độngECMP: Equal-Cost Multipath Routing
Khi có nhiều route có cùng destination CIDR và cùng priority, GCP sẽ áp dụng cơ chế ECMP để cân bằng tải traffic:
Các Route:
Route A: dest=10.1.0.0/16, next_hop=instance-1
Route B: dest=10.1.0.0/16, next_hop=instance-2
Route C: dest=10.1.0.0/16, next_hop=instance-3
Cả ba route đều có cùng độ cụ thể và cùng priority.
→ ECMP được áp dụng, traffic được phân phối đều cho cả ba instance.Cân bằng tải ECMP
GCP sử dụng cơ chế hash-based balancing để phân phối traffic:
- 5-tuple hash (source IP, dest IP, source port, dest port, protocol)
- Mặc định, đảm bảo các packet trong cùng kết nối đi đến cùng một backend.
- 3-tuple hash (source IP, dest IP, protocol)
- Sử dụng khi không có thông tin port.
Hệ quả: Toàn bộ packet trong cùng một connection (cùng 5-tuple) sẽ đi qua cùng một next-hop. Các connection khác nhau có thể được phân phối sang các hop khác nhau.
Debug:
# Kiểm tra xem có nhiều route cho cùng một đích hay không
gcloud compute routes list --filter="destination_range=10.1.0.0/16"
# Nếu có nhiều route, traffic sẽ được phân phối qua ECMP
# Nếu phân phối không đều, có thể do đụng độ hash (hash collision) hoặc cấu hình saiĐộ ưu tiên của Route (Route Priority)
Khi có nhiều route khác nhau về độ cụ thể hoặc kiểu next-hop, priority sẽ quyết định:
gcloud compute routes create my-route \
--destination-range=0.0.0.0/0 \
--next-hop-instance=instance-1 \
--priority=1000Số priority nhỏ hơn = độ ưu tiên cao hơn (ngược nhưng đồng nhất với cơ chế của firewall rules).
Priority mặc định: 1000. Custom: 0-65535.
Giải quyết xung đột (Conflict Resolution):
Route A: dest=10.0.0.0/8, priority=100
Route B: dest=10.0.1.0/16, priority=1000
Packet gửi tới 10.0.1.50:
- Route B cụ thể hơn (Route A bao phủ dải IP rộng hơn)
- → Route B được chọn
- (Priority bị bỏ qua vì độ cụ thể của destination wins)Policy-Based Routes
Cấu hình nâng cao: Định tuyến dựa trên các điều kiện ngoài IP đích.
gcloud compute network-policies rules create \
--source-range=10.0.0.0/8 \
--destination-range=10.1.0.0/16 \
--destination-port=8080 \
--next-hop-ilb=10.2.0.10 \
--priority=100Các trường hợp sử dụng:
- Định tuyến các port cụ thể (ví dụ: port 8080) đi qua proxy.
- Định tuyến traffic từ các dải IP nguồn cụ thể tới các next-hop khác nhau.
- Các kỹ thuật điều phối traffic nâng cao (traffic engineering).
Thứ tự ưu tiên: Policy-based routes được đánh giá rất sớm (bước 2), do đó có độ ưu tiên cao hơn các route thông thường.
Các lỗi Routing thường gặp khi Debug
Trường hợp 1: Gửi nhầm đích (Traffic Goes to Wrong Destination)
Triệu chứng: Packet đi đến một VM không mong muốn.
Ví dụ:
Subnet 1: 10.0.1.0/24
Subnet 2: 10.0.1.0/24 ← Trùng dải CIDR (xung đột dải IP!)
Các Route:
Route A: dest=10.0.1.0/24, next_hop=gateway (local)
Route B: dest=10.0.1.0/24, next_hop=peering (tới VPC khác)Kết quả: ECMP sẽ chia đều traffic, packet có thể đi đến một trong hai subnet.
Cách sửa: Sử dụng các route cụ thể hơn:
gcloud compute routes create fix-subnet-1 \
--destination-range=10.0.1.0/25 \
--next-hop-gateway=default-internet-gateway
gcloud compute routes create fix-subnet-2 \
--destination-range=10.0.1.128/25 \
--next-hop-peering=...Trường hợp 2: Không tìm thấy Route (No Route Found)
Triệu chứng: Connectivity Tests báo unreachable, Flow Logs báo drop packet.
Debug:
# Kiểm tra các route dẫn đến đích
gcloud compute routes list \
--filter="destination_range>=10.1.0.0 AND destination_range<=10.1.255.255"
# Nếu thiếu route, hãy tiến hành tạo mới
gcloud compute routes create route-to-dest \
--destination-range=10.1.0.0/16 \
--next-hop-peering=peer-networkTrường hợp 3: Latency cao hơn mong đợi
Triệu chứng: Latency cao bất chấp khoảng cách kết nối ngắn.
Nguyên nhân có thể:
- Traffic đi đường vòng (chọn sai route, mất cân bằng ECMP).
- Định tuyến xuyên vùng (cross-region routing - packet đi vòng qua internet).
- VM ở next-hop bị quá tải.
Debug:
# Kiểm tra thông tin đường truyền
gcloud compute routes describe route-name
# Xem kỹ: destination_range, next_hop_instance, priority
# Nếu là cross-region, kiểm tra xem có direct interconnect hay không
gcloud compute interconnects list
# Nếu là ECMP: kiểm tra phân phối traffic
# Chạy traceroute 10.1.1.1 từ VM nhiều lần
# Sẽ thấy phần lớn đi qua cùng một hop, đôi khi đổi hop khác (ECMP cân bằng)Trường hợp 4: Định tuyến bất đối xứng (Asymmetric Routing)
Traffic chiều A→B đi đường khác so với chiều trả về B→A.
Ví dụ:
A → B: Định tuyến qua direct peering
B → A: Định tuyến vòng qua internet (không có route trả về trực tiếp)
Kết quả: A có thể kết nối tới B, nhưng B không thể kết nối tới A.Debug:
# Kiểm tra route ở cả hai VPC
gcloud compute routes list --filter="destination_range=10.0.1.0/24"
# Cả hai subnet cần có các route phản hồi lẫn nhauCách sửa: Đảm bảo cả hai phía đều có route trỏ đến nhau:
# Trong VPC A
gcloud compute routes create route-to-b \
--destination-range=10.1.0.0/16 \
--next-hop-peering=peer-b
# Trong VPC B
gcloud compute routes create route-to-a \
--destination-range=10.0.0.0/16 \
--next-hop-peering=peer-aGiám sát và Quan sát Route
Liệt kê toàn bộ Route
gcloud compute routes list \
--project=my-project \
--format=table(name,destination_range,next_hop_instance,next_hop_gateway,priority)Kiểm tra Route thực tế trên mỗi Instance
Mặc dù route có tính chất global trong VPC, nhưng instance vẫn có thể bị ghi đè thông qua policy-based routes:
gcloud compute instances describe instance-name \
--zone=us-central1-a \
--format="value(networkInterfaces[].network)"
# Kiểm tra network, sau đó liệt kê các route của network đóGiám sát BGP Routes (Cloud Router)
gcloud compute routers get-status my-router \
--region=us-central1
# Hiển thị status BGP, các route nhận được, và status quảng bá routeĐộ trễ Cập nhật Route (Route Propagation Delay)
Quan trọng: Thay đổi cấu hình route không có tác dụng ngay lập tức. Tài liệu GCP ghi rõ:
Thay đổi cấu hình custom route có thể mất tới 5 phút để cập nhật đến tất cả forwarding engines.
Hệ quả:
- Khi tạo hoặc xóa route, có thể gặp trễ lên tới 5 phút.
- Connectivity Tests có thể không phản ánh thay đổi ngay lập tức.
- Traffic thực tế có thể đi theo các đường khác nhau trên mỗi instance trong thời gian cập nhật.
Giải pháp giảm thiểu:
- Lên kế hoạch thay đổi route vào giờ thấp điểm (off-peak).
- Xác thực việc cập nhật bằng lệnh
gcloud compute routes listliên tục. - Kiểm tra kết nối sau 5 phút kể từ khi đổi cấu hình.
Best Practices
1. Sử dụng các Route cụ thể nhất làm chính sách
# TỐT: Sử dụng route cụ thể cho các đích quan trọng
gcloud compute routes create critical-app-route \
--destination-range=10.1.1.0/25 \
--next-hop-instance=critical-app \
--priority=100
gcloud compute routes create default-route \
--destination-range=0.0.0.0/0 \
--next-hop-gateway=default-internet-gateway \
--priority=10002. Tránh cấu hình đè dải IP đích (Overlapping Destination Ranges)
# XẤU: Các dải IP chồng chéo lên nhau
Route A: 10.0.0.0/8
Route B: 10.0.1.0/16
# TỐT: Các dải IP phân tách rõ ràng
Route A: 10.0.0.0/9
Route B: 10.0.128.0/93. Mô tả rõ mục đích sử dụng của Route
gcloud compute routes create my-app-internet \
--destination-range=0.0.0.0/0 \
--next-hop-gateway=default-internet-gateway \
--description="Default route to internet for my-app instances"4. Xác thực Route trước khi áp dụng lên Production
# Trước khi triển khai route mới:
gcloud compute network-management connectivity-tests create route-validation \
--source-instance=... \
--destination-instance=... \
--async5. Sử dụng Cloud Router cho Dynamic Routing
Đối với kết nối on-premises, hãy sử dụng Cloud Router:
gcloud compute routers create my-router \
--network=my-network \
--asn=65000 \
--region=us-central1