lOMoARcPSD| 58815430
1. Phân ch yêu cầu để thiết kế hệ thống (2 điểm)
Mục êu chính: Xây dựng một hệ thống mạng có khả năng định tuyến các luồng dữ liệu
một cách linh hoạt dựa trên chính sách (PolicyBased Roung). Cụ thể, đường đi của gói
n sẽ ph thuộc vào việc nó sử dụng giao thức TCP hay UDP ở tầng vận chuyển (Layer 4).
Yêu cầu về Topo mạng: Sơ đồ cho thấy 5 switch được kết nối theo kiểu full-mesh, đảm
bảo mỗi switch có một kết nối trực ếp đến tất cả các switch còn lại, tăng cường khả
năng phục hồi và cung cấp nhiều lựa chọn đường đi.
Phân ch các luồng lưu lượng cụ thể:
1. Luồng 1 (TCP 📜): Tất cả gói n TCP từ mạng 128.119/16 (nối với s1) đến mạng
128.121/16 (nối với s3) phải đưc áp đặt đi theo đường dẫn s1 → s2 → s4 → s3.
2. Luồng 2 (UDP 📬): Tất cả gói n UDP có cùng nguồn và đích như trên phải đưc
áp đặt đi theo đường dẫn khác là s1 → s5 → s4 → s3.
Kết lun: Các yêu cầu trên không thể được đáp ứng bởi cơ chế định tuyến IP truyền
thống (vốn thường chỉ chọn đường đi ngắn nhất, trong trường hợp này có thể là s1 →
s3). Do đó, kiến trúc SDN với Controller trung tâmgiải pháp lý tưởng, cho phép định
nghĩa và thực thi các đường đi tùy chỉnh một cách chính xác.
2. Thiết kế hệ thống (3 điểm)
Hệ thống sẽ được thiết kế dựa trên kiến trúc Mạng định nghĩa bằng phần mềm (SDN) với giao
thức OpenFlow.
Kiến trúc tổng thể:
o Tầng điều khiển (Control Plane): Một SDN Controller trung tâm đóng vai trò là
"bộ não" của mạng. Nó chịu trách nhiệm xử lý logic, nh toán đường đi dựa trên
chính sách và cài đặt các quy tắc (ow rules) xuống các switch.
o Tầng dữ liệu (Data Plane): 5 switch (s1 đến s5) hoạt động như các OpenFlow
switch. Chúng chỉ thực hiện chức năng chuyển ếp gói n với tốc độ cao dựa
trên các quy tắc được lưu trong Bảng luồng (Flow Table) do Controller cung cấp.
Nguyên lý hoạt động (Cơ chế Reacve):
1. Khi gói n đầu ên của một luồng mới đến switch s1, s1 sẽ không m thấy quy
tắc nào khớp (sự kin table-miss).
lOMoARcPSD| 58815430
2. s1 đóng gói thông n góin vào một thông điệp Packet-In và gửi lên Controller
để hỏi cách xử lý.
3. Controller nhận Packet-In, phân ch (ví dụ: thấy đây là luồng TCP cần đi tuyến s1
→ s2 → s4 → s3).
4. Controller gửi các thông điệp Flow-Mod (cài đặt quy tắc) xuống tất cả các switch
trên đường đi đó (s1, s2, s4, s3).
5. Sau khi cài đặt xong, Controller gửi thông điệp Packet-Out để chthị cho s1 xử lý
gói n ban đầu.
6. Các gói n sau này trong cùng luồng sẽ được xử lý ngay tại các switch mà không
cần liên lạc với Controller nữa.
3. Thiết lập các quy tắc chuyển ếp tại Controller (2 điểm)
Đây là mô tả logic chi ếtController sẽ thực hiện khi phát hiện các luồng mới, sử dụng chính
xác các số hiệu cổng trên sơ đồ.
Logic xử lý Luồng 1 (TCP Path: s1 → s2 → s4 → s3)
Khi Controller phát hiện một luồng TCP từ 128.119/16 đến 128.121/16:
Đối với s1: Ra lệnh: "Cài quy tắc: Nếu nhận được gói n TCP từ 128.119/16 đến
128.121/16 tại cổng 5 (từ LAN), hãy chuyển ếp nó ra cổng 1 (hướng đến s2)."
Đối với s2: Ra lệnh: "Cài quy tắc: Nếu nhận được gói n TCP này tại cổng 1 (từ s1), hãy
chuyển ếp nó ra cổng 3 (hướng đến s4)."
Đối với s4: Ra lệnh: "Cài quy tắc: Nếu nhận được gói n TCP này tại cổng 2 (từ s2), hãy
chuyển ếp nó ra cổng 1 (hướng đến s3)."
Đối với s3: Ra lệnh: "Cài quy tắc: Nếu nhận được gói n TCP này tại cổng 4 (từ s4), hãy
chuyển ếp nó ra cổng 5 (vào mạng LAN đích)."
Logic xử lý Luồng 2 (UDP Path: s1 → s5 → s4 → s3)
Khi Controller phát hiện một luồng UDP từ 128.119/16 đến 128.121/16:
Đối với s1: Ra lệnh: "Cài quy tắc: Nếu nhận được gói n UDP từ 128.119/16 đến
128.121/16 tại cổng 5 (từ LAN), hãy chuyển ếp nó ra cổng 4 (hướng đến s5)."
Đối với s5: Ra lệnh: "Cài quy tắc: Nếu nhận được gói n UDP này tại cổng 1 (từ s1), hãy
chuyển ếp nó ra cổng 2 (hướng đến s4)."
lOMoARcPSD| 58815430
Đối với s4: Ra lệnh: "Cài quy tắc: Nếu nhận được gói n UDP này tại cổng 3 (từ s5), hãy
chuyển ếp nó ra cổng 1 (hướng đến s3)."
Đối với s3: Ra lệnh: "Cài quy tắc: Nếu nhận được gói n UDP này tại cổng 4 (từ s4), hãy
chuyển ếp nó ra cổng 5 (vào mạng LAN đích)."
4. Hoàn thành các bảng chuyển ếp (3 điểm)
Đây là kết qucuối cùng (các bảng luồng) trên từng switch sau khi Controller đã cài đặt.
Lưu ý: Để làm ví dụ cụ thể và đáp ứng yêu cầu, chúng ta giả sử luồng TCP là truy cập Web (cổng
đích 80) và luồng UDP là truy vấn DNS (cổng đích 53). Cổng nguồn (sport) là ngẫu nhiên do máy
khách tạo ra, nên chúng ta không cần đưa vào điều kiện match vì nó không cố định.
Bảng chuyển ếp cho Switch s1
Priori
Match (Điều kiện khớp)
ty
Acon (Hành
động)
in_port: 5, ip_proto: TCP, ipv4_src: 128.119/16,
1000 ipv4_dst: 128.121/16, tcp_dport: 80
Forward ra cổng 1
in_port: 5, ip_proto: UDP, ipv4_src: 128.119/16,
1000 ipv4_dst: 128.121/16, udp_dport: 53
Xuất sang Trang nh
Bảng chuyển ếp cho Switch s2
Forward ra cổng 4
Priori
Match (Điều kiện khớp)
ty
Acon (Hành
động)
in_port: 1, ip_proto: TCP, ipv4_src: 128.119/16,
1000 ipv4_dst: 128.121/16, tcp_dport: 80
Forward ra cổng 3
Xuất sang Trang nh
Bảng chuyển ếp cho Switch s5
Priori Acon (Hành
Match (Điều kiện khớp)
ty động)
in_port: 1, ip_proto: UDP, ipv4_src: 128.119/16, Forward ra
lOMoARcPSD| 58815430
1000
ipv4_dst: 128.121/16, udp_dport: 53 cổng 2
Xuất sang Trang nh
Bảng chuyển ếp cho Switch s4
Priori Acon (Hành
Match (Điều kiện khớp)
ty động)
in_port: 2, ip_proto: TCP, ipv4_src: 128.119/16, Forward ra
1000
ipv4_dst: 128.121/16, tcp_dport: 80 cổng 1
in_port: 3, ip_proto: UDP, ipv4_src: 128.119/16, Forward ra
1000
ipv4_dst: 128.121/16, udp_dport: 53 cổng 1
Xuất sang Trang nh
Bảng chuyển ếp cho Switch s3
Priori Acon (Hành
Match (Điều kiện khớp)
ty động)
in_port: 4, ip_proto: TCP, ipv4_src: 128.119/16, Forward ra
1000
ipv4_dst: 128.121/16, tcp_dport: 80 cổng 5
in_port: 4, ip_proto: UDP, ipv4_src: 128.119/16, Forward ra
1000
ipv4_dst: 128.121/16, udp_dport: 53 cổng 5
Xuất sang Trang nh

