Tìm Hiểu Về Nox Pox Controller Trema Controller.pdf

Giao thức OpenFlow kết nối phần mềm điều khiển với các thiết bị mạng để phần mềm máy chủ có thể cho các thiết bị chuyển mạch biết nơi gửi các gói.. Bộ điều khiển sử dụng giao thức OpenFl

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Tìm hiểu về NOX/POX CONTROLLER TREMA CONTROLLER

Nhóm 9 Ngô Đức Bình – 20021494 Chu Tuấn Anh – 20021481 Nguyễn Duy Đạt – 20021510 Hoàng Đức Phương – 20021569 Nguyễn Minh Tuấn – 20021595 Hoàng Tùng Quân – 20020247 Nguyễn Thị Thu Nguyệt - 20021563

D

1

MỤC LỤC

1: SDN Controller

2: Nox/Pox Controller

2.1: Nox Controller

2.2: Pox Controller

2.2.1: Giới thiệu chung

2.2.2: Khởi chạy pox

2.2.3: Các thành phần của pox

2.2.4: Pox API

2.2.5: Openflow in POX

2.2.6: Một số hình ảnh chạy POX thực tế

3: Trema Controller

3.1: Giới thiệu chung

3.2: So sánh Trema với NOX/POX

3.3: Các thành phần của Trema

3.4: REST API

3.5: API ứng dụng Trema

3.5.1: Chủ đề, sự kiện và hàng đợi sự kiện

3.5.2: Mô hình chương trình ứng dựng Trema

3.6: Tham chiếu API giao thức OpenFlow

Tài liệu tham khảo:,

1: SDN Controller

SDN controller là một ứng dụng hoạt động

như bộ não của mạng điều khiển mềm, nó

hoạt động như một điểm kiểm soát toàn bộ

hoạt động của mạng

SDN controller là loại hệ điều hành cho

mạng mà mọi giao tiếp giữa các ứng dụng

và thiết bị phải đi qua Bộ điều khiển nằm

giữa các thiết bị mạng một bên và lớp ứng

dụng ở phía bên kia, dịch các yêu cầu từ lớp

ứng dụng và quản lý điều khiển luồng sang

các thiết bị mạng (thông qua API hướng

nam) và cung cấp cho ứng dụng SDN chế

độ xem trừu tượng về logic mạng và nghiệp

vụ (thông qua API hướng bắc) Bộ điều

khiển SDN xác định các luồng dữ liệu xảy

ra trong mặt phẳng dữ liệu SDN Mỗi luồng

qua mạng trước tiên phải được sự cho phép

của bộ điều khiển theo chính sách mạng Hình 1: Kiến trúc của SDN controller

Nếu bộ điều khiển cho phép một luồng, nó sẽ tính toán một tuyến đường cho luồng đi và thêm một

mục nhập cho luồng đó trong mỗi switch dọc theo đường dẫn Với tất cả các chức năng phức tạp

được tổng hợp bởi bộ điều khiển, các thiết bị chuyển mạch chỉ đơn giản là quản lý các bảng luồng

mà các mục nhập chỉ có thể được điền bởi bộ điều khiển

Giao tiếp giữa bộ điều khiển và thiết bị chuyển mạch sử dụng giao thức và API được tiêu chuẩn

hóa Bộ điều khiển SDN phục vụ như một loại hệ điều hành cho mạng Tất cả các giao tiếp giữa

các ứng dụng và thiết bị phải đi qua bộ điều khiển Giao thức OpenFlow kết nối phần mềm điều

khiển với các thiết bị mạng để phần mềm máy chủ có thể cho các thiết bị chuyển mạch biết nơi gửi

các gói Bộ điều khiển sử dụng giao thức OpenFlow để cấu hình các thiết bị mạng và chọn đường

dẫn tốt nhất cho lưu lượng ứng dụng Bởi vì kế hoạch điều khiển mạng được thực hiện trong phần

mềm, lưu lượng mạng có thể được quản lý năng động hơn và ở mức chi tiết hơn nhiều

2: Nox/Pox Controller

2.1: Nox Controller

