HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

CƠ SỞ TẠI THÀNH PHỐ HỒ CHÍ MINH

KHOA VIỄN THÔNG II

BÁO CÁO CHUYÊN ĐỀ

KHOA VIỄN THÔNG II
NĂM HỌC: 2020

Đề tài:

Tìm hiểu một mạng SDN đơn giản

NHÓM 3:
Mai Chí Khương N16DCVT040
Văn Phước Kiên N16DCVT033
Lê Trung Lương N16DCVT041
Nguyễn Thành Lưu N16DCVT043
Trần Nhật Minh N16DCVT044
Võ Văn Minh N16DCVT046
Huỳnh Hồ Nam N16DCVT047
Lê Ngọc Tuấn Nhã N15DCVT061
Lê Hồng Phúc N16DCVT056
Huỳnh Chiếm Phương N16DCVT057

Giảng viên: ThS. NGUYỄN XUÂN KHÁNH

TP.HCM
Tháng 4 năm 2020
 HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
CƠ SỞ TẠI THÀNH PHỐ HỒ CHÍ MINH
KHOA VIỄN THÔNG II

BÁO CÁO CHUYÊN ĐỀ

KHOA VIỄN THÔNG II
NĂM HỌC: 2020

Đề tài:

Tìm hiểu một mạng SDN đơn giản

NHÓM 3:
Mai Chí Khương N16DCVT040
Văn Phước Kiên N16DCVT033
Lê Trung Lương N16DCVT041
Nguyễn Thành Lưu N16DCVT043
Trần Nhật Minh N16DCVT044
Võ Văn Minh N16DCVT046
Huỳnh Hồ Nam N16DCVT047
Lê Ngọc Tuấn Nhã N15DCVT061
Lê Hồng Phúc N16DCVT056
Huỳnh Chiếm Phương N16DCVT057

Giảng viên: ThS. NGUYỄN XUÂN KHÁNH

TP.HCM
Tháng 4 năm 2020
NHẬN XÉT CỦA GIẢNG VIÊN

i
 LỜI CẢM ƠN
Đầu tiên, nhóm em xin gủi lời cảm ơn đến Thầy ThS. Nguyễn Xuân Khánh . Thầy luôn
hướng dẫn tận tình cho nhóm trong suốt quá trình nhóm thực hiện đề tài. Thầy đã giải đáp các
thắc mắc cũng như khó khăn mà nhóm gặp phải. Nhóm xin kính chúc Thầy dồi dào sức khỏe và
ngày càng thành công trên con đường sự nghiệp giáo dục của mình.
Tiếp đến, nhóm em xin gửi lời cảm ơn đến các Thầy Cô trong khoa Viễn Thông II đã giúp
nhóm em có những kiến thức bổ ích để thực hiện đề tài này. Kính chúc các Thầy Cô dồi dào sức
khỏe.
Nhóm cũng xin gửi lời cảm ơn đến các thành viên trong lớp đã giúp đỡ nhóm trên lớp học
và sau giờ học.
Và cuối cùng, xin cảm ơn tất cả các thành viên trong nhóm đã tìm hiểu, xây dựng và hoàn
thành đề tài.

Hồ Chí Minh, tháng 4 năm 2020

Tập thể sinh viên nhóm 3

ii
 MỤC LỤC

1 TỔNG QUAN VỀ MININET 1

1.1 Giới thiệu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Các thành phần . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 HOẠT ĐỘNG CỦA OPENFLOW 3

3 TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN 6

3.1 Xây dựng một mạng SDN đơn giản . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 Khởi tạo Mininet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2 Cấu hình tạo Topo mạng . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3 Thực thi lệnh tạo topo . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Kiểm tra hoạt động thực hiện các cơ chế tạo luồng giữa các host, ý nghĩa nội
dung Flowtable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Kiểm tra hoạt động thực hiện các cơ chế tạo luồng giữa các host . . . . 9
3.2.2 Ý nghĩa nội dung flowtable . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Phân tích các bản tin giao thức OpenFlow khi khởi động mạng, ping và tạo luồng 12
3.3.1 Yêu cầu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2 Thiết lập Wireshark và bắt gói tin . . . . . . . . . . . . . . . . . . . . 13
3.3.3 Các Message trong Openflow . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4 Phân tích gói tin của quá trình khởi tạo kết nối giữa controller và switch 16
3.3.5 Phân tích gói tin trong quá trình ping giữa các host . . . . . . . . . . . 20
3.4 Tìm hiểu và triển khai 1 bộ điều khiển . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 Cài đặt JAVA trên Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.2 Tải opendaylight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.3 Cài npm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.4 Cài Opendaylight-openflow-app . . . . . . . . . . . . . . . . . . . . . 32
3.4.5 Chỉnh sửa nội dung env.module.js . . . . . . . . . . . . . . . . . . . . 32
3.4.6 Chạy opendaylight trên ubuntu . . . . . . . . . . . . . . . . . . . . . . 33
3.4.7 Giao diện GUI của Controller ODL . . . . . . . . . . . . . . . . . . . 35

4 KẾT LUẬN 38

iii
 DANH SÁCH HÌNH VẼ

