Tweet
Cisco LISP (Locator ID Separation Protocol) – Control Plane Hoạt Động Như Thế Nào?
Ở phần trước, chúng ta đã hiểu tư tưởng cốt lõi của LISP:
tách Identity khỏi Location.
Nhưng chỉ biết ý tưởng thôi chưa đủ.
Câu hỏi thực tế hơn là:
Làm sao router biết một EID đang nằm ở đâu?
Ví dụ:
Host nguồn muốn gửi traffic đến:
192.168.2.102
Làm sao ITR biết rằng endpoint này đang reachable qua:
RLOC 192.168.123.2
Đây chính là vai trò của LISP Control Plane.
Nếu Data Plane chịu trách nhiệm vận chuyển packet, thì Control Plane chịu trách nhiệm tìm đúng đường đi bằng cách phân giải EID thành RLOC.
Có thể hình dung:
Khác biệt là LISP thực hiện việc này ở tầng routing infrastructure thay vì application layer.
Vì sao không dùng routing table truyền thống?
Trong IP routing cổ điển, router chỉ cần lookup FIB.
Ví dụ:
192.168.2.0/24 → next-hop 10.1.1.1
Rất đơn giản.
Nhưng nếu làm như vậy với hàng triệu endpoint, routing table sẽ bùng nổ.
LISP chọn cách khác.
Thay vì:
mọi router đều biết mọi prefix
LISP dùng:
distributed mapping database
Tức là chỉ truy vấn khi cần.
Ý tưởng này giống DNS hơn là routing cổ điển.
Hai quá trình chính của Control Plane
LISP control plane gồm hai workflow chính: 1. Registration workflow
Endpoint prefix phải được đăng ký trước.
Gồm:
2. Resolution workflow
Khi cần gửi traffic:
Nói ngắn:
đăng ký trước, tra cứu khi cần.
Workflow 1 – Map-Register
Hãy bắt đầu từ site đích.
Giả sử Site 2 có:
Host:
192.168.2.102
ETR:
RLOC = 192.168.123.2
ETR cần thông báo cho hệ thống:
Nếu không, không ai biết traffic phải gửi về đâu.
Bước 1: ETR tạo Map-Register
ETR gửi thông điệp:
Map-Register
Thông tin bên trong:
Ví dụ:
EID: 192.168.2.0/24
RLOC: 192.168.123.2
Nghĩa là:
Cổng UDP sử dụng
Map-Register dùng:
UDP 4342
Đây là control-plane signaling port của LISP.
Vai trò của Map Server
Map Server là nơi lưu mapping database.
Ví dụ:
Có thể hiểu Map Server như DNS authoritative server.
Nó giữ thông tin “sự thật” về mapping.
Bước 2: Map-Notify
Khi Map Server nhận Map-Register:
Thông điệp:
Map-Notify
Ý nghĩa:
Điều này tránh ambiguity.
ETR biết registration thành công.
Workflow 2 – Map Resolution
Giờ đến site nguồn.
Host:
192.168.1.101
muốn nói chuyện với:
192.168.2.102
Host không biết gì về LISP.
Nó chỉ gửi IP packet bình thường đến default gateway.
Gateway ở đây là ITR.
Bước 1: ITR nhận packet
Packet:
SRC 192.168.1.101
DST 192.168.2.102
ITR kiểm tra:
Destination có thuộc EID space không?
Nếu có:
lookup mapping.
Local Map Cache
ITR có cache riêng.
Ví dụ:
192.168.2.0/24 → 192.168.123.2
Nếu đã có cache:
encapsulate luôn.
Không cần hỏi ai.
Điều này tăng tốc forwarding.
Nếu cache chưa có?
ITR cần hỏi hệ thống mapping.
Nó gửi:
Map-Request
Vai trò của Map Resolver
ITR không gửi query lung tung.
Nó gửi đến:
MR (Map Resolver)
MR đóng vai trò giống DNS resolver.
Nó nhận query:
Map-Request
Thông điệp chứa:
Ví dụ:
Query:
192.168.2.102
Nếu MR biết mapping?
MR forward query đến đúng ETR hoặc Map Server.
Nếu MR không biết?
MR hỏi hệ thống mapping infrastructure.
Đây là distributed lookup model.
Map-Reply
ETR hoặc authoritative component trả lời:
Map-Reply
Nội dung:
192.168.2.0/24 → 192.168.123.2
Nghĩa là:
ITR cache kết quả
Sau khi nhận reply:
ITR lưu:
local map-cache
Lần sau:
không cần query nữa.
Giống DNS caching.
Negative Map-Reply
Điều gì xảy ra nếu destination không tồn tại?
Ví dụ:
10.99.99.99
Không có mapping.
Hệ thống trả:
Negative Map-Reply
Ý nghĩa:
ITR xử lý theo policy.
Có thể:
Proxy Map-Reply
Trong một số deployment, ETR có thể cho phép:
Proxy Map-Reply
Nghĩa là Map Server thay ETR trả lời.
Lợi ích:
So sánh với DNS
LISP control plane rất giống DNS.
Khác biệt lớn:
DNS dành cho application layer.
LISP dành cho routing infrastructure.
Full Packet Walk (Control Plane)
Hãy ghép toàn bộ lại.
Step 1
ETR đăng ký:
192.168.2.0/24 → 192.168.123.2
với Map Server.
Step 2
Map Server lưu mapping.
Step 3
Map Server gửi:
Map-Notify
Step 4
Host H1 gửi packet đến:
192.168.2.102
Step 5
ITR nhận packet.
Step 6
ITR kiểm tra cache.
Không có entry.
Step 7
ITR gửi:
Map-Request
đến MR.
Step 8
MR resolve query.
Step 9
ETR trả:
Map-Reply
Step 10
ITR lưu cache.
Step 11
ITR sẵn sàng encapsulate traffic.
Điều quan trọng cần nhớ
LISP control plane không flood routing information như IGP/BGP.
Thay vào đó:
on-demand resolution.
Điều này giúp:
Ở phần trước, chúng ta đã hiểu tư tưởng cốt lõi của LISP:
tách Identity khỏi Location.
Nhưng chỉ biết ý tưởng thôi chưa đủ.
Câu hỏi thực tế hơn là:
Làm sao router biết một EID đang nằm ở đâu?
Ví dụ:
Host nguồn muốn gửi traffic đến:
192.168.2.102
Làm sao ITR biết rằng endpoint này đang reachable qua:
RLOC 192.168.123.2
Đây chính là vai trò của LISP Control Plane.
Nếu Data Plane chịu trách nhiệm vận chuyển packet, thì Control Plane chịu trách nhiệm tìm đúng đường đi bằng cách phân giải EID thành RLOC.
Có thể hình dung:
- DNS:
- LISP:
Khác biệt là LISP thực hiện việc này ở tầng routing infrastructure thay vì application layer.
Vì sao không dùng routing table truyền thống?
Trong IP routing cổ điển, router chỉ cần lookup FIB.
Ví dụ:
192.168.2.0/24 → next-hop 10.1.1.1
Rất đơn giản.
Nhưng nếu làm như vậy với hàng triệu endpoint, routing table sẽ bùng nổ.
LISP chọn cách khác.
Thay vì:
mọi router đều biết mọi prefix
LISP dùng:
distributed mapping database
Tức là chỉ truy vấn khi cần.
Ý tưởng này giống DNS hơn là routing cổ điển.
Hai quá trình chính của Control Plane
LISP control plane gồm hai workflow chính: 1. Registration workflow
Endpoint prefix phải được đăng ký trước.
Gồm:
- Map-Register
- Map-Notify
2. Resolution workflow
Khi cần gửi traffic:
- Map-Request
- Map-Reply
Nói ngắn:
đăng ký trước, tra cứu khi cần.
Workflow 1 – Map-Register
Hãy bắt đầu từ site đích.
Giả sử Site 2 có:
Host:
192.168.2.102
ETR:
RLOC = 192.168.123.2
ETR cần thông báo cho hệ thống:
Prefix này nằm sau tôi.
Nếu không, không ai biết traffic phải gửi về đâu.
Bước 1: ETR tạo Map-Register
ETR gửi thông điệp:
Map-Register
Thông tin bên trong:
- EID prefix
- RLOC
- authentication
- attributes
Ví dụ:
EID: 192.168.2.0/24
RLOC: 192.168.123.2
Nghĩa là:
Muốn đến subnet này thì hãy gửi đến tôi.
Cổng UDP sử dụng
Map-Register dùng:
UDP 4342
Đây là control-plane signaling port của LISP.
Vai trò của Map Server
Map Server là nơi lưu mapping database.
Ví dụ:
| 192.168.2.0/24 | 192.168.123.2 |
Nó giữ thông tin “sự thật” về mapping.
Bước 2: Map-Notify
Khi Map Server nhận Map-Register:
- xác thực
- lưu mapping
- phản hồi lại ETR
Thông điệp:
Map-Notify
Ý nghĩa:
Tôi đã nhận registration của bạn.
Điều này tránh ambiguity.
ETR biết registration thành công.
Workflow 2 – Map Resolution
Giờ đến site nguồn.
Host:
192.168.1.101
muốn nói chuyện với:
192.168.2.102
Host không biết gì về LISP.
Nó chỉ gửi IP packet bình thường đến default gateway.
Gateway ở đây là ITR.
Bước 1: ITR nhận packet
Packet:
SRC 192.168.1.101
DST 192.168.2.102
ITR kiểm tra:
Destination có thuộc EID space không?
Nếu có:
lookup mapping.
Local Map Cache
ITR có cache riêng.
Ví dụ:
192.168.2.0/24 → 192.168.123.2
Nếu đã có cache:
encapsulate luôn.
Không cần hỏi ai.
Điều này tăng tốc forwarding.
Nếu cache chưa có?
ITR cần hỏi hệ thống mapping.
Nó gửi:
Map-Request
Vai trò của Map Resolver
ITR không gửi query lung tung.
Nó gửi đến:
MR (Map Resolver)
MR đóng vai trò giống DNS resolver.
Nó nhận query:
Ai đang giữ EID này?
Map-Request
Thông điệp chứa:
- destination EID
- requester information
- nonce
- metadata
Ví dụ:
Query:
192.168.2.102
Nếu MR biết mapping?
MR forward query đến đúng ETR hoặc Map Server.
Nếu MR không biết?
MR hỏi hệ thống mapping infrastructure.
Đây là distributed lookup model.
Map-Reply
ETR hoặc authoritative component trả lời:
Map-Reply
Nội dung:
192.168.2.0/24 → 192.168.123.2
Nghĩa là:
Destination đang reachable qua RLOC này.
ITR cache kết quả
Sau khi nhận reply:
ITR lưu:
local map-cache
Lần sau:
không cần query nữa.
Giống DNS caching.
Negative Map-Reply
Điều gì xảy ra nếu destination không tồn tại?
Ví dụ:
10.99.99.99
Không có mapping.
Hệ thống trả:
Negative Map-Reply
Ý nghĩa:
Tôi không biết prefix này.
ITR xử lý theo policy.
Có thể:
- drop
- fallback
- forward via PETR
Proxy Map-Reply
Trong một số deployment, ETR có thể cho phép:
Proxy Map-Reply
Nghĩa là Map Server thay ETR trả lời.
Lợi ích:
- giảm load
- đơn giản hóa
- tăng scalability
So sánh với DNS
LISP control plane rất giống DNS.
| Hostname | EID |
| IP address | RLOC |
| DNS Server | Map Server |
| DNS Resolver | Map Resolver |
| DNS Query | Map-Request |
| DNS Response | Map-Reply |
| DNS Cache | Map Cache |
DNS dành cho application layer.
LISP dành cho routing infrastructure.
Full Packet Walk (Control Plane)
Hãy ghép toàn bộ lại.
Step 1
ETR đăng ký:
192.168.2.0/24 → 192.168.123.2
với Map Server.
Step 2
Map Server lưu mapping.
Step 3
Map Server gửi:
Map-Notify
Step 4
Host H1 gửi packet đến:
192.168.2.102
Step 5
ITR nhận packet.
Step 6
ITR kiểm tra cache.
Không có entry.
Step 7
ITR gửi:
Map-Request
đến MR.
Step 8
MR resolve query.
Step 9
ETR trả:
Map-Reply
Step 10
ITR lưu cache.
Step 11
ITR sẵn sàng encapsulate traffic.
Điều quan trọng cần nhớ
LISP control plane không flood routing information như IGP/BGP.
Thay vào đó:
on-demand resolution.
Điều này giúp:
- giảm routing table scale
- tăng abstraction
- hỗ trợ mobility
- hỗ trợ segmentation
- tách control khỏi forwarding logic