NOX là bộ điều khiển OpenFlow đầu tiên, được phát triển bởi Nicira và trở thành một nguồn mở

vào 2008 Sau đó được mở rộng và hỗ trợ bởi ON, hoạt động phòng thí nghiệm tại Đại học Stanford,

UC Berkeley và ICSI

Những người xây dựng khung SDN đã tập hợp vào năm 2011 và thành lập Trung tâm nghiên cứu

mạng mở (ONRC) và ON Lab (Open Network Lab) để tập trung, phát triển, triển khai và hỗ trợ

các công cụ và nền tảng SDN nguồn mở Phiên bản NOX có thể được định nghĩa là: 1) NOX

Classic: Đây là phiên bản đã có sẵn theo GPL từ năm 2009 2) NOX: "NOX mới." Trước đây là

một nền tảng điều khiển mạng dựa trên C ++ và hỗ trợ ngôn ngữ lập trình Python NOX mới chỉ

hỗ trợ C ++ với ít ứng dụng mạng hơn, nhưng nó nhanh hơn nhiều và cung cấp cơ sở mã tốt hơn

so với NOX-Classic

3

NOX vừa là bộ điều khiển nguyên thủy vừa là khung dựa trên thành phần để phát triển các ứng dụng SDN Nó cung cấp các mô-đun hỗ trợ cụ thể cho OpenFlow nhưng đã được mở rộng Lõi NOX cung cấp các phương thức trợ giúp và API để tương tác với các thiết bị chuyển mạch OpenFlow, bao gồm trình xử lý kết nối và xử lý sự kiện Các thành phần bổ sung tận dụng API đó

có sẵn, bao gồm theo dõi máy chủ, định tuyến, cấu trúc liên kết (LLDP) và giao diện Python được triển khai làm trình bao bọc cho thành phần API

Hình 2: Kiến trúc của NOX Controller

NOX thường được sử dụng trong nghiên cứu mạng học thuật để phát triển các ứng dụng SDN như nghiên cứu giao thức mạng Một tác dụng phụ thực sự thú vị của việc sử dụng học thuật rộng rãi của nó mã có sẵn để mô phỏng một switch học tập và một switch toàn mạng, có thể được sử dụng làm mã khởi động cho các dự án lập trình và thử nghiệm khác nhau

Một số ứng dụng NOX phổ biến là SANE và Ethane SANE là một cách tiếp cận để đại diện cho mạng dưới dạng một hệ thống tệp Ethane là một ứng dụng nghiên cứu của Đại học Stanford về bảo mật tập trung, toàn mạng ở cấp độ của danh sách kiểm soát truy cập truyền thống Cả hai đều chứng minh hiệu quả của SDN bằng cách giảm đáng kể các dòng mã cần thiết để thực hiện các chức năng này cần nhiều mã hơn đáng kể để thực hiện các chức năng tương tự trong quá khứ Dựa trên thành công này, các nhà nghiên cứu đã chứng minh các ứng dụng giống như MPLS trên lõi NOX

NOX bị một số hạn chế, Để giải quyết những vấn đề này, một nền tảng mới dựa trên NOX đã ra đời POX, tự gọi mình là anh chị em của NOX Bộ điều khiển POX là phiên bản Python thuần túy của NOX Nó được biết đến như một bộ điều khiển dòng chảy mở, mã nguồn mở, chung, được viết bằng python Đó là đổi mới để cải thiện hiệu suất của Python NOX gốc

2.2: Pox Controller

2.2.1: Giới thiệu chung

POX là phiên bản mới hơn, dựa trên Python của NOX (hoặc NOX trong Python) Ý tưởng đằng sau sự phát triển của nó là đưa NOX trở lại nguồn gốc C ++ của nó và phát triển một nền tảng dựa trên Python riêng biệt (Python 2.7) Nó có API SDN cấp cao bao gồm biểu đồ cấu trúc liên kết có thể truy vấn và hỗ trợ ảo hóa

Những ưu điểm của POX:

• POX có giao diện Pythonic OpenFlow

• POX có các thành phần mẫu có thể tái sử dụng để lựa chọn đường dẫn, khám phá cấu trúc liên kết

