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 3.3 3.4 4 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 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 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 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 namespace 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 = 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 = 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 packetout. · OFPT_PACKET_OUT ∗ Ngoài ra còn có các loại message như Read-State, Role-Request, AsynchronousConfiguration. – 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 controller có thê không gửi gói ofpt_barrier_request], hai gói tin này được floodlight 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 controller, 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: • //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 //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-mdsalall 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õ //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