1.1 Các thành phần trong Mininet . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Hoạt động đầu tiên của OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Flow Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Flow Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Flow Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Đăng nhập vào Mininet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Thư mục làm việc hiện tại . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Vị trí file cấu hình topo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 File topo-2sw-2host.py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 Cấu hình từng phần tử trong topo . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6 Thực thi lệnh tạo topo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7 Thông tin thành phần topo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.8 Kiểm tra thông tin bảng luồng Switch 1 . . . . . . . . . . . . . . . . . . . . . 9
3.9 Kiểm tra luồng Switch 1,2 và 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.10 Ping không thành công . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.11 Sơ đồ mạng và cổng kết nối của mạng SDN . . . . . . . . . . . . . . . . . . . 10
3.12 Tạo kết nối giữa các Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.13 Ping thành công . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.14 Kiểm tra lại luồng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.15 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.16 Chọn cổng Ethernet trong WireShark . . . . . . . . . . . . . . . . . . . . . . 14
3.17 Lọc gói tin openflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.18 Các gói tin cho quá trình khởi tạo kết nối . . . . . . . . . . . . . . . . . . . . . 16
3.19 Quá trình khởi tạo kết nối . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.20 Hello message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.21 Thông tin Hello message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.22 Fetures message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.23 Thông tin gói ofpt_features_reply . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.24 Các gói tin trong bước set configuration . . . . . . . . . . . . . . . . . . . . . 19

iv
DANH SÁCH HÌNH VẼ

3.25 ofpt_flow_mod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.26 Thông tin trong ofpt_flow_mod . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.27 ofpt_echo_request/reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.28 Quá trình ARP request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.29 Quá trình ARP reply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.30 Chỉnh nội dung env.module.js . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.31 Chạy opendaylight trên ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.32 Sơ đồ mạng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.33 Khởi tạo mạng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.34 Giao diện GUI của ODL Controller . . . . . . . . . . . . . . . . . . . . . . . 35
3.35 Mục Flow Mangerment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.36 Mục Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.37 Mục Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.38 Mục Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Nhóm 3 D16CQVT01-N Trang v

 CHƯƠNG 1

TỔNG QUAN VỀ MININET

1.1 Giới thiệu

Mininet là một hệ thống dùng tạo nguyên mẫu cho các mạng lớn trong điều kiện tài nguyên
trên một laptop. Mininet sử dụng những đặc tính ảo hóa cấp hệ điều hành, gồm các tiến trình và
không gian tên mạng, cho phép nó giả lập lên đến hàng trăm node. Mininet tạo điều kiện thuận
lợi cho các nhà nghiên cứu trong lĩnh vực kết nối mạng có thể phát triển và triển khai những
ý tưởng, ví dụ một kiến trúc mạng mới, một giao thức di động, hoặc một đặc tính bổ sung vào
router. Mininet tạo ra một môi trường tạo nguyên mẫu của một mạng với những đặc tính sau :

• Linh động: Các địa hình và chức năng mới dược định nghĩa trong phần mềm, dùng những
ngôn ngữ và hệ điều hành quen thuộc

• Triển khai : Việc triển khai một nguyên mẫu đúng về mặt chức năng trên các mạng phần
cứng và môi trường thử nghiệm sẽ không cần thay đổi mã hoặc cấu hình.

• Tương tác: Việc quản lý và vận hành mạng sẽ thực hiện như trong mạng thực, như thể ta
đang tương tác với mạng thực.

• Qui mô : Tạo nguyên mẫu cho các mạng lên đến hàng trăm hàng ngàn chuyển mạch chỉ
trên một laptop.

• Thực tế : Hành vi của nguyên mẫu là những hành vi thực với mức độ tin cây cao, ví dụ
những ứng dụng và chồng giao thức cỏ thể sử dụng được mà không có sự thay đổi nào.

• Chia sẽ : những nguyên mẫu khép kín sẽ dễ dàng chia sẽ với các cộng tác viên.

1.2 Các thành phần

• Links: Một cặp Ethernet ảo (veth pair) hoạt động giống như một kết nối dây giữa 2 giao
tiếp ảo; các gói gởi qua một giao tiếp được đưa đến một giao tiếp khác, và phẩn mềm ứng
dụng và hệ thống nhìn thấy mỗi giao tiếp như là một cổng Ethernet với đầy đủ chức năng.

1
CHƯƠNG 1. TỔNG QUAN VỀ MININET

Các cặp veth có thể được gắn vào các chuyển mạch ảo như là Linux bridge (mã thực hiện
một tập con của chuẩn IEEE 802.1d) hoặc một chuyển mạch OpenFlow phần mềm

• Hosts: Các namespace mạng là những container trạng thái mạng (phương pháp ảo hóa
cấp hệ điều hành linux). Chúng cung cấp cho các tiến trình (và nhóm các tiến trình) quyền
sở hữu riêng biệt các giao tiếp, các cổng và các bảng định tuyến (như ARP và IP). Ví dụ,
2 web server trong 2 namespace mạng có thể đồng tồn tại trên một hệ thống, cả 2 đều có
thể lắng nghe ở cổng 80 trên các giao tiếp eth0 riêng.