• POX chạy ở bất cứ đâu và có thể đi kèm với thời gian chạy PyPy không cần cài đặt để triển khai dễ dàng

• POX đặc biệt nhắm mục tiêu Linux, Mac OS và Windows

• POX hỗ trợ các công cụ GUI và trực quan hóa giống như NOX

• POX hoạt động tốt so với các ứng dụng NOX được viết bằng Python

Cả NOX và POX hiện đang giao tiếp với các thiết bị chuyển mạch OpenFlow v1.0 và bao gồm hỗ trợ đặc biệt cho Open vSwitch

Không có GUI chính thức cho POX, mặc dù các dự án của bên thứ ba, chẳng hạn như POXDesk1, tồn tại Đặc biệt, POXDesk cung cấp chức năng cơ bản, chẳng hạn như trực quan hóa các bảng luồng, các sự kiện được ghi lại và cấu trúc liên kết mạng Giao tiếp giữa POXDesk và lõi của POX

sử dụng API REpresentational State Transfer (REST) có sẵn với bộ điều khiển

2.2.2: Khởi chạy pox

“pox.py” khởi động POX Nó lấy một danh sách các tên thành phần trên dòng lệnh, định vị các thành phần, gọi hàm “launch()” của chúng (nếu nó tồn tại), và sau đó chuyển sang trạng thái "up" Nếu chạy “./pox.py”, nó sẽ cố gắng tìm một trình thông dịch Python 3 thích hợp Đặc biệt, nếu có một bản sao của PyPy trong thư mục POX chính, nó sẽ sử dụng bản sao đó (để tăng hiệu suất tiềm năng lớn) Nếu không, nó sẽ tìm kiếm những thứ gọi là python3 và quay trở lại python Tất nhiên, cũng có thể gọi trình thông dịch Python mong muốn theo cách thủ công (ví dụ: python3 pox.py) Dòng lệnh POX tùy chọn bắt đầu với các tùy chọn riêng của POX Tiếp theo là tên của một thành phần POX, có thể được theo sau bởi các tùy chọn cho thành phần đó Điều này có thể được theo sau bởi các thành phần khác và các tùy chọn của chúng

2.2.3: Các thành phần của pox

Các thành phần POX về cơ bản là các mô-đun Python với một vài quy ước dành riêng cho POX Chúng được tìm kiếm ở mọi nơi mà Python thường nhìn, cộng với các thư mục pox và ext Do đó,

có thể làm như sau:

./pox.py forwarding.l2_learning

5

Có thể chuyển các tùy chọn cho các thành phần bằng cách chỉ định các tùy chọn sau tên thành phần Chúng được chuyển đến hàm launch() của mô-đun tương ứng Ví dụ: nếu muốn chạy POX dưới dạng bộ điều khiển OpenFlow và địa chỉ điều khiển hoặc cổng mà nó sử dụng, có thể chuyển chúng dưới dạng tùy chọn cho thành phần openflow.01: ./pox.py openflow.of_01 address=10.1.1.1 port=6634 Một số thành phần khác của pox:

- pox/forwardi

ng -

pox/openflo

w: -

pox/proto:

- pox/misc -

pox/log

2.2.4: Pox API

POX chứa một số API để giúp phát triển các ứng dụng điều khiển mạng

Một số ví dụ về API của POX:

• Làm việc với POX: The POX Core object

POX có một đối tượng gọi là "core", đóng vai trò là điểm trung tâm cho phần lớn API của POX Một số chức năng mà nó cung cấp chỉ là các trình bao bọc thuận tiện xung quanh các chức năng khác và một số chức năng là duy nhất Tuy nhiên, một trong những mục đích chính khác của đối tượng cốt lõi là cung cấp điểm hẹn giữa các thành phần Thông thường, thay vì sử dụng các câu lệnh import để một thành phần nhập một thành phần khác

