Eksperyment w ramach Laboratorium SDN PL-LAB2020 Aplikacja firewall działająca w warstwie sieciowego systemu operacyjnego infrastruktury SDN Raport Wersja: 1.0 PCSS, 2016 Praca współfinansowana przez Narodowe Centrum Badań i Rozwoju w ramach Europejskich Funduszy Strukturalnych, nr umowy POIG.02.03.01-00-104/13 (Projekt PL-LAB2020) oraz nr umowy POIG.01.01.02-00-045/09, (Projekt Inżynieria Internetu Przyszłości).
Spis treści 1. Cel eksperymentu... 3 2. Rezerwacja eksperymentu w portalu PL-LAB2020... 3 3. Konfiguracja urządzeń biorących udział w eksperymencie... 4 1.1 Instalacja kontrolera sieci SDN... 4 1.2 Instalacja aplikacji sieciowej typu firewall... 5 1.3 Konfiguracja przełączników OpenFlow... 5 1.4 Uruchomienie klientów końcowych hostów... 7 4. Przeprowadzenie eksperymentu... 7 5. Wyniki eksperymentu... 13 6. Podsumowanie... 13 7. Referencje... 14-2 -
1. Cel eksperymentu W ramach eksperymentu w sieci badawczej PL-LAB2020 przeprowadzono testy aplikacji działającej w warstwie sieciowego systemu operacyjnego infrastruktury SDN. Celem bezpośrednim przeprowadzonego eksperymentu były testy funkcjonalne aplikacji sieciowej simple_firewall (zapora sieciowa). W szczególności została przetestowana konfiguracja zapory sieciowej do pracy z ruchem UDP zarówno z poziomu pliku konfiguracyjnego, jak również z użyciem interfejsu programowego (REST API). Ponadto celami pośrednimi eksperymentu były: Testy procesu rezerwacji eksperymentu w Portalu PL-LAB, Testy opóźnienia w przesyłaniu pakietów na warstwie przekazu danych pomiędzy dwoma ośrodkami badawczymi: Poznańskim Centrum Superkomputerowo-Sieciowym oraz Politechniką Warszawską. W celu przeprowadzenia eksperymentu zostało w sieci PL-LAB2020 skonfigurowane rozproszone laboratorium badawcze obejmujące zasoby sieciowo-obliczeniowe. 2. Rezerwacja sieci eksperymentu w Portalu PL-LAB Na potrzeby eksperymentu w Portalu PL-LAB zarezerwowano zasoby sieciowo-obliczeniowo w dwóch ośrodkach: Politechnice Warszawskiej, oraz Poznańskim Centrum Superkomputerowo-Sieciowym. Eksperyment o identyfikatorze #418 zestawiony w Portalu obrazuje Rysunek 1. Rysunek 1. Eksperyment w Portalu PL-LAB - 3 -
Lista urządzeń biorących udział w eksperymencie: 1) Politechnika Warszawska a) 2x serwer DL380 Gen9 (OS: Ubuntu 14.04) host1 oraz kontroler sieci SDN z aplikacją sieciową b) Przełącznik OpenFlow (v.1.3) Pica8-3922 2) Poznańskie Centrum Superkomputerowo-Sieciowe a) 1x serwer DL380 Gen9 (OS: Ubuntu 14.04) host2 b) Przełącznik OpenFlow (v.1.3) NowiSwitch-2128 Między węzłami PL-LAB2020 w PCSS i PW zarezerwowano łącze o przepływności 150 Mb/s. 3. Konfiguracja urządzeń biorących udział w eksperymencie W procesie konfiguracji urządzeń sieciowych i serwerów zostało stworzone środowisko eksperymentu składające się z dwóch hostów, dwóch przełączników OpenFlow, oraz kontrolera sieci z aplikacją sieciową simple_firewall jak to przedstawiono na poniższym rysunku (Rysunek 2). Rysunek 2. Środowisko eksperymentu topologia logiczna W poniższych podrozdziałach przedstawiono etapy konfiguracji eksperymentu. 3.1 Instalacja kontrolera sieci SDN Rolę kontrolera sieci SDN, działającej w oparciu o protokół OpenFlow 1.3 pełni aplikacja Ryu [Ryu]. Na potrzeby eksperymentu użyto wersji 4.8 tego oprogramowania. Przeprowadzono instalację według instrukcji dostępnej na stronie twórców aplikacji [Ryu-install]. Kontroler (wraz z aplikacją simple_firewall pracującą w warstwie sieciowego systemu operacyjnego) posiada globalny widok na sieć definiowaną programowo. Kontroler SDN/OpenFlow zainstalowano na dedykowanym serwerze z system operacyjnym Ubuntu 14.04. Sprawdzenie zainstalowanej wersji kontrolera sdn@s14-2:~$ ryu --version ryu 4.8 sdn@s14-2:~$ ryu-manager --version ryu-manager 4.8-4 -
3.2 Instalacja aplikacji sieciowej typu firewall Aplikacja sieciowa simple_firewall zaprojektowana oraz zaimplementowana w PCSS i dostępna pod adresem [simple_firewall] jest dedykowana do pracy z kontrolerem Ryu. Pod wskazanym adresem znajduje się rozbudowany opis aplikacji, kod źródłowy, oraz opis procesu instalacji i konfiguracji. Aplikacja simple_firewall jest oparta na przykładowej aplikacji rest_firewall uzupełnia ją jednak o elementy przekazywania pakietów IP w oparciu o statyczną tablicę routingu, oraz obsługę ramek ARP. Instalacja aplikacji sprowadza się do kilku prostych kroków: Instalacja zależności $sudo apt-get install python-eventlet python-routes python-webob python-paramiko git Pobranie kodu źródłowego ~/ryu/ryu/app$ git clone https://github.com/lukogr/simple_firewall Konfiguracja aplikacji w pliku simple_firewall_conf.py Konfiguracja w formie pliku JSON obejmuje zasady routingu pakietów w sieci na warstwie L3 (IP) - w sekcji topology_conf, oraz zasady zapory sieciowej - w sekcji firewall_rules. Zasady zapory (typu ALLOW/DENY) są wczytywane przez aplikację simple_firewall z chwilą uruchomienia. Nowo wprowadzone do pliku reguły wymagają restartu aplikacji (w czasie działania aplikacji możliwe jest też użycie interfejsu Rest API do konfiguracji reguł firewalla). Sekcja topology_conf posiada format statycznej tablicy routingu i definiuje sposób przesyłania pakietów IP na każdym z przełączników OpenFlow identyfikowanych poprzez identyfikator DPID (ang. Data Path ID). Dokumentacja aplikacji dostępna na stronie [simple_firewall] definiuje możliwe ustawienia reguł filtrowania pakietów w sekcji firewall_rules. Uruchomienie aplikacji simple_firewall Po pomyślnym zainstalowaniu aplikacji simple_firewall należy ją uruchomić poleceniem: ~/ryu$ PYTHONPATH=../bin/ryu-manager --verbose ryu/app/simple_firewall/simple_firewall.py Po uruchomieniu simple_firewall w konsoli wyświetlane są wszystkie zdarzenia dotyczące kontrolera oraz samej aplikacji takie jak: podłączenie przełączników OpenFlow, pojawienie się nowych, nieznanych strumieni (ang. flow) oraz informacje o zablokowanych strumieniach ruchu. 3.3 Konfiguracja przełączników OpenFlow Przełączniki OpenFlow zostały skonfigurowane do pracy z kontrolerem sieci SDN dostępnym pod adresem 10.140.0.141 na porcie 6633 (domyślny port dla protokołu OpenFlow). Pica8-3922 Konfiguracja bridge br0 do pracy z kontrolerem sieci admin@picos-ovs$ovs-vsctl add-br br0 -- set bridge br0 datapath_type=pica8-5 -
admin@picos-ovs$ovs-vsctl set-controller br0 tcp:10.140.0.141:6633 Konfiguracja portów warstwy przekazu danych admin@picos-ovs$ovs-vsctl add-port br0 te-1/1/45 -- set interface te-1/1/45 type=pica8 options:link_speed=1g admin@picos-ovs$ovs-ofctl mod-port br0 te-1/1/45 up admin@picos-ovs$ovs-vsctl add-port br0 te-1/1/46 -- set interface te-1/1/46 type=pica8 options:link_speed=1g admin@picos-ovs$ovs-ofctl mod-port br0 te-1/1/46 up Sprawdzenie konfiguracji brigde admin@picos-ovs$ovs-ofctl show br0 OFPT_FEATURES_REPLY (OF1.4) (xid=0x2): dpid:5e3e486e730002fe n_tables:254, n_buffers:256 capabilities: FLOW_STATS TABLE_STATS PORT_STATS GROUP_STATS OFPST_PORT_DESC reply (OF1.4) (xid=0x3): 45(te-1/1/45): addr:48:6e:73:00:02:fe config: 0 state: LINK_UP current: 1GB-FD FIBER advertised: 1GB-FD 10GB-FD FIBER supported: 100MB-HD 100MB-FD 1GB-FD 10GB-FD FIBER AUTO_NEG speed: 1000 Mbps now, 10000 Mbps max 46(te-1/1/46): addr:48:6e:73:00:02:fe config: 0 state: LINK_UP current: 1GB-FD FIBER advertised: 1GB-FD 10GB-FD FIBER supported: 100MB-HD 100MB-FD 1GB-FD 10GB-FD FIBER AUTO_NEG speed: 1000 Mbps now, 10000 Mbps max LOCAL(br0): addr:48:6e:73:00:02:fe config: 0 state: LINK_UP current: 10MB-FD COPPER supported: 10MB-FD COPPER speed: 10 Mbps now, 10 Mbps max Noviswitch-2128 Konfiguracja do pracy z kontrolerem sieci noviswitch# set config controller controllergroup gr_a controllerid ID_1 priority 1 ipaddr 10.140.0.141 port 6633 security none Sprawdzenie połączenia przełącznik-kontroler SDN/OpenFlow noviswitch# show config controller "*" = Controller currently connected +-----------------------------------------------------------------------------+ Group gr_a Role - Equal +-----------------------------------------------------------------------------+ Prio ControllerId Auxid Auxprio Ipaddress Port Sec Ver Inb 1 ID_1 0 0 *10.140.0.141 6633 none any off +-----------------------------------------------------------------------------+ - 6 -
Sprawdzenie statusu przełącznika noviswitch# show status switch Hardware serial number: NS2128-00223D5A0018 Kernel : 2.6.32-504.16.2.el6.x86_64 Switch uptime : 7 days 21:28:21 Overall CPU(%) usage : 0.012304 Overall Mem(KB) usage : 2212892 Overall SSD(KB) usage : 1167368 OF1 port link status : up OF2 port link status : down CLI port link status : up -- latest (current) -- NoviWare-OPE version: NW400.0.1 c7059c322ea9f783d47a17e9bd4a4b27186cf1c9 NoviWare-PPE version: NW400.0.1 5df028eca4e47226b9d06ce55ec1961c276e07cc EZDriver version: 8.46a -- previous -- NoviWare-OPE version: NW300.0.7 d60246d2aa740a7c2622b68e08541b74ff92bdeb NoviWare-PPE version: NW300.0.7 c14e0e29ea57682212d80a5bcb700ee9ebd8a59d EZDriver version: 8.46a -- default (recovery) -- NoviWare-OPE version: NW300.0.2 ad2867b9139c634eb211d2ca191988ffc7945852 NoviWare-PPE version: NW300.0.2 8b4dd7258e6cb00e1126ec5d818e9beccb6785aa EZDriver version: 8.46a 3.4 Uruchomienie klientów końcowych hostów Na potrzeby eksperymentu zarezerwowano dwa serwery pełniące funkcje klientów końcowych dołączonych do infrastruktury SDN składającej się z dwóch przełączników. Na serwerach zainstalowano system operacyjny Ubuntu w wersji 14.04. 4. Przeprowadzenie eksperymentu Sprawdzenie połączenia pomiędzy hostami (PW-PCSS) Domyślnie aplikacja simple_firewall jest skonfigurowana do pracy z ruchem ICMP (ping) pomiędzy adresami 192.168.0.1 (host1 - PW) oraz 192.168.20.2 (host2 - PCSS), oraz blokuje każdy inny nieznany ruch sieciowy. Zawartość pliku konfiguracyjnego simple_firewall_conf.py zezwalająca na dwukierunkową transmisję ICMP pomiędzy hostami: firewall_rules = [ "priority":"100", "nw_src":"192.168.20.2/24", "nw_dst":"192.168.0.1/24", "nw_proto":"icmp", "actions":"allow" "priority":"100", "nw_src":"192.168.0.1/24", "nw_dst":"192.168.20.2/24", "nw_proto":"icmp", - 7 -
] "actions":"allow" Ponadto aplikacja simple_firewall buduje swoją wewnętrzną tablicę ARP, zapamiętując adresy MAC skojarzone z interfejsami oraz instaluje odpowiednie wpisy w tablicy przełączania (flow table) przełączników OpenFlow unikając akcji packet_in dla ramek z zapytaniami ARP. W celu sprawdzenia połączenia na warstwie przekazu danych pomiędzy hostami host1 oraz host2 uruchomiono aplikację ping: sdn@s14-1:~$ ping 192.168.20.2 PING 192.168.20.2 (192.168.20.2) 56(84) bytes of data. 64 bytes from 192.168.20.2: icmp_seq=1 ttl=64 time=4.59 ms 64 bytes from 192.168.20.2: icmp_seq=2 ttl=64 time=4.57 ms 64 bytes from 192.168.20.2: icmp_seq=3 ttl=64 time=4.56 ms Konfiguracja reguł zapory sieciowej Do konfiguracji reguł zapory sieciowej można użyć dowolnego klienta REST API. W trakcie opisywanego eksperymentu użyto aplikacji Postman [Post]. Przykładowy wpis w formacie JSON wysyłany w komunikacie POST interfejsu REST API, definiujący regułę ALLOW (pozwól) dla ruchu UDP na port 2222 przesyłanego z host1 do host2: POST http://10.140.0.141:8080/firewall/rules/all } "priority":"100", "nw_src":"192.168.0.1/24", "nw_dst":"192.168.20.2/24", "nw_proto":"udp", "tp_dst": "2222", "actions":"allow" Wyświetlenie reguł zapory GET http://10.140.0.141:8080/firewall/rules/all [ "access_control_list": [ "rules": [ "priority": 1, "dl_type": "ARP", "actions": "ALLOW", "dl_dst": "5c:b9:01:8f:08:40", "rule_id": 0, "in_port": 6 "priority": 1, "dl_type": "ARP", "actions": "ALLOW", "dl_dst": "00:11:0a:69:e7:1c", "rule_id": 0, "in_port": 8-8 -
"priority": 100, "dl_type": "IPv4", "nw_proto": "UDP", "tp_dst": 2222, "nw_dst": "192.168.20.0/255.255.255.0", "nw_src": "192.168.0.0/255.255.255.0", "rule_id": 3, "actions": "ALLOW" "priority": 100, "dl_type": "IPv4", "nw_proto": "ICMP", "nw_dst": "192.168.0.0/255.255.255.0", "nw_src": "192.168.20.0/255.255.255.0", "rule_id": 1, "actions": "ALLOW" "priority": 100, "dl_type": "IPv4", "nw_proto": "ICMP", "nw_dst": "192.168.20.0/255.255.255.0", "nw_src": "192.168.0.0/255.255.255.0", "rule_id": 2, "actions": "ALLOW" } ] } ], "switch_id": "000000223d5a0019" "access_control_list": [ "rules": [ "priority": 1, "dl_type": "ARP", "actions": "ALLOW", "dl_dst": "5c:b9:01:8f:08:40", "rule_id": 0, "in_port": 46 "priority": 1, "dl_type": "ARP", "actions": "ALLOW", "dl_dst": "00:11:0a:69:e7:1c", "rule_id": 0, "in_port": 45 "priority": 100, "dl_type": "IPv4", "nw_proto": "UDP", "tp_dst": 2222, "nw_dst": "192.168.20.0/255.255.255.0", "nw_src": "192.168.0.0/255.255.255.0", "rule_id": 3, "actions": "ALLOW" - 9 -
] "priority": 100, "dl_type": "IPv4", "nw_proto": "ICMP", "nw_dst": "192.168.0.0/255.255.255.0", "nw_src": "192.168.20.0/255.255.255.0", "rule_id": 1, "actions": "ALLOW" "priority": 100, "dl_type": "IPv4", "nw_proto": "ICMP", "nw_dst": "192.168.20.0/255.255.255.0", "nw_src": "192.168.0.0/255.255.255.0", "rule_id": 2, "actions": "ALLOW" } ] } ], "switch_id": "5e3e486e730002fe" } Sprawdzenie tablic przełączania na przełącznikach OpenFlow: NoviSwitch noviswitch# show status flow tableid all [##################################################] 100% Flow entries [FLOW_ENTRIES] Total entries: 4 [TABLE 0] Total entries: 4 [FLOW_ID4] Timestamp = Tue Dec 20 08:32:12 2016 ofp_version = 4 ControllerGroup = gr_a ControllerId = ID_1 Priority = 100 Idle_timeout = 0 Hard_timeout = 0 Packet_count = 0 Byte_count = 0 Cookie = 3 Send_flow_rem = false [MATCHFIELDS] OFPXMT_OFB_ETH_TYPE = 0x800 OFPXMT_OFB_IPV4_SRC = 192.168.0.0 & 255.255.255.0 OFPXMT_OFB_IPV4_DST = 192.168.20.0 & 255.255.255.0 OFPXMT_OFB_IP_PROTO = 17 OFPXMT_OFB_UDP_DST = 2222 [INSTRUCTIONS] [OFPIT_APPLY_ACTIONS] [ACTIONS] [OFPAT_OUTPUT] port = 6 [FLOW_ID1] Timestamp = Tue Dec 20 08:32:08 2016 ofp_version = 4 ControllerGroup = gr_a ControllerId = ID_1 Priority = 0-10 -
Idle_timeout = 0 Hard_timeout = 0 Packet_count = 0 Byte_count = 0 Cookie = 0 Send_flow_rem = false [MATCHFIELDS] all match [INSTRUCTIONS] [OFPIT_APPLY_ACTIONS] [ACTIONS] [OFPAT_OUTPUT] port = ctrl mlen = 128 [FLOW_ID2] Timestamp = Tue Dec 20 08:32:08 2016 ofp_version = 4 ControllerGroup = gr_a ControllerId = ID_1 Priority = 100 Idle_timeout = 0 Hard_timeout = 0 Packet_count = 0 Byte_count = 0 Cookie = 1 Send_flow_rem = false [MATCHFIELDS] OFPXMT_OFB_ETH_TYPE = 0x800 OFPXMT_OFB_IPV4_SRC = 192.168.20.0 & 255.255.255.0 OFPXMT_OFB_IPV4_DST = 192.168.0.0 & 255.255.255.0 OFPXMT_OFB_IP_PROTO = 1 [INSTRUCTIONS] [OFPIT_APPLY_ACTIONS] [ACTIONS] [OFPAT_OUTPUT] port = 8 [FLOW_ID3] Timestamp = Tue Dec 20 08:32:08 2016 ofp_version = 4 ControllerGroup = gr_a ControllerId = ID_1 Priority = 100 Idle_timeout = 0 Hard_timeout = 0 Packet_count = 0 Byte_count = 0 Cookie = 2 Send_flow_rem = false [MATCHFIELDS] OFPXMT_OFB_ETH_TYPE = 0x800 OFPXMT_OFB_IPV4_SRC = 192.168.0.0 & 255.255.255.0 OFPXMT_OFB_IPV4_DST = 192.168.20.0 & 255.255.255.0 OFPXMT_OFB_IP_PROTO = 1 [INSTRUCTIONS] [OFPIT_APPLY_ACTIONS] [ACTIONS] [OFPAT_OUTPUT] port = 6 [FLOW_ID5] Timestamp = Tue Dec 20 08:40:30 2016 ofp_version = 4 ControllerGroup = gr_a ControllerId = ID_1 Priority = 1-11 -
Idle_timeout = 0 Hard_timeout = 0 Packet_count = 77 Byte_count = 4928 Cookie = 0 Send_flow_rem = false [MATCHFIELDS] OFPXMT_OFB_IN_PORT = 6 OFPXMT_OFB_ETH_DST = 5c:b9:01:8f:08:40 OFPXMT_OFB_ETH_TYPE = 0x806 [INSTRUCTIONS] [OFPIT_APPLY_ACTIONS] [ACTIONS] [OFPAT_OUTPUT] port = 8 [FLOW_ID6] Timestamp = Tue Dec 20 08:40:30 2016 ofp_version = 4 ControllerGroup = gr_a ControllerId = ID_1 Priority = 1 Idle_timeout = 0 Hard_timeout = 0 Packet_count = 77 Byte_count = 4928 Cookie = 0 Send_flow_rem = false [MATCHFIELDS] OFPXMT_OFB_IN_PORT = 8 OFPXMT_OFB_ETH_DST = 00:11:0a:69:e7:1c OFPXMT_OFB_ETH_TYPE = 0x806 [INSTRUCTIONS] [OFPIT_APPLY_ACTIONS] [ACTIONS] [OFPAT_OUTPUT] port = 6 Pica8 admin@picos-ovs$ovs-ofctl dump-flows br0 OFPST_FLOW reply (OF1.4) (xid=0x2): cookie=0x0, duration=1460.254s, table=0, n_packets=n/a, n_bytes=4792, priority=1,arp,in_port=46,dl_dst=5c:b9:01:8f:08:40 actions=output:45 cookie=0x0, duration=1460.252s, table=0, n_packets=n/a, n_bytes=4732, priority=1,arp,in_port=45,dl_dst=00:11:0a:69:e7:1c actions=output:46 cookie=0x3, duration=1532.221s, table=0, n_packets=n/a, n_bytes=31232, priority=100,udp,nw_src=192.168.0.0/24,nw_dst=192.168.20.0/24,tp_dst=2222 actions=output:46 cookie=0x0, duration=1537.924s, table=0, n_packets=n/a, n_bytes=31488, priority=0 actions=controller:128 cookie=0x1, duration=1537.917s, table=0, n_packets=n/a, n_bytes=36642, priority=100,icmp,nw_src=192.168.20.0/24,nw_dst=192.168.0.0/24 actions=output:45 cookie=0x2, duration=1537.914s, table=0, n_packets=n/a, n_bytes=0, priority=100,icmp,nw_src=192.168.0.0/24,nw_dst=192.168.20.0/24 actions=output:46 Sprawdzenie poprawności działania aplikacji dla ruchu UDP Poprawność działania reguł firewalla dla ruchu UDP można sprawdzić dowolnym programowym generatorem ruchu. W przypadku opisywanego eksperymentu użyto prostego generatora [simple_gen] zaimplementowanego w PCSS. $ git clone https://github.com/lukogr/simple_udp_gen $ python simple_udp_gen.py 2222 3333-12 -
Powyższe wywołanie uruchamia dwa strumienie ruchu UDP na portach o numerach: 2222 oraz 3333. Ponieważ simple_firewall nie jest skonfigurowany do pracy z UDP:3333, ruch ten zostaje zablokowany na przełączniku Pica8 (pierwszy przełącznik dostępowy), a fakt ten odnotowany w konsoli aplikacji. Rysunek 3. Informacja w konsoli aplikacji o ruchu zablokowanym (UDP:3333) Datagramy UDP przesyłane z host1 do portu 2222 obserwowane na host2 w PCSS: mgmt@1-srv1:~$ sudo tcpdump -i p2p1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on p2p1, link-type EN10MB (Ethernet), capture size 65535 bytes 14:25:57.530965 IP 192.168.0.1.33578 > 192.168.20.2.2222: UDP, length 1 14:25:57.530998 IP 192.168.20.2 > 192.168.0.1: ICMP 192.168.20.2 udp port 2222 unreachable, length 3 5. Wyniki eksperymentu Eksperyment zestawiony przez Portal w sieci badawczej PL-LAB2020 umożliwił zweryfikowanie poprawności działania aplikacji simple_firewall. Testy aplikacji z użyciem protokołów ICMP i ARP (ping), oraz programowego generatora ruchu UDP pokazały poprawność działania zapory ogniowej. Zmierzone za pomocą aplikacji ping opóźnienie RTT na ścieżce przesyłania danych pomiędzy PCSS a PW wyniosło ok. 4ms. Zweryfikowano przy tym transparentność urządzeń użytych do konfiguracji środowiska badawczego (Juniper ACX) na warstwie 2 ramki Ethernet przesyłane były od końca do końca (PCSS-PW) bez zmiany źródłowego i docelowego adresu MAC. Jednym z pośrednich wyników eksperymentu była także sesja debugging w formie konsultacji z deweloperami z firmy NoviSwitch na temat obsługi akcji protokołu OpenFlow typu NORMAL (niewspierana w przełącznikach NoviSwitch-2128), oraz procedur zapisu zdarzeń do pliku log. Zasugerowano przy tym poprawkę dodającą do każdego zdarzenia pełną informację o dacie i czasie zajścia zostanie ona dodana w następnej wersji oprogramowania NoviWare. 6. Podsumowanie W raporcie opisano eksperyment SDN przeprowadzony w sieci PL-LAB2020, w szczególności cel i zakres eksperymentu oraz proces instalacji i konfiguracji urządzeń oraz użytych modułów programowych. W czasie testów infrastruktura sieci SDN działała w oparciu o protokół OpenFlow w wersji 1.3. Opracowanie nie stanowi przy tym przewodnika po technologii SDN wszelkie szczegóły dotyczące protokołu OpenFlow są dostępne na stronach organizacji ONF [OpenFlow]. - 13 -
7. Referencje [Ryu] https://osrg.github.io/ryu/ [Ryu-install] https://github.com/osrg/ryu/wiki/openflow_tutorial [simple_firewall] https://github.com/lukogr/simple_firewall [simple_gen] https://github.com/lukogr/simple_udp_gen [OpenFlow] https://www.opennetworking.org/ja/sdn-resources-ja/onf-specifications/openflow [Post] https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop - 14 -