Một host trong Mininet đơn giản là một tiến trình shell (ví dụ bash) được đưa vào names-
pace mạng riêng của nó với yêu cầu hệ thống riêng biệt. Mỗi host có riêng các

• Switches: Các chuyển mạch OpenFow bằng phần mểm cung cấp cơ chế phân phối gói vể
ý nghĩa giống như những chuyển mạch phần cứng cung cấp.

• Controller: Các bộ điều khiển có thể đặt ở bất cứ nơi đâu trên mạng thực hoặc trên mạng
mô phỏng, miễn sao thiết bị chạy các chuyển mạch có kết nối mức IP với bộ điều khiển.
Đối với Mininet chạy trong một máy ảo, bộ điều khiển có thể chạy bên trong máy ảo này,
chạy trên máy host, hoặc trong một đám mây.

Hình 1.1: Các thành phần trong Mininet

Nhóm 3 D16CQVT01-N Trang 2

 CHƯƠNG 2

HOẠT ĐỘNG CỦA OPENFLOW

Hình 2.1: Hoạt động đầu tiên của OpenFlow

Bắt đầu gửi gói tin HTTP từ h1 sang h4, quá trình TCP conversation luôn luôn khởi động
với 1 bản tin syn packet . Nếu s1 là sw chính như hình trên thì gói HTTP sẽ chuyển thẳng từ
h1 sang h4 dựa vào địa chỉ mac đã biết sẵn nên s1 sẽ biết chuyển gói tin đi đâu (H4). Đây là
OpenFlow sw, s1 sẽ kiểm tra bản local flows của nó, vì đây là gói tin đầu tiên nên trong bản
flowtable sẽ không có entry matching của gói tin này, được gọi là table miss. Bình thường nếu
không có 1 flow matching thì sw sẽ gửi 1 gói tin lên controller được gọi là packet in. Gói tin
này sẽ bao gồm gói tin TCP SYN gốc bên trong nó kèm theo toàn bộ gói tin hoặc packet header
và 1 buffer ID sẽ cho sw biết phải làm gì với gói đang lưu trữ. Khi controller nhận gói bản tin
packet in thì sẽ có 1 số action như là Controller sẽ gửi 1 gói packet out hoặc flow modification
trở về sw.

• Định nghĩa packet out : là 1 bản tin hướng dẫn sw về những gì phải làm với gói tin cụ thể,
packet out có thể bao gồm 1 gói tin hoàn chỉnh hoặc 1 buffer ID có liên quan gói tin mà
nó đang lưu trữ. Controller sẽ hướng dẫn sw1 gửi 1 gói tin liên quan đến buffer id 250.

3
CHƯƠNG 2. HOẠT ĐỘNG CỦA OPENFLOW

Hình 2.2: Flow Mode

• Controller còn gửi 1 bản tin flow modification, hướng dẫn sw xây dựng 1 flow entry mới
vào flow table của nó. Flow entrty cho sw biết những gói tương tự được gửi sau này gửi
đi đâu dựa vào matching field. Flow mod còn bao gồm buffer id và nó sẽ cho sw biết rằng
gói tin đầu tiên mà mình lưu trữ là buffer id 250 và lấy nó để bỏ vào action trong gói tin
này, action hoạt động theo h1 yêu cầu sw. Ngoài ra 1 bản tin có thể bao gồm nhiều action
như pop push swap. . . . . . .

– Time out bao gồm:

∗ idle time out =20: nếu như không có matching HTTP requests trong vòng 20s
thì nó sẽ xóa flow entry này và host time out =60s : sau 60s không cần biết đang
làm gì sẽ xóa flow entry.

∗ prioty =5000: độ ưu tiên và nó sẽ sắp xếp thứ tự ưu tiên của các flow etry, nếu
flow có độ ưu tiên lớn hơn thì sẽ được sử dụng và flow thấp hơn sẽ bị từ chối

∗ sw sẽ gửi gói tin tới h4.

Nhóm 3 D16CQVT01-N Trang 4

CHƯƠNG 2. HOẠT ĐỘNG CỦA OPENFLOW

Hình 2.3: Flow Entry

– Mặc dù đã thiết lập flow entry h1 sang h4 nhưng khi gửi ngược từ h4 sang h1 thì
flow entry của SYN ack không hề có flow entry nên thực hiện tương tự cách bước
gửi lên controller để có flow entry.

Hình 2.4: Flow Entry

– Sau khi 2 quá trình h1 sang h4, h4 sang h1 thì ta đã có flow entry cho cả đi và về
trong flow table cho nên các gói tin gửi sau này sẽ gửi thẳng từ h1 sang h4 hoặc
ngược lại mà không cần phải gửi tin lên controller.

Nhóm 3 D16CQVT01-N Trang 5

 CHƯƠNG 3

TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

3.1 Xây dựng một mạng SDN đơn giản

Yêu cầu: Xây dựng một mạng SDN đơn giản gồm 1 bộ điều khiển,4 host và 3 switch

3.1.1 Khởi tạo Mininet

• Trong báo cáo này, sử dụng VMware Workstation để làm nền tảng chạy máy ảo Mininet.

• Đăng nhập vào Mininet với user là mininet và password là mininet

Hình 3.1: Đăng nhập vào Mininet