để chúng có thể tương tác, các thành phần thay vào đó sẽ tự "đăng ký" trên đối tượng cốt lõi và các thành phần khác sẽ truy vấn đối tượng cốt lõi Một lợi thế lớn cho phương pháp này là sự phụ thuộc giữa các thành phần không được mã hóa cứng và các thành phần khác nhau hiển thị cùng một giao diện có thể dễ dàng thay thế cho nhau Nghĩ theo một cách khác, điều này cung cấp một giải pháp thay thế cho không gian tên mô-đun thông thường của Python, có phần dễ sắp xếp lại hơn Nhiều mô-đun trong POX sẽ muốn truy cập vào đối tượng cốt lõi Theo quy ước, điều này đang thực hiện bằng cách nhập đối tượng cốt lõi như sau:

“from pox.core import core”

• Làm việc với Addresses: pox.lib.addresses

Địa chỉ IPv4, IPv6 và Ethernet trong POX được đại diện bởi các lớp IPAddr, IPAddr6 và EthAddr của pox.lib.addresses Trong một số trường hợp, các định dạng địa chỉ khác có thể hoạt động (ví dụ: địa chỉ IP chấm-quad), nhưng việc sử dụng các lớp địa chỉ phải luôn hoạt động Ví dụ: khi làm việc với địa chỉ IP:

“from pox.lib.addresses import IPAddr, IPAddr6, EthAddr

ip = IPAddr("192.168.1.1") print str(ip) # Prints "192.168.1.1" print

ip.toUnsignedN() # Convert to network-order unsigned integer 16885952 print ip.raw # Returns a length-four bytes object (a four byte string, more or less)

ip = IPAddr(16885952,networkOrder=True) print

str(ip) # Also prints "192.168.1.1" !”

• Làm việc với packets: pox.lib.packet

Rất nhiều ứng dụng trong POX tương tác với các gói (ví dụ: có thể muốn xây dựng các gói và gửi chúng ra khỏi switch hoặc có thể nhận chúng từ một switch thông qua bản tin OpenFlow: mono: 'ofp_packet_in') Để tạo điều kiện thuận lợi cho việc này, POX có một thư viện để phân tích cú pháp và xây dựng các gói Thư viện có hỗ trợ cho một số loại gói khác nhau Hầu hết các gói tin có một số loại tiêu đề và một số loại tải trọng Một payload thường là một loại gói tin khác Ví dụ: trong POX, người ta thường hoạt động với các gói :mono:'ethernet' thường chứa các gói :mono:'ipv4' (thường chứa các gói :mono:'tcp' ) Tất cả các lớp gói trong POX được tìm thấy trong pox / lib / packet Theo quy ước, nhập thư viện gói POX dưới dạng:

import pox.lib.packet as pkt

• Làm việc với sockets: ioworker pox.lib.ioworker chứa API cấp cao để làm việc với các ổ cắm không đồng bộ trong

POX Gửi là fire-and-forget, dữ liệu nhận được được đệm và callback được kích hoạt khi có sẵn một số

• Làm việc với pcap/libpcap: pxpcap

Thư viện pcap cho Python cung cấp tất cả những điều sau: được duy trì hỗ trợ Windows, Linux và MacOS hỗ trợ cả chụp và tiêm có thể chụp ở mức hợp lý, cùng với việc đáp ứng các mục tiêu này, pxpcap hiển thị các chức năng liên quan đến pcap và pcap khác, chẳng hạn như liệt kê giao diện mạng và đọc / ghi các tệp dấu vết tcpdump / pcap Thư mục pxpcap cũng chứa một vài thành phần POX tiện ích nhỏ có thể dùng làm ví dụ nếu muốn viết mã của riêng mình bằng pxpcap Rõ ràng nhất trong số này có thể được gọi là "pxshark" - nó nắm bắt lưu lượng truy cập từ một giao diện, mổ xẻ nó bằng thư viện gói POX và kết xuất kết quả Có thể chạy

điều này như sau: /pox.py pox.lib.pxpcap interface=eth0

Để tìm hiểu thêm về các API của POX có thể truy cập:

https://noxrepo.github.io/poxdoc/html/#pox-apis

2.2.5: Openflow in POX

