Eksperyment w ramach Laboratorium SDN PL-LAB2020

Transkrypt

1 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 /13 (Projekt PL-LAB2020) oraz nr umowy POIG /09, (Projekt Inżynieria Internetu Przyszłości).

2 Spis treści 1. Cel eksperymentu Rezerwacja eksperymentu w portalu PL-LAB Konfiguracja urządzeń biorących udział w eksperymencie Instalacja kontrolera sieci SDN Instalacja aplikacji sieciowej typu firewall Konfiguracja przełączników OpenFlow Uruchomienie klientów końcowych hostów Przeprowadzenie eksperymentu Wyniki eksperymentu Podsumowanie Referencje

3 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 -

4 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) Pica ) 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 Sprawdzenie zainstalowanej wersji kontrolera sdn@s14-2:~$ ryu --version ryu 4.8 sdn@s14-2:~$ ryu-manager --version ryu-manager

5 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 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 na porcie 6633 (domyślny port dla protokołu OpenFlow). Pica Konfiguracja bridge br0 do pracy z kontrolerem sieci admin@picos-ovs$ovs-vsctl add-br br0 -- set bridge br0 datapath_type=pica8-5 -

6 set-controller br0 tcp: :6633 Konfiguracja portów warstwy przekazu danych add-port br0 te-1/1/45 -- set interface te-1/1/45 type=pica8 options:link_speed=1g mod-port br0 te-1/1/45 up add-port br0 te-1/1/46 -- set interface te-1/1/46 type=pica8 options:link_speed=1g mod-port br0 te-1/1/46 up Sprawdzenie konfiguracji brigde 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, 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, 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 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 * none any off

7 Sprawdzenie statusu przełącznika noviswitch# show status switch Hardware serial number: NS D5A0018 Kernel : el6.x86_64 Switch uptime : 7 days 21:28:21 Overall CPU(%) usage : Overall Mem(KB) usage : Overall SSD(KB) usage : OF1 port link status : up OF2 port link status : down CLI port link status : up -- latest (current) -- NoviWare-OPE version: NW c7059c322ea9f783d47a17e9bd4a4b27186cf1c9 NoviWare-PPE version: NW df028eca4e47226b9d06ce55ec1961c276e07cc EZDriver version: 8.46a -- previous -- NoviWare-OPE version: NW d60246d2aa740a7c2622b68e08541b74ff92bdeb NoviWare-PPE version: NW c14e0e29ea d80a5bcb700ee9ebd8a59d EZDriver version: 8.46a -- default (recovery) -- NoviWare-OPE version: NW ad2867b9139c634eb211d2ca191988ffc NoviWare-PPE version: NW b4dd7258e6cb00e1126ec5d818e9beccb6785aa 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 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 (host1 - PW) oraz (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":" /24", "nw_dst":" /24", "nw_proto":"icmp", "actions":"allow" "priority":"100", "nw_src":" /24", "nw_dst":" /24", "nw_proto":"icmp", - 7 -

8 ] "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 PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=64 time=4.59 ms 64 bytes from : icmp_seq=2 ttl=64 time=4.57 ms 64 bytes from : 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 } "priority":"100", "nw_src":" /24", "nw_dst":" /24", "nw_proto":"udp", "tp_dst": "2222", "actions":"allow" Wyświetlenie reguł zapory GET [ "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 -

9 "priority": 100, "dl_type": "IPv4", "nw_proto": "UDP", "tp_dst": 2222, "nw_dst": " / ", "nw_src": " / ", "rule_id": 3, "actions": "ALLOW" "priority": 100, "dl_type": "IPv4", "nw_proto": "ICMP", "nw_dst": " / ", "nw_src": " / ", "rule_id": 1, "actions": "ALLOW" "priority": 100, "dl_type": "IPv4", "nw_proto": "ICMP", "nw_dst": " / ", "nw_src": " / ", "rule_id": 2, "actions": "ALLOW" } ] } ], "switch_id": " d5a0019" "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": " / ", "nw_src": " / ", "rule_id": 3, "actions": "ALLOW" - 9 -

10 ] "priority": 100, "dl_type": "IPv4", "nw_proto": "ICMP", "nw_dst": " / ", "nw_src": " / ", "rule_id": 1, "actions": "ALLOW" "priority": 100, "dl_type": "IPv4", "nw_proto": "ICMP", "nw_dst": " / ", "nw_src": " / ", "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: 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 = & OFPXMT_OFB_IPV4_DST = & 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: ofp_version = 4 ControllerGroup = gr_a ControllerId = ID_1 Priority =

11 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: 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 = & OFPXMT_OFB_IPV4_DST = & OFPXMT_OFB_IP_PROTO = 1 [INSTRUCTIONS] [OFPIT_APPLY_ACTIONS] [ACTIONS] [OFPAT_OUTPUT] port = 8 [FLOW_ID3] Timestamp = Tue Dec 20 08:32: 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 = & OFPXMT_OFB_IPV4_DST = & OFPXMT_OFB_IP_PROTO = 1 [INSTRUCTIONS] [OFPIT_APPLY_ACTIONS] [ACTIONS] [OFPAT_OUTPUT] port = 6 [FLOW_ID5] Timestamp = Tue Dec 20 08:40: ofp_version = 4 ControllerGroup = gr_a ControllerId = ID_1 Priority =

12 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: 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= s, 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= s, 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= s, table=0, n_packets=n/a, n_bytes=31232, priority=100,udp,nw_src= /24,nw_dst= /24,tp_dst=2222 actions=output:46 cookie=0x0, duration= s, table=0, n_packets=n/a, n_bytes=31488, priority=0 actions=controller:128 cookie=0x1, duration= s, table=0, n_packets=n/a, n_bytes=36642, priority=100,icmp,nw_src= /24,nw_dst= /24 actions=output:45 cookie=0x2, duration= s, table=0, n_packets=n/a, n_bytes=0, priority=100,icmp,nw_src= /24,nw_dst= /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 $ python simple_udp_gen.py

13 Powyższe wywołanie uruchamia dwa strumienie ruchu UDP na portach o numerach: 2222 oraz 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 bytes 14:25: IP > : UDP, length 1 14:25: IP > : ICMP 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]

14 7. Referencje [Ryu] [Ryu-install] [simple_firewall] [simple_gen] [OpenFlow] [Post]