• Ta nhập lệnh $ pwd để in ra đường dẫn đến thư mục làm việc hiện tại.

Hình 3.2: Thư mục làm việc hiện tại

6
CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

3.1.2 Cấu hình tạo Topo mạng

• Chúng ta sử dụng ngôn ngữ lập trình Python để cấu hình topo cho file mặc định của
Mininet.

• File nằm trong đường dẫn /home/mininet/mininet/custom và có tên là topo-2sw-2host.py

Hình 3.3: Vị trí file cấu hình topo

• Để sửa file topo-2sw-2host.py mặc định ta di chuyển đến thư mục chưa nó bằng câu lệnh
cd mininet/custom/. Sau đó để đọc file ta sử dụng lệnh nano topo-2sw-2host.py

Hình 3.4: File topo-2sw-2host.py

• Chúng ta tiến hành sửa file trực tiếp trên file mặc định. Cụ thể:

– Thêm 1 switch với câu lệnh <tên switch> = self.addSwitch( ‘ ‘)

Nhóm 3 D16CQVT01-N Trang 7

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

– Thêm 1 host với câu lệnh <tên host> = self.addHost( ‘ ‘)

– Thiết lập đường truyền bằng câu lệnh self.addLink( , )

Hình 3.5: Cấu hình từng phần tử trong topo

• Sau đó nhấn Ctrl + x để lưu file với tên là chuyende.py

3.1.3 Thực thi lệnh tạo topo

• Ta sử dụng lệnh $ sudo mn –custom /mininet/custom/chuyende.py –topo mytopo –

mac –switch ovsk –controller remote chạy file chuyende.py để tạo mạng SDN. Sau khi
chạy thành công sẽ xuất ra màn hình 1 bộ điều khiển, 4 host và 3 switch.

Hình 3.6: Thực thi lệnh tạo topo

• Dùng câu lệnh sh sudo ovs-ofctl show s2 để kiểm tra thông tin của bảng luồng của switch
2.

Nhóm 3 D16CQVT01-N Trang 8

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

3.2 Kiểm tra hoạt động thực hiện các cơ chế tạo luồng giữa
các host, ý nghĩa nội dung Flowtable

3.2.1 Kiểm tra hoạt động thực hiện các cơ chế tạo luồng giữa các host

• Kiểm tra các kết nối của mạng vừa tạo với các câu lệnh như sau:

– net: hiển thị interface trong các node.

– dump: hiển thị thông tin chi tiết tất cả các node.

– nodes: hiển thị các node hiện tại.

– links: hiển thị các đường truyền

Hình 3.7: Thông tin thành phần topo

• Các đường truyền đã tạo thành công. Tạo luồng cho các host và switch:

– Dùng lệnh sh ovs-ofctl show s1 để kiểm tra luồng switch 1

Hình 3.8: Kiểm tra thông tin bảng luồng Switch 1

– Ngoài ra, để kiểm tra các luồng của switch s1, ta còn có thể dùng lệnh sh ovs-ofctl
dump-flows s1 và tương tự với switch 2 và switch 3.

Nhóm 3 D16CQVT01-N Trang 9

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

Hình 3.9: Kiểm tra luồng Switch 1,2 và 3

– Ta tiến hành ping thử từ Host 1(h1) qua Host 4(h4):

Hình 3.10: Ping không thành công

– Chưa có kết nối giữa các host vì trong bảng luồng không có luồng nào cho kết nối
này. Để tạo luồng từ host 1 sang host 4, ta dùng trình tiện ích ovs-ofctl. Cách xác
định in_port và outport thì ta dựa vào sơ đồ mạng đã vẽ được sau khi thực hiện các
lệnh links, dump, net, nodes.

Hình 3.11: Sơ đồ mạng và cổng kết nối của mạng SDN

• Dùng câu lệnh sh ovs-ofctl add-flow s1 in_port=1,actions=output:normal

– Với s1 là tên switch, In_port là cổng vào, Output là cổng ra.

– Với câu lệnh trên luồng sẽ được tạo đi từ cổng 1 của switch 1 ra tất cả cổng còn lại.
Nếu thay normal bằng số, thì luồng sẽ ra theo cổng số được chỉ định.

Nhóm 3 D16CQVT01-N Trang 10

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

Hình 3.12: Tạo kết nối giữa các Host

– Ping lại và thấy gói tin đã được gửi đi thành công:

Hình 3.13: Ping thành công

• Gõ lệnh pingall để kiểm tra lại luồng, mỗi port vào đã được phân luồng thành công với
tất cả port ra trên switch.

Hình 3.14: Kiểm tra lại luồng

3.2.2 Ý nghĩa nội dung flowtable

• Bảng luồng hay bảng lưu lượng giúp cho việc chuyển các gói tin từ nơi gửi đến nơi nhận
một cách hiệu quả và thích hợp dựa vào các thông số và thành phần trong FlowTable
(thông tin độ ưu tiên).Flowtable đóng vai trò như một bảng định tuyến trong router trong
mạng truyền thống. Flowtable quản lý được đường đi của gói tin dựa vào cấu hình các
port in và out do người kỹ sư mạng thiết lập.