Một trong những mục đích chính của việc sử dụng POX là để phát triển các ứng dụng điều khiển OpenFlow - nghĩa là nơi POX hoạt động như một bộ điều khiển cho bộ chuyển mạch OpenFlow (hoặc, theo thuật ngữ thích hợp hơn, đường dẫn dữ liệu OpenFlow)

Vì POX thường được sử dụng với OpenFlow, nên có một cơ chế tải nhu cầu đặc biệt, thường sẽ phát hiện khi đang cố gắng sử dụng OpenFlow và tải lên các thành phần liên quan đến OpenFlow với các giá trị mặc định Nếu demand loading không phát hiện ra rằng đang cố gắng sử dụng nó,

có thể tinh chỉnh thành phần của mình để làm rõ rằng (chỉ cần truy cập core.openflow trong hàm khởi chạy của sẽ làm điều đó) hoặc chỉ cần chỉ định thành phần "openflow" ở đầu dòng lệnh Một phần chính của API POX OpenFlow là đối tượng "nexus" OpenFlow Thông thường, có một đối tượng duy nhất như vậy được đăng ký là core.openflow như một phần của quá trình tải nhu cầu được đề cập ở trên

7

Thành phần POX thực sự giao tiếp với các thiết bị chuyển mạch OpenFlow là openflow.of_01 (01

đề cập đến thực tế là thành phần này nói giao thức dây OpenFlow 0x01) Một lần nữa, tính năng demand-loading thường sẽ khiến thành phần này được khởi tạo với các giá trị mặc định (nghe trên cổng 6633) Tuy nhiên, có thể gọi nó tự động thay vào đó để thay đổi các tùy chọn hoặc nếu muốn chạy nó nhiều lần (ví dụ: để nghe trên TCP và SSL đơn giản hoặc trên nhiều cổng)

Một số ví dụ về openflow trong pox:

• DPIPS in POX

Đặc tả OpenFlow chỉ định rằng mỗi đường dẫn dữ liệu (switches) có ID đường dẫn dữ liệu hoặc DPID duy nhất, là giá trị 64 bit và được truyền từ switch đến bộ điều khiển trong bằng thông báo ofp_switch_features Nó đưa ra rằng 48 trong số các bit đó được dự định là một địa chỉ Ethernet

và 16 bit được "xác định bởi người triển khai" (trong thực tế, chúng thường chỉ bằng không) Vì bản thân bộ chuyển mạch OpenFlow (chủ yếu) là "minh bạch" với mạng, nên không hoàn toàn rõ ràng chính xác địa chỉ Ethernet nào được cho là nằm trong các bit đó, nhưng chúng ta có thể giả định đó là một cái gì đó dành riêng cho switch Vì các đối tượng Kết nối OpenFlow (được thảo luận bên dưới) được gắn với một switch cụ thể, DPID có sẵn trên đối tượng Kết nối bằng thuộc tính dpid Ngoài ra, địa chỉ Ethernet tương ứng có sẵn bằng cách sử dụng thuộc tính eth_addr POX định nghĩa một định dạng DPID cụ thể, được triển khai trong pox.lib.util.dpid_to_str() Khi được truyền DPID trong trường hợp phổ biến là 16 bit "do người triển khai xác định" là 0, kết quả

là một chuỗi trông rất giống địa chỉ Ethernet ngoại trừ thay vì dấu hai chấm phân tách byte (như POX luôn làm cho địa chỉ Ethernet), dấu gạch ngang được sử dụng thay thế

• Giao tiếp với Datapath (Switch)

Khi bản tin đến từ switch, chúng hiển thị trong POX dưới dạng sự kiện có thể viết trình xử lý sự kiện - nói chung có một loại sự kiện tương ứng với từng loại bản tin mà switch có thể gửi

Về cơ bản, có hai cách có thể giao tiếp với đường dẫn dữ liệu trong POX: thông qua Connection, Kết nối cho đường dẫn dữ liệu cụ thể đó hoặc thông qua OpenFlow Nexus đang quản lý đường dẫn dữ liệu đó Có một đối tượng Kết nối cho mỗi đường dẫn dữ liệu được kết nối với POX và thường có một OpenFlow Nexus quản lý tất cả các kết nối Trong cấu hình bình thường, có một mối quan hệ OpenFlow duy nhất có sẵn dưới dạng core.openflow Có rất nhiều sự chồng chéo giữa Kết nối và Nexus Một trong hai có thể được sử dụng để gửi bản tin đến một switch và hầu hết các