Preview text:

lOMoAR cPSD| 58815430
1. Phân tích yêu cầu để thiết kế hệ thống (2 điểm)
Mục tiêu chính: Xây dựng một hệ thống mạng có khả năng định tuyến các luồng dữ liệu
một cách linh hoạt dựa trên chính sách (PolicyBased Routing). Cụ thể, đường đi của gói
tin sẽ phụ thuộc vào việc nó sử dụng giao thức TCP hay UDP ở tầng vận chuyển (Layer 4). •
Yêu cầu về Topo mạng: Sơ đồ cho thấy 5 switch được kết nối theo kiểu full-mesh, đảm
bảo mỗi switch có một kết nối trực tiếp đến tất cả các switch còn lại, tăng cường khả
năng phục hồi và cung cấp nhiều lựa chọn đường đi. •
Phân tích các luồng lưu lượng cụ thể:
1. Luồng 1 (TCP 📜): Tất cả gói tin TCP từ mạng 128.119/16 (nối với s1) đến mạng
128.121/16 (nối với s3) phải được áp đặt đi theo đường dẫn s1 → s2 → s4 → s3.
2. Luồng 2 (UDP 📬): Tất cả gói tin UDP có cùng nguồn và đích như trên phải được
áp đặt đi theo đường dẫn khác là s1 → s5 → s4 → s3. •
Kết luận: Các yêu cầu trên không thể được đáp ứng bởi cơ chế định tuyến IP truyền
thống (vốn thường chỉ chọn đường đi ngắn nhất, trong trường hợp này có thể là s1 →
s3). Do đó, kiến trúc SDN với Controller trung tâm là giải pháp lý tưởng, cho phép định
nghĩa và thực thi các đường đi tùy chỉnh một cách chính xác.
2. Thiết kế hệ thống (3 điểm)
Hệ thống sẽ được thiết kế dựa trên kiến trúc Mạng định nghĩa bằng phần mềm (SDN) với giao thức OpenFlow. •
Kiến trúc tổng thể:
o Tầng điều khiển (Control Plane): Một SDN Controller trung tâm đóng vai trò là
"bộ não" của mạng. Nó chịu trách nhiệm xử lý logic, tính toán đường đi dựa trên
chính sách và cài đặt các quy tắc (flow rules) xuống các switch.
o Tầng dữ liệu (Data Plane): 5 switch (s1 đến s5) hoạt động như các OpenFlow
switch. Chúng chỉ thực hiện chức năng chuyển tiếp gói tin với tốc độ cao dựa
trên các quy tắc được lưu trong Bảng luồng (Flow Table) do Controller cung cấp. •
Nguyên lý hoạt động (Cơ chế Reactive):
1. Khi gói tin đầu tiên của một luồng mới đến switch s1, s1 sẽ không tìm thấy quy
tắc nào khớp (sự kiện table-miss). lOMoAR cPSD| 58815430
2. s1 đóng gói thông tin gói tin vào một thông điệp Packet-In và gửi lên Controller để hỏi cách xử lý.
3. Controller nhận Packet-In, phân tích (ví dụ: thấy đây là luồng TCP cần đi tuyến s1 → s2 → s4 → s3).
4. Controller gửi các thông điệp Flow-Mod (cài đặt quy tắc) xuống tất cả các switch
trên đường đi đó (s1, s2, s4, s3).
5. Sau khi cài đặt xong, Controller gửi thông điệp Packet-Out để chỉ thị cho s1 xử lý gói tin ban đầu.
6. Các gói tin sau này trong cùng luồng sẽ được xử lý ngay tại các switch mà không
cần liên lạc với Controller nữa.
3. Thiết lập các quy tắc chuyển tiếp tại Controller (2 điểm)
Đây là mô tả logic chi tiết mà Controller sẽ thực hiện khi phát hiện các luồng mới, sử dụng chính
xác các số hiệu cổng trên sơ đồ.
Logic xử lý Luồng 1 (TCP Path: s1 → s2 → s4 → s3)
Khi Controller phát hiện một luồng TCP từ 128.119/16 đến 128.121/16: •
Đối với s1: Ra lệnh: "Cài quy tắc: Nếu nhận được gói tin TCP từ 128.119/16 đến
128.121/16 tại cổng 5 (từ LAN), hãy chuyển tiếp nó ra cổng 1 (hướng đến s2)." •
Đối với s2: Ra lệnh: "Cài quy tắc: Nếu nhận được gói tin TCP này tại cổng 1 (từ s1), hãy
chuyển tiếp nó ra cổng 3 (hướng đến s4)." •
Đối với s4: Ra lệnh: "Cài quy tắc: Nếu nhận được gói tin TCP này tại cổng 2 (từ s2), hãy
chuyển tiếp nó ra cổng 1 (hướng đến s3)." •
Đối với s3: Ra lệnh: "Cài quy tắc: Nếu nhận được gói tin TCP này tại cổng 4 (từ s4), hãy
chuyển tiếp nó ra cổng 5 (vào mạng LAN đích)."
Logic xử lý Luồng 2 (UDP Path: s1 → s5 → s4 → s3)
Khi Controller phát hiện một luồng UDP từ 128.119/16 đến 128.121/16: •
Đối với s1: Ra lệnh: "Cài quy tắc: Nếu nhận được gói tin UDP từ 128.119/16 đến
128.121/16 tại cổng 5 (từ LAN), hãy chuyển tiếp nó ra cổng 4 (hướng đến s5)." •
Đối với s5: Ra lệnh: "Cài quy tắc: Nếu nhận được gói tin UDP này tại cổng 1 (từ s1), hãy
chuyển tiếp nó ra cổng 2 (hướng đến s4)." lOMoAR cPSD| 58815430 •
Đối với s4: Ra lệnh: "Cài quy tắc: Nếu nhận được gói tin UDP này tại cổng 3 (từ s5), hãy
chuyển tiếp nó ra cổng 1 (hướng đến s3)." •
Đối với s3: Ra lệnh: "Cài quy tắc: Nếu nhận được gói tin UDP này tại cổng 4 (từ s4), hãy
chuyển tiếp nó ra cổng 5 (vào mạng LAN đích)."
4. Hoàn thành các bảng chuyển tiếp (3 điểm)
Đây là kết quả cuối cùng (các bảng luồng) trên từng switch sau khi Controller đã cài đặt.
Lưu ý: Để làm ví dụ cụ thể và đáp ứng yêu cầu, chúng ta giả sử luồng TCP là truy cập Web (cổng
đích 80) và luồng UDP là truy vấn DNS (cổng đích 53). Cổng nguồn (sport) là ngẫu nhiên do máy
khách tạo ra, nên chúng ta không cần đưa vào điều kiện match vì nó không cố định.
Bảng chuyển tiếp cho Switch s1 Priori Action (Hành
Match (Điều kiện khớp) động) ty
in_port: 5, ip_proto: TCP, ipv4_src: 128.119/16, Forward ra cổng 1
1000 ipv4_dst: 128.121/16, tcp_dport: 80
in_port: 5, ip_proto: UDP, ipv4_src: 128.119/16, Forward ra cổng 4
1000 ipv4_dst: 128.121/16, udp_dport: 53 Xuất sang Trang tính
Bảng chuyển tiếp cho Switch s2 Priori Action (Hành
Match (Điều kiện khớp) động) ty
in_port: 1, ip_proto: TCP, ipv4_src: 128.119/16,
1000 ipv4_dst: 128.121/16, tcp_dport: 80 Forward ra cổng 3 Xuất sang Trang tính
Bảng chuyển tiếp cho Switch s5 Priori Action (Hành
Match (Điều kiện khớp) ty động)
in_port: 1, ip_proto: UDP, ipv4_src: 128.119/16, Forward ra lOMoAR cPSD| 58815430 1000
ipv4_dst: 128.121/16, udp_dport: 53 cổng 2 Xuất sang Trang tính
Bảng chuyển tiếp cho Switch s4 Priori Action (Hành
Match (Điều kiện khớp) ty động)
in_port: 2, ip_proto: TCP, ipv4_src: 128.119/16, Forward ra 1000
ipv4_dst: 128.121/16, tcp_dport: 80 cổng 1
in_port: 3, ip_proto: UDP, ipv4_src: 128.119/16, Forward ra 1000
ipv4_dst: 128.121/16, udp_dport: 53 cổng 1 Xuất sang Trang tính
Bảng chuyển tiếp cho Switch s3 Priori Action (Hành
Match (Điều kiện khớp) ty động)
in_port: 4, ip_proto: TCP, ipv4_src: 128.119/16, Forward ra 1000
ipv4_dst: 128.121/16, tcp_dport: 80 cổng 5
in_port: 4, ip_proto: UDP, ipv4_src: 128.119/16, Forward ra 1000
ipv4_dst: 128.121/16, udp_dport: 53 cổng 5 Xuất sang Trang tính