• Trong mỗi bảng flow table này sẽ chứa một tập các flow entry. Các flow entry này được
thêm, sửa đổi hoặc loại bỏ đi bởi SDN controller. Mỗi flow entry sẽ bao gồm các thành
phần sau:

Nhóm 3 D16CQVT01-N Trang 11

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

– Match fields: Bao gồm các thông tin về packet header và ingress port dùng để so
khớp các gói tin, khi một gói tin match với một flow entry thì gói tin đó sẽ được xử
lý bằng các hành động đã được định nghĩa trong flow entry đó.

– Priority: Mức độ ưu tiên của flow entry đó. Mỗi gói tin có thể match với nhiều flow
entry khi đó gói tin sẽ được xử lý bởi flow entry có priority cao hơn.

– Counters: Bộ đếm sẽ cập nhật mỗi khi gói tin được xử lý bởi flow entry đó.

– Instructions: Định nghĩa các hành động để xử lý gói tin.

– Timeouts: Thời gian tối đa để xử lý gói tin

– Cookie: giá trị được chọn bởi Controller được sử dụng để lọc số liệu thống kê của
flow entry, sửa đổi flow entry hoặc xóa flow entry.

• Ngoài các flow entry mỗi flow table còn chứa một table miss flow entry được sử dụng để
xử lý các gói tin khi không có flow entry nào trong flow table match với gói tin đó. Table
miss flow entry có thể sẽ chuyển tiếp gói tin đó đến controller, gửi gói tin tới flow table
tiếp theo hoặc loại bỏ gói tin.

3.3 Phân tích các bản tin giao thức OpenFlow khi khởi động
mạng, ping và tạo luồng

3.3.1 Yêu cầu

• Ở phần này chúng ta sẽ sử dụng wireshark để bắt ;và phân tích gói tin trong các quá trình
khởi tạo kết nối giữa controller và switch, hay khi ta ping giữa host 1 và host 2

• Trong phần này chúng ta dùng Mininet để tạo mạng sdn gồm 4 host và 3 switch (hình 3.1)
với giao thức southbound là openflow phiên bản 1.0 và controller là Floodlight được kết
nói với mininet qua interface vmnet8.

Nhóm 3 D16CQVT01-N Trang 12

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

Hình 3.15: Topology

3.3.2 Thiết lập Wireshark và bắt gói tin

Sau khi đã mở wireshark trên windows chúng ta thực hiện tuấn tự các bước như sau:

• B1: Chọn cổng để tiến hành capture:

Nhóm 3 D16CQVT01-N Trang 13

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

Hình 3.16: Chọn cổng Ethernet trong WireShark

• B2: Tại mục fillter nhập openflow_v1 để lọc gói tin openflow phiên bản 1.0 và nhấn
Enter:

Hình 3.17: Lọc gói tin openflow

• B3: Khởi tạo mạng sdn trên mininet

# sudo mn –custom chuyende.py –topo mytopo –switch ovsk –controller remote,ip=ĐỊA_CHỈ_IP

–mac

Chú ý: ĐỊA_CHỈ_IP là địa chỉ ip của floodlight controller

Nhóm 3 D16CQVT01-N Trang 14

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

3.3.3 Các Message trong Openflow

• Chúng ta chỉ sẽ tìm hiểu 1 số gói tin trong openflow liên quan đến quá trình khởi tạo kết
nối giữa controller và switch, quá trình học flow, ping.

• Openflow có 3 loại message, mỗi message này lại có các loại message con. Bao gồm:

– Controller to Switch

∗ Được gửi bởi controller

∗ Features: Controller yêu cầu switch trả lời cho nó các capability.

· OFPT_FEATURES_REQUEST

· OFPT_FEATURES_REPLY

∗ Configuration: Controller có thể set hoặc truy vấn các tham số cấu hình cho
switch .

· OFPT_GET_CONFIG

∗ Modify-State: Thêm chỉnh sửa xóa các mục luồng hoặc group

· OFPT_FLOW_MOD

∗ Barrier: Controller sau khi gửi cho switch 1 message và muốn switch trả lời
cho controller biết rằng switch đã xử lý message đó như thế nào (thành công
hay gặp vấn đề).

· OFPT_BARRIER_REQUEST

· OFPT_BARRIER_REPLY

∗ Packet-out: Khi controller muốn gửi 1 packet cho switch thì nó dùng packet-
out.

· OFPT_PACKET_OUT

∗ Ngoài ra còn có các loại message như Read-State, Role-Request, Asynchronous-

Configuration.

– Asynchronous

∗ Được gửi bởi switch

∗ Packet-in: Truyền tải các control packet cho controller

· OFPT_PACKET_IN

∗ Error: Thông báo cho controller khi có lỗi

· OFPT_ERROR

Nhóm 3 D16CQVT01-N Trang 15

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

∗ Ngoài ra còn có một số message khác như flow removed và port status

– Symmetric

∗ Được gửi bởi cả controller lẫn switch:

∗ Hello: Được trao đổi giữa switch và controller trong quá trình khởi tạo kết nỗi.

· OFPT_HELLO

∗ Echo: xác nhận xem liên kiết giữa controller và switch còn up hay đã down

· OFPT_ECHO_REQUEST

· OFPT_ECHO_REPLY