sự kiện được nêu ra trên cả hai Đôi khi nó thuận tiện hơn để sử dụng cái này hay cái kia Openflow Event: Respond to switch

Hầu hết các sự kiện liên quan đến OpenFlow được nêu ra để phản hồi trực tiếp với một bản tin nhận được từ một switch Theo hướng dẫn chung, các sự kiện liên quan đến OpenFlow có ba thuộc tính sau:

attribute Type description

connection Connection Connection to the relevant switch (e.g., which sent the

message this event corresponds to)

Dpid Long Datapath ID of relevant switch (use dpid_to_str() to format

it for display)

Ofp ofp_header

subclass

OpenFlow message object that caused this event

See OpenFlow Messages for info on these objects

• Bản tin openflow

Bản tin OpenFlow là cách các thiết bị chuyển mạch OpenFlow giao tiếp với bộ điều khiển Các bản tin được định nghĩa trong Đặc tả OpenFlow Có nhiều phiên bản của đặc điểm kỹ thuật; POX hiện hỗ trợ OpenFlow phiên bản 1.0.0 (phiên bản giao thức dây 0x01) POX chứa các lớp và hằng

số tương ứng với các phần tử của giao thức OpenFlow và chúng được định nghĩa trong tệp pox / openflow / libopenflow_01.py (01 đề cập đến phiên bản giao thức dây) Đối với hầu hết các phần, các tên giống như trong đặc điểm kỹ thuật Trong một vài trường hợp, POX có những cái tên mà chúng tôi nghĩ là tốt hơn Ngoài ra, POX định nghĩa một số lớp không tương ứng với các cấu trúc

cụ thể trong đặc tả (đặc tả không mô tả các cấu trúc chỉ là một tiêu đề OpenFlow đơn giản chỉ được phân biệt bởi thuộc tính loại tin nhắn - POX làm việc) Match Structure

OpenFlow xác định cấu trúc đối sánh - ofp_match - cho phép xác định một tập hợp các tiêu đề cho các gói để khớp với nhau có thể xây dựng kết quả phù hợp từ đầu hoặc sử dụng phương thức xuất

để tạo một kết hợp dựa trên gói hiện có Cấu trúc trận đấu được xác định trong pox / openflow / libopenflow_01.py trong lớp ofp_match Các thuộc tính của nó có nguồn gốc từ các thành viên được liệt kê trong đặc tả OpenFlow:

Attribute Meaning

in_port Switch port number the packet arrived on

dl_src Ethernet source address

dl_dst Ethernet destination address

dl_vlan VLAN ID

dl_vlan_pcp VLAN priority

dl_type Ethertype / length (e.g 0x0800 = IPv4)

nw_tos IP TOS/DS bits

nw_proto IP protocol (e.g., 6 = TCP) or lower 8 bits of ARP opcode

9

nw_src IP source address

nw_dst IP destination address

tp_src TCP/UDP source port

tp_dst TCP/UDP destination port

• Openflow Action

Hành động OpenFlow được áp dụng cho các gói phù hợp với quy tắc được cài đặt tại đường dẫn

dữ liệu Các đoạn mã được tìm thấy ở đây có thể được tìm thấy trong libopenflow_01.py trong pox / openflow

Để có thể có nhiều thông tin về POX hoặc đầy đủ các thành phần, tính năng và các câu lệnh của

POX, truy cập: https://noxrepo.github.io/pox-doc/html/#

2.2.6: Một số hình ảnh chạy POX thực tế

Ta tạo 1 topology gồm 1 controller , 2 switches và 4 hosts (như hình bên dưới)

Đầu tiên, ping các host với nhau ( khi chưa kích hoạt controller) sử dụng lệnh pingall Ta thấy tỉ lệ các packets drop là 100%