PBR – Khi routing table “không còn đủ dùng” nữa

[KhanhHa]

Có một tình huống rất thực tế:
Network của bạn có 2 đường Internet. Routing table đã chạy ổn định, OSPF/BGP đầy đủ. Nhưng sếp lại đưa yêu cầu:

“Traffic từ phòng kế toán phải đi ISP A cho ổn định, còn team dev thì đi ISP B cho nhanh.”

👉 Lúc này, nếu bạn chỉ dựa vào routing table → bó tay.
Và đây chính là lúc Policy-Based Routing (PBR) phát huy sức mạnh.

---

Policy-Based Routing (PBR) là gì?


Hiểu đơn giản:

• Bình thường router sẽ:
  → nhìn vào destination IP
  → tra routing table
  → quyết định next-hop
• Nhưng với PBR:
  → router sẽ match theo policy (ACL, source, protocol…)
  → rồi ép packet đi theo đường do bạn chỉ định

👉 Tức là: bạn “override” logic định tuyến mặc định.

---

Khi nào nên dùng PBR?


Một vài case rất hay gặp ngoài thực tế:

• Điều hướng traffic theo nguồn (source-based routing)
• Chia tải giữa nhiều ISP (không cần load balancing phức tạp)
• Ép traffic quan trọng đi đường low latency
• Bypass routing table cho các luồng đặc biệt

Ví dụ dễ hiểu:

• Máy kế toán (192.168.1.0/24) → đi ISP Viettel
• Máy dev → đi ISP FPT

👉 Routing table không làm được việc này. Nhưng PBR thì làm rất gọn.

---

Cách cấu hình PBR (chuẩn Cisco – dùng được từ CCNA → CCIE)

Bước 1: Tạo ACL để match traffic

 access-list 101 permit ip 192.168.1.0 0.0.0.255 any

Nghĩa là:

• Bắt tất cả traffic từ mạng 192.168.1.0/24

---

Bước 2: Tạo route-map (trái tim của PBR)

route-map PBR permit 10
match ip address 101
set ip next-hop 10.1.1.2

Giải thích theo kiểu “người mới cũng hiểu”:

• match: chọn đúng traffic bạn muốn can thiệp
• set: ép nó đi qua next-hop bạn chỉ định

Tức là:
“Thằng nào match ACL 101 → đi qua 10.1.1.2, không cần hỏi routing table”

---

Bước 3: Apply vào interface

interface GigabitEthernet0/0
ip policy route-map PBR

⚠️ Đây là chỗ nhiều bạn sai nhất:

• PBR chỉ hoạt động khi gắn vào interface inbound
• Không gắn → config coi như “để ngắm”

---

Flow hoạt động thực tế (rất quan trọng nếu bạn học CCNP/CCIE)

1. Packet đi vào interface
2. Router check:
   • Có PBR không?
3. Nếu match:
   → dùng

   set next-hop

4. Nếu không match:
   → quay về routing table bình thường

Key insight: PBR chạy trước routing table

---

Ví dụ thực tế (để dễ hình dung hơn)

Giả sử:

• PC kế toán: 192.168.1.10
• Default route → ISP A
• Nhưng bạn muốn ép nó đi ISP B

Khi bật PBR:

• PC gửi packet
• Router thấy match ACL
• → ép đi next-hop ISP B

👉 Dù routing table vẫn chỉ về ISP A, traffic vẫn bị “bẻ lái”

---

Kiểm tra & debug

Check nhanh:

show route-map
show ip policy

Debug:

debug ip policy

👉 Khi lab, nên bật debug để thấy rõ:

• Packet nào bị match
• Có đi đúng policy không

---

Lưu ý quan trọng (level đi làm + CCIE)

• PBR không scale tốt nếu ACL quá phức tạp
• Dễ làm network khó troubleshoot nếu lạm dụng
• Nếu next-hop bị down → traffic có thể “đi vào hư vô”

👉 Cách xử lý xịn hơn:

set ip next-hop verify-availability

Kết hợp thêm:

• IP SLA
• Tracking

→ để failover thông minh

---

Vậy PBR không phải để thay routing protocol. Nó là công cụ để:

• Control traffic theo business requirement
• Override routing khi cần thiết
• Giải quyết những bài toán “routing table không làm được”

Nhưng dùng PBR cũng giống như “dao mổ”:

• Dùng đúng → cực kỳ lợi hại
• Dùng sai → network rất khó debug

Nếu bạn đang học CCNA/CCNP mà thấy PBR “mơ hồ” thì cứ nhớ 1 câu:

“Routing table quyết định đường đi mặc định,
còn PBR là thứ cho phép mình… cãi lại nó.”