∗ Ngoài ra còn có Experimenter

3.3.4 Phân tích gói tin của quá trình khởi tạo kết nối giữa controller và
switch

Hình 3.18: Các gói tin cho quá trình khởi tạo kết nối

• Quá trình khởi tạo kết nối

Nhóm 3 D16CQVT01-N Trang 16

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

Hình 3.19: Quá trình khởi tạo kết nối

• Phân tích

– Trao đổi Hello Message:

Hình 3.20: Hello message

Hình 3.21: Thông tin Hello message

∗ Switch gửi gói tin OFPT_HELLO bao gồm version cho controller để khởi tạo
kết nối với controller, nếu controller có hỗ trợ phiên bản của switch => kết nối
được thiết lập

∗ Chú ý: tùy theo controller có 1 số controller sẽ trả lời lại cho switch gói tin hello

– Feature Request – Reply

Nhóm 3 D16CQVT01-N Trang 17

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

Hình 3.22: Fetures message

∗ Controller gửi cho switch gói ofpt_features_request để yêu cầu switch gửi các
capability cho controller. Switch trả lời lại gói ofpt_features_reply.

Hình 3.23: Thông tin gói ofpt_features_reply

∗ Trong featuter_reply chứa:

· Datapath ID dùng để định danh switch

· N_table: số lượng table tối đa của sw

· Capabilites: Khả năng thống kê luồng, table, port, group, vv

· Actions: Các action mà sw có thể thực hiện, set vlan id và priority, lưu trữ
output trong hàng đợi, forward ra sw port vv

· Các thông tin về Port của switch như port number, MAC, các flag, Tên port
vv

Nhóm 3 D16CQVT01-N Trang 18

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

– Set Configuration

∗ Controller gửi 2 gói tin ofpt_set_config và ofpt_barrier_request (tùy theo con-

troller có thê không gửi gói ofpt_barrier_request), hai gói tin này được flood-
light gói trong packet ofpt_get_config_request

∗ Ofpt_set_config được controller gửi để set các flag trên switch và cho switch
biết số byte lớn nhất của packet có thể gửi cho controller.

∗ Ofpt_barrier_request yếu cầu switch nếu xử lý thành công thì trả lại gói ofpt_barrier_reply,
nếu bị lỗi thì tả về ofpt_error

Hình 3.24: Các gói tin trong bước set configuration

– Ofpt_flow_mod (tùy controller có thể gửi hoặc không)

Hình 3.25: ofpt_flow_mod

Nhóm 3 D16CQVT01-N Trang 19

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

Hình 3.26: Thông tin trong ofpt_flow_mod

∗ Controller gửi gói tin ofpt_flow_mod cho switch

∗ Bên trong ofpt_flow_mod chứa các thông tin của 1 flow entry như inport,
source mac , priority, và đặc biệt là command.

∗ Ở đây Controller gửi gói tin ofpt_flow_mod cho switch với command là xóa hết
tất cả các flowing

– Echo message:

Hình 3.27: ofpt_echo_request/reply

∗ Dùng để xác nhận xem kết nối giữa switch và controller liệu có vấn đề không,
ở đây ta thấy cứ khoảng mỗi 5 s controller gửi cho switch 1 echo request và
switch trả lời echo reply cho thấy kết nối vẫn bình thường.

3.3.5 Phân tích gói tin trong quá trình ping giữa các host

Sơ lược: ở phần này chúng ta sẽ ping từ h1 sang h2, ta sẽ phân tích gói tin ở 3 giai đoạn là từ
Arp request và Arp reply và Icmp (gói tin để ping).

Nhóm 3 D16CQVT01-N Trang 20

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

• ARP Request:

Hình 3.28: Quá trình ARP request

– Bước 1 và 2

∗ H1 ping cho H2 nhưng nó ko biết địa chỉ MAC của H2 nên nó gửi gói ARP.

∗ Gói ARP đến switch 1, switch không có bất kì flow entry nào để match nên nó
đóng gói arp này vào trong gói PACKET_IN để gửi cho controller.

∗ Controller học đươc rằng muốn tới H1 thì đi ra port1 của Sw1

Nhóm 3 D16CQVT01-N Trang 21

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

∗ Như trên hình, gói tin Packet_IN có source ip là 10.10.10.129 (switch) và des
ip là 10.10.10.128 (controller), source port là 57050 nên đây là SW1. Gói tin
được gửi từ SW1 tới controller.

∗ Gói tin chứa các thông tin như: In port (là cổng mà gói tin đi vào switch 1) là
1, Reason (nguyên nhân nó gửi gói tin tời controller) là vì nó gói tin này không
match bất kì flow entries nào (thực ra là sw không có bất kì flow entries)

∗ Bên trong gói Packet_IN này còn chứa gói ARP mà H1 gửi ra

– Bước 3:

Nhóm 3 D16CQVT01-N Trang 22

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

∗ Controller gửi lại cho switch 1 gói Packet_Out với action type là bảo switch 1
forward gói tin arp này ra tất cả các port.

– Bước 4-5-6-7:

∗ Switch 1 nhận được Packet_Out ở bước 3 và gửi nó ra tât cả các port. (bước 4)

∗ Switch 3 (source port là 57046) nhận được gói tin và không biết làm gì với gói
tin này, nó gửi cho controller gói packet_in tương tự như ở b2 với in port là 3
(port mà gói tin đi vào switch 3), reason là gói tin không match bất kì flow entry
nào (bước 5)

∗ Controller học được răng muốn tới h1 thì đi ra port 3 của sw3.

Nhóm 3 D16CQVT01-N Trang 23

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

∗ Sau đó Switch 3 cũng nhận được gói packet_out từ controller (bước 6) và gửi gói
tin ra tất cả các port (trong đó sw2 cũng nhận và nó cũng gửi gói tin packet_in
lên controller nhưng ở đây chúng ta không nói đến nó)

∗ H2 cũng nhận được gói tin ARP từ switch 3 (bước 7)

• ARP Reply:

Hình 3.29: Quá trình ARP reply

Nhóm 3 D16CQVT01-N Trang 24

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

– Bước 8 – 9

∗ H2 nhận được gói arp và trả lời gói arp reply có chứa MAC của nó (bước 8)

∗ Switch 3 nhận được gói tin và nó cũng không biết làm gì, nó gửi gói Packet_In
cho Controller. (bước 9)

∗ Switch 3 (source port 57046) gửi Packet_In với inport là 1, reason là không có
flow nào match. Trong gói ARP reply chứa địa chỉ Mac của h2.

∗ Controller khi nhận đươc gói tin thì học được rằng muốn tới h2 thì đi ra port 1
của switch 3.

– Bước 10

∗ Controller sau khi nhận được gói Packet_In, thấy rằng sw3 cần flow entry.

∗ Controller nhìn vào phần ethernet của gói arp trong packet_in ở bước 9 và thấy
rằng đích là h1 như hình dưới:

Nhóm 3 D16CQVT01-N Trang 25

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

∗ Controller tra vào trong và thấy muốn tới h1 thì ra cổng 3 của sw3 và cổng 1
của sw1 như hình dưới:

∗ Controller gửi 2 gói ofpt_flow_mod để thêm flow entry cho sw1 và sw3:

· Ofpt_flow_mod gửi cho sw1

Nhóm 3 D16CQVT01-N Trang 26

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

∗ Flow entry gửi cho sw1 với inport là 2 (gói tin đi vào), source mac là từ h2, dest
mac là tới h1, đi ra port 1 của sw1, loại data type là arp (2054)

· Ofpt_flow_mod cho sw3:

Nhóm 3 D16CQVT01-N Trang 27

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

– Bước 11-12

∗ Switch 3 nhận được flow entry từ gói ofpt_flow_mod, nó dùng flow này forward
packet arp reply ra port 3 của switch 3. (bước 11)

∗ Switch 1 nhận packet arp reply từ switch 3, switch 1 dựa vào flow entry từ bước
10 và forward ra port 1 của sw1 (bước 12).

• ICMP:

Nhóm 3 D16CQVT01-N Trang 28

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

– Bước 1:

∗ Sau khi đã nhận arp reply từ h2 và có địa chỉ mac của h2 và h1 bắt đầu gửi gói
icmp , với đích là h2

– Bước 2:

∗ Switch 1 không có flow entry từ h1 tới h2 nên nó gửi gói packet_in cho con-
troller, trong gói packet_in chứa gói icmp, với reason là không có flow nào
match.

– Bước 3:

∗ Controller gửi lại ofpt_flow_mod cho cả switch 1 và switch 3 chứa các thông
tin về flow để đi đến h2

· Ofpt_flow_mod gửi cho sw1:

∗ Inport (packet icmp đi vào) là port 1

∗ Source mac là h1, dest mac là h2

∗ Out port (là port để fowarding) là port 2

∗ Loại data là 2048 (icmp)

∗ Command là new flow

· Ofpt_flow_mod gửi cho sw3:

∗ Inport (packet icmp đi vào) là port 3

∗ Source mac là h1, dest mac là h2

∗ Out port (là port để fowarding) là port 1 ại data là 2048 (icmp)

Nhóm 3 D16CQVT01-N Trang 29

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

∗ Command là new flow

Nhóm 3 D16CQVT01-N Trang 30

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

– Bước 4:

∗ Sw1 nhận đc flow entry và forward gói tin ra port 2

∗ Sw3 nhận đc packet này trên port 3

– Bước 5:

∗ Sw3 forward packet ra port 1

• Quá trình ICMP reply tương tự.

3.4 Tìm hiểu và triển khai 1 bộ điều khiển

Sử dụng Controller Open Daylight phiên bản 0.4.1, chạy trên hệ điều hành Ubuntu 18.4

3.4.1 Cài đặt JAVA trên Ubuntu

Cài đặt JAVA trên Ubuntu (sử dụng phiên bản Java 8), ta thực hiện các câu lệnh:

• Sudo apt-get update

• Sudo apt-get –y install unzip vim wget

Nhóm 3 D16CQVT01-N Trang 31

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

• Sudo apt-get –y install openjdk-8-jre

• Echo ‘export

• JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre’» /.bashrc

• /.bashrc

3.4.2 Tải opendaylight

Tải opendaylight về, link tải:

• https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/distribu
karaf/

• Opendaylight có tên Distribution-karaf-0.4.0-Beryllium.zip

• Ta tiến hành giải nén bằng câu lệnh:

– Unzip Distribution-karaf-0.4.0-Beryllium.zip.

3.4.3 Cài npm

Sau đó ta mở thêm 1 terminal ubuntu, cài npm (npm là 1 chương trình để quản lý thư viện
trong môi trường JAVA Node.js):

• Sudo apt install npm

3.4.4 Cài Opendaylight-openflow-app

• Sudo apt install git

• git clone https://github.com/CiscoDevNet/OpenDaylight-Openflow-App

• cd OpenDaylight-Openflow-App/

• sudo npm install –g grunt-cli

3.4.5 Chỉnh sửa nội dung env.module.js

Sau đó ta vào chỉnh sửa nội dung env.module.js, mục đích là sửa địa chỉ ip của controller
mặc định thành ip khớp với ip controller ta đang sử dụng bằng câu lệnh:

Nhóm 3 D16CQVT01-N Trang 32

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

• vim /OpenDaylight-Openflow-App/ofm/src/common/config/env.module.js

• ta sửa localhost thành ip của Opendaylight

Hình 3.30: Chỉnh nội dung env.module.js

3.4.6 Chạy opendaylight trên ubuntu

Sau đó ta chạy opendaylight trên ubuntu bằng câu lệnh:

• ./karaf/bin/karaf

• Sau khi đã mở được Opendaylight, ta sẽ cài các tính năng cho open daylight:

– feature:install odl-restconf-all odl-openflowplugin-all odl-l2switch-all odl-mdsal-

all odl-yangtools-common odl-dlux-core odl-dlux-all

Hình 3.31: Chạy opendaylight trên ubuntu

• Sau đó, chạy opendaylight-openflow-app:

– cd OpenDaylight-Openflow-App/

– sudo grunt

Nhóm 3 D16CQVT01-N Trang 33

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

• Xong phần cấu hình ODL trên ubuntu, bây giờ, ta vào mininet tạo 1 topo gồm 4host 3sw,
với controller được trỏ tới địp chỉ ip của ODL. Mô hình như sau:

Hình 3.32: Sơ đồ mạng

• Lệnh khởi tạo: (với file mytopo.py được viết bằng python và được lưu từ trước vào
mininet):

– sudo mn –custom mytopo.py –switch=ovsk –controller=remote,ip=10.10.10.135,port=6633

–topo mytopo –mac

Hình 3.33: Khởi tạo mạng

Nhóm 3 D16CQVT01-N Trang 34

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

3.4.7 Giao diện GUI của Controller ODL

• Sau đó, ta vào giao diện GUI của Controller ODL bằng cách vào trình duyệt web, gõ
http://10.10.10.35:900

• Ta sẽ thấy giao diện GUI của ODL Controller như sau:

Hình 3.34: Giao diện GUI của ODL Controller

• Tại giao diện này, ta có thể thực hiện các thao tác như xem thông tin của mô hình mạng.
Tạo, sửa, xóa, thêm luồng,. . . Ví dụ như:

– Hình 3.34 đã cho ta thấy được mô hình tổng quát của mạng.

– Tại Flow Managerment (Hình 3.35) ta có thể xem những thông tin trạng thái các
Switch, các flow emtry và chỉnh sửa chúng:

Hình 3.35: Mục Flow Mangerment

Nhóm 3 D16CQVT01-N Trang 35

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

– Tại mục Flow (Hình 3.36) cho phép chúng ta xem, sửa, xóa và tạo luồng mới cho
hoạt động của topo mạng.

Hình 3.36: Mục Flow

– Tại mục Statistics (Hình 3.37), cho phép chúng ta xem thông tin của table, port,
group, metter,. . . .

Hình 3.37: Mục Statistics

– Ở mục Hosts (hình 3.38), ta có thể xem các thông tin của host như host ID, địa chỉ
IP, MAC,. . .

Nhóm 3 D16CQVT01-N Trang 36

CHƯƠNG 3. TÌM HIỂU MỘT MẠNG SDN ĐƠN GIẢN

Hình 3.38: Mục Host

• Tóm lại, với 1 mô hình mạng sử dụng controller, ta sẽ có khả năng quản lý các thiết bị với
1 cái nhìn toàn cảnh, trực quan, dễ sử dụng và tiết kiệm tài nguyên bởi việc Phân luồng
dữ liệu thành 2 luồng control plane và data plane riêng biệt.

Nhóm 3 D16CQVT01-N Trang 37

 CHƯƠNG 4

KẾT LUẬN
Trong báo cáo này đã giới thiệu về Mininet và hoạt động của giao thức OpenFlow. Đồng
thời cũng hướng dẫn các thao tác cơ bản với Mininet để xây dựng và quản lý các thực thể một
topo mạng đơn giản. SDN ra đời để giúp con người đơn giản hóa việc quản lý các thực thể trong
mạng SDN và Mininet chính là công cụ để thực hiện việc đơn giản hóa ấy. Tuy nhiên báo cáo
chỉ dừng lại ở mức cơ bản, nếu muốn tìm hiểu sâu thì vấn đề bảo mật có thể được xem xét đến.

38