SOFTWARE-DEFINED NETWORKING

Transkript

1 SOFTWARE-DEFINED NETWORKING Magne Hjertaker 13HKOM 31. mai 2016

2 Dokumentkontroll Rapportens tittel: Software-Defined Networking Forfatter(e): Magne Hjertaker Høgskolens veileder: Eventuelle Merknader: Dato/Versjon /v1.00 Rapportnummer: Studieretning: 13HKOM Antall sider m/vedlegg 68 Gradering: Oppdragsgiver: Høgskolen i Bergen Oppdragsgivers kontaktperson(er) (inklusiv kontaktinformasjon): Oppdragsgivers referanse: Knut Øvsthus Revisjon Dato Status Utført av v Første utkast Magne Hjertaker v Revidert utkast Magne Hjertaker v Info om LAB-miljø Magne Hjertaker v STP info Magne Hjertaker v OpenFlow generelt Magne Hjertaker v LAB utførelser Magne Hjertaker v Figurer og LAB dokumentasjon Magne Hjertaker v Gjennomgang Magne Hjertaker v Diskusjon Magne Hjertaker v Korrektur Magne Hjertaker v NFV info Magne Hjertaker v Kilder Magne Hjertaker v Reverse path forwarding LAB Magne Hjertaker v REST LAB Magne Hjertaker v Ordne struktur på innhold Magne Hjertaker v Kravspesifikasjon korrektur Magne Hjertaker v Ordne overskrifter og format kildehenvisninger Magne Hjertaker v Endringer i white box kapittel, innledning Magne Hjertaker v Diskusjon: overgang Magne Hjertaker v Korrektur Magne Hjertaker v Sammendrag Magne Hjertaker v Gjennomgang, finskriving Magne Hjertaker v Klargjøring innlevering Magne Hjertaker

3 Forord SDN var et begrep jeg hadde hørt mye om, men som jeg visste lite om. Jeg hadde fått med meg at det var en spennende og annerledes måte å styre et nettverk på, men ikke så mye annet. Jeg spurte noen veiledere om muligheten til å bruke bacheloroppgaven min for å se nærmere på dette, og Knut Øvsthus stilte seg med en gang til rådighet som min veileder. Det tok litt tid før jeg fikk spisset inn en problemstilling, men under hele prosjektet ble mye tid brukt på research og testing med relevant teknologi, og jeg har lært svært mye om temaet gjennom denne oppgaven. Takk til Stian Øvrevåge for sin faglige innsikt som har gitt meg stor interesse for faget, og for veiledning og samtaler underveis i prosessen. Takk til min kone og min datter for all støtte jeg har fått, og for å gi meg mye rom til studiene midt i en travel familiehverdag. En spesielt stor takk til Knut Øvsthus for å gi meg muligheten til å ta denne oppgaven, god hjelp, og for mange gode diskusjoner. Rev: v1.00 3(68)

4 Sammendrag Software-Defined Networking (SDN) er et nettverkskonsept som skiller software fra hardwarefunksjoner i en nettverksenhet (en switch). Kontrollogikken (the control plane) flyttes over i en sentral enhet, en controller. Dette gjør det enklere å administrere store nettverk, og det introduserer muligheten til å plassere tidligere fysiske enheter (som for eksempel en brannmur) over i software for implementasjon hvor som helst i nettverket. Denne oppgaven har blitt brukt for å få et overblikk over SDN-teknologi. Som problemstilling har det blitt sett på om SDN teknologi kan brukes i normale bedriftsnettverk i dag. En controller har et sørgående og et nordgående interface. Det sørgående vender mot the forwarding plane eller infrastructure layer, og her befinner switchene seg, som tar av seg den faktiske videresendingen av pakker. Protokollen med mest støtte er protokollen OpenFlow, som utvikles av Open Networking Foundation. Det har blitt valgt å fokusere på OpenFlow 1.3 som SDN protokoll i denne oppgaven, som har mye støtte både fra switch-leverandører og ulik SDN-programvare. Det nordgående interface går mot applikasjoner som kan få tilgang til nettverkstopologien via API, og gjøre endringer. På denne måten blir nettverket programmerbart. Kontrolleren tar har en fullstendig topologioversikt over nettverket og deler ut regler i form av oppføringer i switchens flow table. Dersom en switch får inn en pakke som ikke finner treff i den lokale flow table, vil pakken bli videresendt til kontrolleren. Her blir avgjørelser om pakkehåndtering behandlet. Figur 1 viser et oversiktsbilde over de ulike lagene og vanlige interface. Figur 1: Oversikt over lagstruktur og typiske koblinger Rev: v1.00 4(68)

5 Det blir presentert ulike begreper og teknologier som forbindes med SDN. Først forklares forskjellen mellom en tradisjonell switch og SDN-switch, som viser at avgjørelsene blir flyttet ut av switchen. NETCONF og OF-Config er protokoller som tar av seg selve konfigurasjonen av SDN-switcher. Et viktig konsept som ofte blir sett på i sammenheng med SDN er NFV (Network Function Virtualization), hvor nettverkstjenester fra fysiske enheter blir flyttet over i software og kan tas i bruk over alt i nettverket. En white box er en switch uten låst software fra leverandør hvor det kan fritt installeres et NOS (Network Operating System). Dette er et operativsystem som brukes for å styre og konfigurere switchen. Videre presenteres OpenFlow protokollens spesifikasjoner, som igjen forklarer hvordan OpenFlow fungerer. Det finnes mange kontrollere på markedet, og ulike valg for testing og simulering av SDN. I kapittel 5 presenteres programvaren som har blitt installert og testet i forbindelse med testene i denne oppgaven. Mininet simulerer nettverk med OpenFlow-switcher og datamaskiner, og gjør det enkelt å komme i gang med testing av OpenFlow. Kontrolleren Floodlight er lett å installere og bruke, mens OpenDaylight har best støtte for ulike protokoller samt mange utviklere. I kapittel 6 utføres det ulike tester på funksjonalitet i den valgte protokollen OpenFlow. Det demonstreres blant annet hvordan OpenFlow kan få en switch behandle pakker slik at avanserte nettverksfunksjoner kan utføres direkte i switchen. Dette er mulig på grunn av avanserte match og modifikasjonsmuligheter på pakkene i switchen. Det demonstres behandling av looping-utfordringer, og det nordgående interface utforskes med et API (Application Program Interface) som heter REST (Representational State Transfer). For å bli kjent med mulighetene og utfordringene med SDN har det blitt gjennomgått mye dokumentasjon som det refereres til gjennom hele oppgaven. Til slutt, i kapittel 7 diskuteres utfordringene som introduseres med den nye teknologien. Det er viktig å trekke frem at det dukker opp mange nye sikkerhetsutfordringer, og at utviklingen ikke er kommet så langt at det vil være praktisk å bytte ut et helt bedriftsnettverk med SDN-teknologi. Det er uansett mulig å starte implementasjon i deler av nettverket, gjerne i datasenter, og kontroll av virtuelle maskiner (VM). Rev: v1.00 5(68)

6 1 Innhold Dokumentkontroll... 2 Forord... 3 Sammendrag Innledning Organisering av rapporten Oppdragsgiver Problemstilling Gjennomføring av oppgaven Bakgrunnsteori Forskjellen på tradisjonell switching og SDN switching Tradisjonell switching SDN switching Proactive eller Reactive NETCONF og OF-CONFIG Open vswitch Nettverksoperativsystem Network Function Virtualization (NFV) Service Chaining Teori. Software-Defined Networking - OpenFlow OpenFlow versjoner Grunnleggende OpenFlow funksjonalitet OpenFlow porter OpenFlow tabeller Matching og actions Kommunikasjon Spanning-Tree og OpenFlow Spanning-Tree utfordringer i hybride nettverk Lastbalansering og portaggregering i OpenFlow VLAN og trafikkseparering i OpenFlow og Open vswitch Kontrollere og behandling av trafikk fra ulike VLAN Fysiske OpenFlow switcher og VLAN Virtuelle switcher og VLAN Realisering av valgt løsning Rev: v1.00 6(68)

7 5.1 Testmiljø Testet programvare Mininet EstiNet Wireshark SDN kontrollere OpenDaylight Floodlight HP VAN SDN Controller Ryu Vurderinger av programvare og kontrollere Testing Trafikkstyring på ulike lag Lag Lag Lag Lag Pakkemodifikasjoner VLANs Eksempel på bruk av STP i OpenFlow fra Ryu Flere tabeller og prioritet Nordgående interface, RESTful API Observasjoner gjort fra testene Vurdering. SDN i dag Applikasjoner Sikkerhet Overgang til SDN Konklusjon Appendiks A Litteraturliste Appendiks B Forkortelser og ordforklaringer Appendiks C Prosjektledelse og styring C.1 Prosjektorganisasjon C.2 Fremdriftsplan C.3 Risikoliste Rev: v1.00 7(68)

8 Appendiks D Figurliste Appendiks E RYU STP utskrift Appendiks F LAB-utskrifter Rev: v1.00 8(68)

9 1 Innledning Software-Defined Networking (SDN) er et nettverkskonsept hvor hovedideen er at logikken for å kontrollere nettverkstrafikken blir tatt ut av nettverksenhetene (heretter kallet switchene). Open Networking Foundation definerer SDN slik: "The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices." [1 I et tradisjonelt nettverk inneholder en switch både the control plane og the forwarding plane, men i SDN blir de separert. Pakkehåndteringen blir flyttet inn i en sentral enhet, en controller, som fungerer som hjernen til alle switchene. Switchene har en flow table, og kontrolleren setter inn flow table entries som beskriver hvordan pakker skal bli behandlet og sendt gjennom nettverket. Når en switch får en pakke som ikke finner match i sin flow table, vil pakken bli videresendt til kontrolleren for analysering 1. På denne måten har pakkehåndtering blitt flyttet ut av hardware og over i software, og kontrolleren åpner for mulighet til å programmere nettverksfunksjoner. Figur 2 viser kontrollerens nordgående og sørgående interface. Det sørgående interfacet vender mot switchene, the forwarding plane, som har ansvar for videresendingen av pakkene. Dette interfacet inneholder en SDN protokoll, eksempelvis OpenFlow [2 som er den mest etablerte sørgående protokollen. Kommunikasjon med switchene foregår via TCP-tilkoblinger (Transmission Control Protocol). Kontrollerens nordgående interface går mot applikasjonslaget. Gjennom dette interfacet får applikasjoner tilgang til informasjon om nettverket via API, og mulighet til å påvirke kontrollerens trafikkstyring. Dermed påvirke nettverkes trafikkflyt. Det vil være mulig å bruke kommersielle applikasjoner, og mulighet til å programmere egne programmer. Eventuelle øst og vestgående interface vil peke mot andre kontrollere i samme nettverk. Figur 2: SDN-kontrollers interface 1 Kontrolleren har også mulighet til å konfigurere switchen til å droppe pakker som ikke har match. Rev: v1.00 9(68)

10 1.1 Organisering av rapporten På grunn av at jeg har hatt en åpen og egendefinert oppgave, og ikke en konkret problemstilling fra starten av, har mye av tiden og arbeidet mitt gått til å bli kjent med SDN og OpenFlow. Jeg har lest mye dokumentasjon og artikler, samt sett videoer som går i dybden på ulike emner som omhandler SDN. Jeg bruker derfor også en del av denne oppgaven til å forklare OpenFlows funksjonalitet, utfordringer og muligheter. SDN er et nytt konsept, og relaterte begreper er ikke etablert på norsk. På grunn av dette vil det inngå en god del engelsk terminologi i denne oppgaven. 1.2 Oppdragsgiver Denne oppgaven var egendefinert. 1.3 Problemstilling Det har vært mye snakk om Software-Defined Networking (SDN) de siste årene. SDN er en viktig brikke i nestegenerasjons mobile nettverk, 5G [3. Allerede i dag bruker mange av de store internettbedriftene som Google [4 [5, Facebook [6 og Microsoft [7 ulike SDN-relaterte teknologier for å styre sine nettverk. Med tusenvis av nettverksenheter har disse bedriftene mange fordeler med å ta i bruk programmerbare nettverksløsninger. I tillegg har Cisco meldt at neste oppdatering av deres CCNA Routing and Switching sertifisering kommer til å inkludere forståelse om SDN [8. Jeg ønsker å se nærmere på er om SDN teknologien er moden nok til å tas i bruk i vanlige nett. Kan mellomstore bedrifter som ikke har tusenvis av switcher, og bare noen få nettverksadministratorer ha fordeler med å bruke SDN-teknologi til å styre sine nettverk i dag? For å ta stilling til dette ønsker jeg å undersøke: Er det enkelt å komme i gang med SDN? o Installasjon av programvare. o Valg av kontroller. o Test og simulering av SDN nettverk. Muligheter med switchens flow table. o Matching av ulike pakketyper. o Pakkebehandling. Kontakt mot nettverket via det nordgående interface. o Mulighet for programmering. Funksjonalitet fra tradisjonelle nettverk i SDN. o VLAN for nettverksseparering. o Spanning-Tree for å unngå looping i nettverk. o Lastbalansering for linkredundans. 2 Gjennomføring av oppgaven Denne oppgaven brukes til å gi et generelt overblikk over mulighetene og utfordringene med SDN og spesielt den sørgående protokollen OpenFlow slik det ligger til rette for i dag. Store deler av tiden kommer til å bli brukt til å bli kjent med teknologien. Rev: v (68)

11 I starten kommer jeg til å lese artikler og studier på relevante temaer for å etablere en grunnleggende forståelse. Etter hvert går jeg mer i dybden på viktige tjenester og dokumentasjon. Informasjon jeg trenger finner jeg på internett. ONF har spesifikasjoner på OpenFlow protokollen og mye relevant informasjon. SDxCentral har gitt ut flere relevante rapporter som jeg skal lese. IEEE har mange publiserte studier som er relevante for min oppgave som jeg får tilgang til via skolens nettverk. GNS3 Academy har et videokurs som gir introduksjon til teknologien som jeg kommer til å se gjennom. Noe info kan jeg også finne ved hjelp av teknologinyhetssteder, samt spesifiserte søk på Google. Jeg kommer til å teste teknologien i praksis ved å sette opp et testmiljø via virtuelle maskiner på min datamaskin. På den måten får jeg mulighet til å teste SDN og OpenFlow i praksis. Jeg vil bli kjent med ulike kontrollere, og velger ut noen som jeg skal få installert og tatt i bruk mot mitt testnettverk. For å bli bedre kjent med OpenFlow vil jeg teste switchenes flow table og se hvordan trafikk reagerer på ulike oppføringer i switchene. Jeg kommer ikke til å programmere egen applikasjon i det nordgående interface, da det er for tidskrevende. Men jeg ønsker å lære hvordan applikasjoner kan kommunisere med en kontroller, hente ut informasjon fra nettverket, og introdusere egen funksjonalitet i nettverket. 3 Bakgrunnsteori For å få et godt grunnlag for videre forståelse starter oppgaven med å forklare ulike begreper og funksjoner som er viktige for å forstå funksjonaliteten til SDN. 3.1 Forskjellen på tradisjonell switching og SDN switching I denne delen forklarer jeg forskjellen på tradisjonell og SDN switching Tradisjonell switching I den tradisjonelle switching-modellen lærer switchen en MAC-adresse (media access control) første gang den mottar en pakke fra en enhet 2. Adressen legges da inn i switchens MAC-adressetabell sammen med tilhørende port. Figur 3 viser en enkel topologi med tilhørende MAC address table. Dersom switchen mottar en pakke med ukjent MAC mottaker, sender switchen pakken ut alle porter (utenom porten hvor pakken kom fra). Riktig enhet svarer, og enhetens MAC-adresse legges til tabellen med tilhørende port. Figur 3: Tradisjonell switching 2 Enheter som bruker nettverket har hver sin unike MAC-adresse. Rev: v (68)

12 3.1.2 SDN switching For å forklare SDN switching tar jeg utgangspunkt i den sørgående SDN-protokollen OpenFlow, som blir forklart grundig i kapittel 4. Med OpenFlow tar ikke switchene egne avgjørelser. Kontrolleren bestemmer og har full oversikt over enhetene i nettverket. Det må først opprettes en forbindelse mellom switchene og kontrolleren gjennom TCP. Dersom switchen mottar en pakke som ikke har en passende oppføring i sin flow table, spør den kontrolleren hva den skal gjøre. Dette gjør den ved å sende gjeldende pakke til kontroller. Kontrolleren gjør kalkulasjoner og svarer med en ny tabelloppføring som switchen kan bruke. Figur 4 viser et enkelt topologieksempel med switchenes flow table. Figur 4: SDN Switching Denne sentrale kontrollen og oversikten over nettverket kan være en fordel for nettverksadministratorer. I et tradisjonelt nettverk vil for eksempel en policy-endring føre til konfigurasjon på hver enkelt enhet. Her styres alt sentralt, og endringene sendes ut der de behøves fra kontroller. Monitorering vil også bli enklere fordi kontroller allerede har informasjon om hele nettverket. Trafikk kan raskt konfigureres til å endre sti gjennom nettverket. Når kontrollogikken er flyttet ut av switchene, vil ny funksjonalitet i nettverket kunne introduseres gjennom applikasjoner som kommuniseres med kontrolleren. Funksjonaliteten vil være fleksibel, og den kan tas i bruk der den trengs i nettverket. Istedenfor å ta destinasjonsbaserte avgjørelser for videresending, tar nå switchen avgjørelser basert på oppføringene i flyttabellen. Switchen må finne en oppføring som har riktige treffegenskaper, og deretter gjøre ønsket handlinger og endringer på pakkene. Oppføringer i flyttabellen har mange ulike treffparametere, blant annet fysiske porter, MAC adresser, IP adresser og TCP portnummer. I praksis betyr dette at avhengig av hva regler som oppført i en flow table, kan en nettverksenhet oppføre seg som for eksempel en ruter, en brannmur, en lastbalanseringsenhet eller en vanlig switch. 3.2 Proactive eller Reactive En kontroller lager stier i nettet ved å gi flow table entries til switchene. Dette blir gjort enten proaktivt eller reaktivt, eller en kombinasjon. Rev: v (68)

13 Proaktiv metode lager oppføringene allerede før switchene har mottatt pakker som skal sendes gjennom nettet. Ved oppstart får kontrolleren oversikt over nettverkstopologien, og basert på disse kan den gi switchene flow table entries for ønskete stier gjennom nettet. Dersom det senere kommer pakker som ikke finner match i tabellen, kan det avgjøres om de skal droppes eller videresendes til kontroller. Ved reaktiv metode lages ingen oppføringer i flyttabellen før switchene begynner å få innkommende pakker. Når switchen får sin første pakke, og den ikke har noen oppføringer i sin tabell 3, blir pakken videresendt til kontrolleren for behandling. Kontrolleren bruker informasjonen den har om nettverket sammen med regler for pakkebehandling i nettverket, og sender tilbake en flow table entry som switchen kan bruke til å behandle og videresende pakken. På denne måten vil bare nødvendige oppføringer havne i flow table. Det er også mulig å kombinere proaktiv og reaktiv metode til en hybrid metode der noen regler blir spesifisert på forhånd, mens resterende leveres av controller ved behov. Alle flow table entries på switchen har en spesifisert tidsluke som bestemmer hvor lenge de skal befinne seg i tabellen. Dersom ingen innkommende pakker har brukt oppføringen over en spesifisert periode, fjernes oppføringen. Dette sørger for at flyttabellene ikke blir overoppfylt med gamle oppføringer. 3.3 NETCONF og OF-CONFIG Mens protokoller som OpenFlow behandler trafikken gjennom nettverket, vil det også være ønskelig å kunne fjernkonfigurere switchene. NETCONF (Network Configuration Protocol) [9 er en protokoll av IETF (Internet Engineering Task Force), og kan bli sett på som en erstatning av den eldre SNMP (Simple Network Management Protocol) [10. NETCONF gir mulighet til å konfigurere ulike nettverksenheter via et XML-basert konfigureringsspråk (Extensible Markup Language). ONF har forstått at konfigurering av utstyret er en viktig del av et effektivt SDN nettverk, og introduserte i 2011 OF-CONFIG 1.0 (OpenFlow Management and Configuration Protocol) [11. Dette er en spesifikasjon som bygger på NETCONF, og sørger for konfigurering av OpenFlow switcher. OF- CONFIG er pr Mai 2016 i versjon 1.2 [ Open vswitch Open vswitch (OVS) [13 er en virtuell switch som er laget for å støtte switching mellom flere virtuelle servere som kjører på en fysisk server. En bedrift kan spare ressurser ved å samle mange virtuelle maskiner i en fysisk maskin. Programvaren kan installeres på en enhet eller et VM med Linux operativsystem. Som standard bruker OVS protokollen OpenFlow til å switche pakkene enten med innebygget eller ekstern kontroller, men det er også mulig å gjennomføre tradisjonell switching ved å tilpasse konfigurasjonen 4. Nettverkssimulatoren Mininet som presenteres i bruker OVS som switcher i sine virtuelle nettverk. 3 Den har egentlig en oppføring som sørger for at ukjente pakker sendes til controller. 4 Med å ha en oppføring i flow table som er markert actions=standard vil tradisjonell switching bli aktivert. Rev: v (68)

14 Det er mulig å mappe OVS sine virtuelle interface med fysiske porter. På den måten kan en fysisk maskin med flere porter gjøres om til en fysisk OVS switch. [14 viser dette med å gjøre den lille datamaskinen Raspberry Pi [15 om til en OVS OpenFlow-switch. OVSDB (Open vswitch Database Management Protocol) er protokollen som sørger for konfigurasjon av OVS switchene. Den introduserer et enkelt hierarki av kommandoer for avansert konfigurasjon av enheten. Den var opprinnelig bare en del av Open vswitch, men har nå blitt en konfigurasjonsprotokoll på lik linje med SNMP og NETCONF selv om den i liten grad har blitt tatt i bruk utenfor Open vswitch enda. OVSDB blir nærmere beskrevet i RFC7074 [ Nettverksoperativsystem En trend som har dukket opp de siste årene er white label switches, white boxes, eller også kallet bare metal switches. Istedenfor at switcher er låst til selgers software og operativsystem slik det ofte er med utstyr fra for eksempel Cisco, Juniper eller HP, selges switcher uten installert software. Kjøper står da fritt til å installere ønsket software, som oftest linux-baserte operativsystemer og ofte gratis med åpen kildekode. Dette gjøre innkjøp av utstyr mye billigere, og løsningene mer fleksible. To av de mest kjente linux-baserte nettverksoperativsystemene er Cumulus Linux [17 og Pica8 PicOS [18. [19 inneholder også en liste over mange av de ulike alternativene. Det er ingen selvfølge at et slikt nettverksoperativsystem (NOS) støtter SDN-teknologi som OpenFlow. Men det å levere hardware som er leverandøruavhengig er en ny trend som ender måten nettverk blir tatt i bruk, og blir på den måten ofte blandet med eller sammenlignet med SDN. Av de nevnte operativsystemene støtter Pica8 OpenFlow, mens Cumulus bare støtter tradisjonell switching. Mye tyder på at bransjen nærmer seg et skifte hvor det blir vanlig å kunne fritt velge ønsket software på en leverandørs switch-hardware. Facebook presenterte i 2015 sin 6-pack [20, en åpen modulær switch. HP er kanskje den av de store leverandørene som jobber hardest med å separere software og hardware. Sammen med blant annet Intel, Broadcom og vmware samarbeider de med å utvikle OpenSwitch [21 [22, et åpent NOS. De har også lansert HPE Altoline 6920 switch-serien [23, som støtter både Pica8 PicOS og Cumulus Linux [ Network Function Virtualization (NFV) Network Function Virtualization (NFV) har også fått mye oppmerksomhet de siste årene, og er tett knyttet opp mot SDN. Ved å virtualisere nettverkstjenester som tidligere har blitt operert som egne fysiske enheter, som for eksempel NAT, DNS, brannmurer osv., kan nettverket gjøres billigere, mer fleksibelt og mer skalerbart. Nettverkstjenestene kjører da på en (eller flere) fysiske servere som gjerne inneholder mange ulike virtualiserte maskiner med de ulike tjenestene. SDxCentral har gjort mye research og sier i sin rapport [25 at de har merket stor økning på interesse og utvikling for NFVløsninger. SDN og NFV er begge to nye interessante teknologier med mye til felles. Begge flytter mer av nettverkslogikken over i software og endrer måten nettverk blir distribuert [26. De er ikke avhengige av hverandre, men begge styrker fordelene med å brukes sammen. SDN er godt egnet til å styre pakker i løsninger tilknyttet mange ulike virtuelle tjenester og enheter som kjører i en fysisk maskin i datasentre. NFV tjenester kan være applikasjoner i det nordgående interface. Rev: v (68)

15 3.7 Service Chaining Når trafikk fra en enhet skal gjennom et nettverk mot sin destinasjon, må pakkene innom og behandles av ulike nettverkstjenester. Hvilke tjenester avhenger av type data som er i pakkene. Noen eksempler kan være at http data må analyseres av ACL, NAT og DPI (Deep Packet Inspection), mens videotrafikk inne skal til DPI men til en videooptimiseringstjeneste. Service Function Chaining (SFC) eller bare Service Chaining kan benyttes sammen med NFV og SDN. Ved å virtualisere nettverkstjenestene kan labels i pakkeheaderen sørge for at ulik trafikk benytte seg av ulike nettverkstjenester, enkelt illustrert i Figur 5. Nettverkstjenestene blir skalerbare, og det kan enkelt gis mer ressurser der det trengs. [27 har en lett forståelig artikkel som forklarer konseptet, og IETF har et informasjonsskriv som beskriver teknologien [28. Figur 5: Ulik trafikk må innom ulike nettverkstjenester 4 Teori. Software-Defined Networking - OpenFlow Jeg velger å fokusere på OpenFlow [2 i denne oppgaven, som er den ledende SDN-protokollen i dag. OpenFlow er protokollen som tar av seg kommunikasjon mellom switch og kontroller, altså det sørgående interface, og som leverer innhold til flow tables i switchene. Opprinnelsen til OpenFlow kom ut i fra arbeidet til doktorgradstudent Martin Casado på Stanford University i 2005 [29. Ideene fra prosjektet ble videreutviklet helt til det endte opp som OpenFlow i 2008 [30. Det var tenkt som en måte for å gjøre universitet og høyskolers campus-nettverk programmerbare, slik at det kunne forskes på nye protokoller. Konseptet skapte mye interesse, og i 2011 ble Open Networking Foundation etablert for å spre opplysning og arbeide videre med Software-Defined Networking og OpenFlow. I styret til ONF sitter folk fra blant annet Facebook, Yahoo, Microsoft, Google og Verizon [31. Noen protokoller som kan brukes til SDN-kontrollerte nettverk, og kan bli sett på som konkurrenter til OpenFlow er Cisco OpFlex [32, BGP [33 (Border Gateway Protocol) og tidligere nevnte NETCONF [ OpenFlow versjoner Teknologien er under stadig utvikling, og det blir stadig lansert nye versjoner. Den er i dag kommet til versjon 1.5 [34 som ble lansert desember 2014, men den er såpass ny enda at det ikke er implementert støtte for den i de fleste kontrollere eller switcher. Hovedsakelig er det versjon v.1.0 [35 og v.1.3 [36 som blir støttet av switcher og kontrollere, og derfor kommer jeg til å ta utgangspunkt i disse under mine tester, men mest fokus på versjon 1.3. Rev: v (68)

16 Den første versjonen etter betalanseringer, altså versjon 1.0, ble lansert 31 desember Den 13. april 2012 ble versjon 1.3 lansert. Noen av endringene som kom etter versjon 1.0 og gjør at versjon 1.3 er et mer attraktivt valg er blant annet: støtte for IPv6 flere og mer fleksible treffparametere (matching) utvidet støtte for VLAN tagger gruppetabeller (mye tilsvarende multicast) kontrollere med master/slave roller (redundant, unngå single point of failure) støtte for flere tabeller Den aller viktigste endringen mellom de to utgivelsene er kanskje støtten for flere tabeller, som kom i versjon 1.1. Versjon 1.0 støtter kun en flow table. I større nettverk kan dette forårsake at switchene får store, komplekse tabeller, som igjen kan kreve mye prosessering. Ved å ha flere tabeller vil matching prosessen bli mer dynamisk, og tabellene enklere å ha kontroll på. All trafikk må matches i den første tabellen, og kan eventuelt bli videresendt til en annen tabell for videre prosessering. 4.2 Grunnleggende OpenFlow funksjonalitet I dette avsnittet skal jeg presentere litt av de grunnleggende funksjonene til OpenFlow, og hvordan kommunikasjon mellom switch og kontroller foregår. Jeg har tatt utgangspunkt i spesifikasjonene for OpenFlow versjon 1.3 [36. En switch kan enten være en ren OpenFlow switch eller en hybrid OpenFlow switch. Hybride løsninger bruker noen av switchens porter til tradisjonell switching, og noen til OpenFlow. Hybride switcher må kunne ta en avgjørelse om pakken skal behandles via OpenFlow eller tradisjonell switching. Dette kan gjøres ved hjelp av pakkens inn-port eller VLAN tag. Rene OpenFlow swicher, også kalt OpenFlow-only switcher, er da altså switcher som kun bruker OpenFlow. Begge nevnte typer kan enten være fysiske switcher eller virtuelle switcher OpenFlow porter Portene er OpenFlow enhetens nettverk-interface. Det blir delt inn fysiske porter, logiske porter og reserverte porter. De fysiske portere representerer de faktiske fysiske portene som en switch har i hardware. På hybride switcher er det ikke nødvendigvis at dette dekker alle hardware-interface, men kun de som er blitt aktivert for OpenFlow. Logiske porter er interface som ikke tilsvarer et fysisk interface. Det kan derimot dekke logiske tuneller, en gruppe av aggregeringsporter eller annet. Den eneste egentlige forskjeller på fysiske og logiske porter fra OpenFlow sitt perspektiv er at logiske porter har noen ekstra felter i headeren for data. Reserverte porter gjelder porter som har bestemte oppgaver i et OpenFlow nettverk. De blir brukt til å utføre bestemte handlinger i en enhets flow table. Porten som har kontakt med en kontroller er et eksempel. ALL sender matchet pakke ut alle tilgjengelige porter, TABLE representerer starten av prosesseringen av en pakke, og sender den til første tabell. Fysiske og hybride OpenFlow swicher har Rev: v (68)

17 også reserverte porter for NORMAL, som sender en pakke ut av OpenFlow og inn i tradisjonell pakkebehandling, og FLOOD som sender en pakke ut alle porter som er aktivert for tradisjonell switching OpenFlow tabeller Alle pakker starter i den første flow table, tabell 0. Her starter pakkebehandlingsprosessen som kanskje skal innom flere flyttabeller. Dersom match i tabell 0 har et goto_table-felt, vil pakker bli videresendt til neste tabell med gitt nummer. En pakke kan kun bli sendt til en tabell med høyere nummer, og kan derfor aldri bli prosessert av en tabell flere ganger. Alle linjer i en flow table har et prioritetsnummer mellom 0 og (16-bits). Dersom prioritet ikke blir angitt får linjen en standard prioritet på Om en innkommende pakke har match i mer enn en tabell vil pakken gå til linjen med høyest prioritet. Dersom en pakke ikke finner match i tabeller, blir det et table miss. Tabeller bør ha et felt som fanger disse (table miss flow entry). Ved å sette prioritet til 0 og match any, vil alle pakker uten bedre match gå her. Det blir da spesifisert om pakken skal kastes, gå til en annen tabell eller sendes til kontroller. Dersom det ikke eksisterer en linje for å fange disse blir pakken kastet. Linjer i en flow table vil enten bli fjernet når kontrolleren ber den om å fjernes, eller etter et spesifisert tidsavbrudd. Idle timeout fjerner linjen når den ikke har hatt noen treff etter angitt tid, mens hard timeout fjerner linjen etter angitt tid etter linjen ble opprettet, altså uavhengig om linjen er blitt tatt i bruk eller ikke. OpenFlow tar også i bruk noen andre tabeller enn flyttabellen. Gruppetabellen kan tenkes på som en tabell for multicast og broadcast, Meter-tabellen kan måle ulike egenskaper med pakke, og kan blant annet brukes til Quality of Service (QoS) Matching og actions For at noe skal hende med pakken må den først finne en match i flow table 0. Det er mange muligheter for å spesifisere treff i tabellene og ikke bare lag 2 trafikk, men alt i fra lag 1 til lag 4 fra OSI tabellen [37. Jeg lister opp noen raske eksempler, for å vise noen få av treffmulighetene. Eksempel lag 1: Match på innkommende port Eksempel lag 2: Match på MAC-adresse Eksempel lag 3: Match på IP-adresse Eksempel lag 4: Match på TCP eller UDP trafikk Når en pakke har funnet en oppføring som matcher vil det også kunne være noen felt markert actions i linjen på flyttabellen. Altså hva som skal gjøres med pakken. Dersom en pakke skal bli sendt til en annen tabell, kan action-feltet bli oppdatert. Først når pakken kommer til siste tabell, altså til en linje som ikke har goto-table, vil handlingene bli utført. Utførte handlinger kan for eksempelvis være å spesifisere ut-port på pakken, sette på VLAN-ID og/eller senke TTL (Time to Live) Kommunikasjon Kommunikasjon mellom kontroller og switch foregår på et ikke-openflow interface og over en TCP tilkobling som standard via port Tilkoblingen har mulighet til å være kryptert med TLS, men dette er enda ikke blitt tatt så mye i bruk i praksis på faktiske controllers. Det er alltid switchen som Rev: v (68)

18 starter oppkobling ved å sende en HELLO melding til kontroller. I HELLO meldinger er det med flagg som markerer støttede OpenFlow versjoner. Switch og kontroller velger å bruke den høyeste versjonen som de begge støtter. Når tilkoblingen er opprettet, blir denne hold i live med ECHO og ECHO-REPLY meldinger. Så snart switchen mister kontakt med en kontroller går den i enten fail secure-modus eller fail standalonemodus. Fail standalone-modus er kun støttet av hybride switcher, og vil si at switchen går tibake til å behandle pakker med tradisjonell switching. I fail secure modus fortsetter switchen å sende pakker som matcher i flyttabellen, frem til timerene går ut. Det er tre meldingstyper som blir utvekslet mellom kontroller og switch. Controller-to-switch, asynchronous og symmetric. Controller-to-switch kan kun være pakker fra kontroller til switch, som navnet sier, og er pakker som kontrolleren bruker til å gjøre endringer på switchens konfigurasjon og flyttabeller. Asynchronous er pakker som switchen sender uten at kontroller har bedt om det først. Dette kan være meldinger om at en linje har gått ut fra flyttabellen, pakker som ikke får treff i flyttabellen eller feilmeldinger. Symmetric kan både blir sendt fra kontroller og fra switch, og blir brukt under oppkobling med HELLO pakker, samt for å holde tilkoblingen i live med ECHO og ECHO- REPLY. Flere kontrollere kan konfigureres til å ha kontakt med de samme switchene, for redundans dersom en switch mister kontakt med en kontroller. Kontrollerene har da spesifiserte roller. Som standard har en kontroller OFPCR_ROLE_EQUAL, som gir kontrolleren full tilgang til switchen. Dersom det er flere kontrollere, kan en kontroller sende en forespørsel til å bli OFPCR_ROLE_MASTER, som sørger for at kontrolleren blir hovedkontrolleren. Switchen gjør da andre kontrollere som var master om til OFPCR_ROLE_SLAVE, som gjør at disse kontrollerene ikke kan gjøre endringer, og bare får sendt port statusmeldinger fra switchen. 4.3 Spanning-Tree og OpenFlow I de fleste nettverk vil de være flere redundante stier mellom switcher i nettverket. På grunn av broadcast-pakker som blir sendt ut når mottaker er ukjent, vil redundante linker lage problemer med å duplisere pakkene og sende de i en evig ring som til slutt vil sluke hele nettverkets kapasitet. IEEE 802.1D, eller Spanning-Tree Protocol (STP) er en viktig protokoll i tradisjonelle nettverk som sørger for at det ikke blir looping i lag 2 topologien. Ved hjelp av BPDU meldinger som utveksles mellom alle switcher, bygger switchen seg en logisk topologioversikt over nettverket, og dersom det er to veier til samme port, stenges den ene. Ettersom kontrolleren har full oversikt over nettverket i SDN og tar alle beslutninger om hvor ulik trafikk skal sendes, er det ikke nødvendigvis behov for å bruke STP i OpenFlow. De aller fleste kontrollerne er programmert til å lage flow table entries som unngår looping. På fysiske switcher kan det hende at en port blir blokkert grunnet STP som kjører utenfor OpenFlow, og switchen sender da en OFPT_PORT_STATUS med et flagg som markerer OFPPS_BLOCKED. Switchen gir også beskjed om porten går ned med flagget OFPPS_LINK_DOWN. Disse flaggene er kun status på porter som switchen kan sende kontrolleren, men kontrolleren kan ikke styre de selv. [36, p. 37. Kontrolleren kan påvirke STP på en fysisk switch ved å sende en OFPPC_NO_STP som kan forhindre porten i å ta i bruk STP. Rev: v (68)

19 Kontrolleren har en del konfigurasjonsflagg for å se og påvirke STP-oppførsel på fysiske switchporter (se figur). I tillegg kan disse flaggene brukes til å implementere STP og BPDU utveksling i OpenFlow. OFPPC_PORT_DOWN = 1 << 0, /* Port is administratively down. */ OFPPC_NO_STP = 1 << 1, /* Disable 802.1D spanning tree on port. */ OFPPC_NO_RECV = 1 << 2, /* Drop most packets received on port. */ OFPPC_NO_RECV_STP = 1 << 3, /* Drop received 802.1D STP packets. */ OFPPC_NO_FLOOD = 1 << 4, /* Do not include this port when flooding. */ OFPPC_NO_FWD = 1 << 5, /* Drop packets forwarded to port. */ OFPPC_NO_PACKET_IN = 1 << 6 /* Do not send packet-in msgs for port. */ Figur 6: STP konfigurasjonsflagg i OpenFlow Spanning-Tree utfordringer i hybride nettverk SDN kommer med stor sannsynlighet til å introduseres gradvis i bedrifters nettverk, og SDN vil i begynnelsen bare benyttes i deler av nettet. I [38 snakker forfatterne om utfordringen med looping og spanning-tree når SDN-nettverk og tradisjonelle nettverk kobles sammen i et nettverk. Dersom det er mer enn en link mellom SDN delen og den tradisjonelle delen vil det kunne oppstå looping mellom de ulike delene. Artikkelen kommer med et forslag til løsning på problemet. Siden kontrolleren har alt ansvar i SDN delen av nettverket vil den foreta alle STP avgjørelser her. Den vil observere om den får BPDU med samme Root Bridge fra flere av sine switcher, og på den måten registrere at det er her snakk om flere linker mellom SDN og tradisjonell nett. Den vil da blokkere linkene bortsett fra en og unngår dermed looping. Dersom det er større nettverk med flere SDN deler og flere tradisjonelle deler (i artikkelen blir de kalt øyer), må kontrolleren få et enda mer helhetlig bilde av nettverket for å unngå loopingmuligheter. Siden kontrolleren får info om de ulike tradisjonelle øyene via BDUP fra naboswitchene i SDN delene, kan den behandle hver «øy» som en node (en switch/bridge), og dermed kalkulere en spanning-tree topologi som brer seg over hele nettverket. 4.4 Lastbalansering og portaggregering i OpenFlow I tradisjonell switching er det mulig å sette sammen flere fysiske nettverksporter til en logisk virtuell port, en EtherChannel, med for eksempel protokollen LACP (IEEE 802.3ad) [39 eller Cisco sin PAgP [40. Dette sørger for redundans mellom to enheter i tillegg til å øke overføringshastighet. Ryu presenterer en applikasjon [41 som viser hvordan OpenFlow kan benytte seg av portaggregering [42, og slå sammen flere fysiske (eller logiske) porter til en logisk port. Dersom en av portene går ned vil linken ikke bli brutt. [43 har sett på mulighetene til å bruke SDN for å levere lastbalansering fra ende-hoster (datamaskin eller mobiltelefon) i trådløse nettverk som WiFi og 4G teknologi, som kan ha flere utgående kanaler. For å unngå problemer med TCP sørger flyttabelloppføringene for at pakker i samme TCP sesjon blir sendt ut samme kanal. Rev: v (68)

20 4.5 VLAN og trafikkseparering i OpenFlow og Open vswitch I bedrifters lokale nettverk er det nesten alltid nødvendig for å separere nettet inn i mindre isolerte nett, eller VLAN (Virtual Local Area Network). Av sikkerhetsmessige årsaker vil det være lurt å kunne skille trafikk fra for eksempel ulike avdelinger i bedriften selv om en er innenfor et lokalt nettverk. I tradisjonell switching er dette normalt hvor trafikk fra ulike VLAN er helt separert, selv om sluttbrukerne fra ulike VLAN befinner seg på samme switcher. For å kunne få trafikk fra ulike VLAN mellom ulike switcher brukes det trunk-porter mellom switchene, som tagger trafikken med VLAN ID tag før den sendes over linken. For at OpenFlow skal kunne brukes i utenfor et LAB-miljø er det helt avgjørende at det er mulig og ukomplisert å benytte seg av VLAN både på fysiske og virtuelle switcher Kontrollere og behandling av trafikk fra ulike VLAN OpenFlow støtter VLAN og kontrolleren sørger for at trafikk i ulike VLAN ikke kan nå hverandre. Oppføringer i flyttabellen kan matche på et VLAN ID. Det er også mulig å modifisere VLAN ID i en pakkeheader ved hjelp av action-feltet i oppføringen, og på den måten flytte trafikk fra et VLAN til et annet om ønsket Fysiske OpenFlow switcher og VLAN HP sine fysiske switcher kan kjøre både tradisjonell og OpenFlow switching samtidig, men på ulike VLAN. Noen porter kan dermed bruke OpenFlow og ha kontakt med en kontroller, mens andre porter kan være koblet til et tradisjonelt LAN. Et krav er at kontakten med kontrolleren foregår på et eget VLAN som ikke kjører OpenFlow. HP ProVision software støtter OF 1.0 og 1.3, mens HP Comware støtter bare OF 1.3. DPID (Datapath ID) blir registrert med de første 16 bits som VLAN ID, mens resten er switchens MAC-adresse. Figur 7 viser et eksempel på konfigurasjonsoppsett på en HP ProVision 3800 switch [44 som forklart av [45. configure openflow controller-id 1 ip controller-interface vlan 192 instance «vlan10» member vlan 10 controller-id 1 version 1.3 enable exit enable show openflow instance vlan 10 Figur 7: Konfigurasjon av OpenFlow på fysisk HP switch Disse switchene har et en-til-en forhold et VLAN per instans, mens Comware switcher [46 kan ha flere OpenFlow VLAN i samme instans Virtuelle switcher og VLAN Open vswitch bruker OpenFlow som standard med VLAN funksjonalitet avslått. Ved å sette switchene til standalone mode benytter switchene seg av tradisjonell switching, og VLAN støttes automatisk. Dette gjøres ved kommandoene ovs-vsctl set-fail-mode s1 standalone og ovs-vsctl Rev: v (68)

21 set-controller s1. Nå kan endeportene tagges med ønsket VLAN eksempelvis ovs-vsctl set port s1-eth1 tag=10, og linkene mellom switchene som trunkporter med ovs-vsctl set port s1-eth2 trunks=10, 20 [47. Det er også mulig å skru på støtten for VLAN med OpenFlow manuelt ved å sette kommandoer for at porter skal oppføre få påført en ønsket VLAN ID eller at en port skal fungere som en trunk som kan transportere pakker fra ulike VLAN. 5 Realisering av valgt løsning I dette avsnittet presenteres maskinvare og programvare som kommer til å brukes og testes i oppgaven. 5.1 Testmiljø Siden oppgaven inneholder mye og ulik testing har et simulert nettverk vært det beste for meg. Ved hjelp av ulike virtuelle maskiner har jeg raskt kunne sette opp og teste ulike nettverk og kontrollere. Alt kjøres fra min bærbare datamaskin, Sony VAIO Pro 13 med Windows 10, en 1.8 GHz Intel Core i7-4500u prosessor og 8 GB ram. De virtuelle maskinene kjøres fra Oracle VM VirtualBox [48 som er et gratis verktøy for å kjøre virtuelle maskiner (VM). Jeg laster ned systembildefiler fra nettet, oppretter en virtuell maskin med ønskede spesifikasjoner og kjører systembildefilen i maskinens virtuelle cd-rom for å installere operativsystemet. En annen fordel med VirtualBox er støtte for å kunne ta «bilde» (snapshot) av den virtuelle maskinen slik maskinen er «nå», for eksempel før installasjon av programvare. Dette gjør det enkelt å hoppe tilbake om noe skulle gå galt i etterkant under testing. Figur 8 viser VirtualBox med ulike virtuelle maskiner som har blitt brukt i oppgaven. Figur 8: VirtualBox med ulike virtuelle maskiner som er blitt brukt Rev: v (68)

22 For at mitt testmiljø skulle fungere var det viktig å ha kommunikasjonsmuligheter mellom ulike VM. Som standard blir trafikken fra et VM sendt inn i din maskins nettverk med NAT (Network Address Translation). Dette fungerer greit for å få kontakt med internett. Et alternativ er å bridge trafikken. Da kan jeg lage en IP adresse på mitt VM som er innenfor samme subnett som nettverket på maskinen min. Det er da kommunikasjon mellom maskin og VM, og kan da få ulike VM i samme nett (med ulike IP-adresser i samme nett). Med å ha de virtuelle maskinene og min egen maskin i samme subnett får jeg muligheten til å koble til VM via SSH, og da bruke Putty istedenfor VirtualBox GUI. I tillegg til logging av all aktivitet, enklere kopiering av tekst, og kjappere å veksle mellom ulike VMs gir dette meg muligheten til å bruke Xming sammen med Putty. Da kan da kjøre GUI applikasjoner fra de virtuelle maskinene selv om de ikke har et operativsystem med et grafisk brukergrensesnitt. Det oppstod et problem at de virtuelle maskinene ikke klarte å få egne IP-adresser på skolenettverket. Selv om dette fungerte fint hjemme. Løsningen min var å installere et Virtuelt nettverkskort på maskinen som heter Microsoft Loopback Adapter [49. Den gjorde at jeg fikk et falskt nettverkskort på kontrollpanelet hvor jeg konfigurerte ønsket IP (som vist i Figur 9). Mot dette kunne jeg bridge mine virtuelle maskiner. Figur 9: Virtuelt nettverkskort Med denne løsningen kom alle mine VM i samme nett og jeg kunne kommunisere mellom de ulike maskinene 5. Ettersom jeg prøver mange ulike tjenester, satte jeg også opp en enkel DHCP-server fra programmet Tftpd32. Det allokerer ut IP-adresser som vist i Figur 10. Dette for å slippe å manuelt konfigurere IP-adresser hele tiden ettersom jeg har mange testmaskiner og gjør stadige endringer. 5 Testet med å bruke ping. Rev: v (68)

23 Figur 10: Enkel DHCP-server 5.2 Testet programvare I dette avsnittet presenterer jeg programvare som jeg har brukt for å simulere og analysere trafikk i SDN nettverk Mininet Mininet [50 er et program som enkelt setter opp og emulerer nettverk med virtuelle OVS switcher og virtuelle hoster (datamaskiner i nettet). Programmet kjører fra eget VM [51 med Ubuntu Linux. Dette er brukt mye under testing. Ved kommandoen sudo mn settes det opp et nettverk. Figur 11 demonstrerer dette. Figur 11: Mininet kommando for oppretting av emulert nettverk Rev: v (68)

24 Kommandoen kommer også med valg slik at jeg kan spesifisere kontrollerplassering, nettverksstørrelse og lignende. Som et eksempel vil kommandoen sudo mn -- controller=remote,ip= mac --topo=linear,4 [52 gi meg et nettverk av 4 lineært koblete switcher med 1 host hver som snakker med en kontroller som har IP-adresse Kommandoen --mac gjør at hostene får enkle MAC-adresser som er enklere å kjenne igjen og analysere (00:00:00:00:00:01, 00::02 osv). Det er også mulig å skrive egne topologier i Python. I tillegg kommer Mininet også med et lite GUIprogram som heter MiniEdit [53, som lar deg tegne opp topologier grafisk, og deretter testkjøre de, eller skrive det ut til en Python skriptfil. Et eksempel på en topologi laget i MiniEdit er vist i Figur 12. Figur 12: MiniEdit Etter at mitt nettverk er oppe og kjører vil hver switch og hver host fungere som en egen maskin, og jeg kan for eksempel logge inn på den første hostmaskinen med å skrive xterm h1 i Mininet. Maskinen åpnes da i eget vindu (forutsatt at Xming-server kjører) og jeg kan kjøre applikasjoner, pinge eller gjøre endringer som jeg ønsker på de individuelle enhetene i nettverket. Rev: v (68)

25 5.2.2 EstiNet EstiNet [54 er et alternativ til Mininet og støtter både nettverkssimulering og emulering. EstiNet er et program med et grafisk brukergrensesnitt (GUI) hvor en kan teste og simulere nettverkstrafikk. Figur 13 viser et eksempel på en nettverkssimulering i EstiNet. Programmet kjøres fra Fedora 20 Linux på egen VM. I EstiNet setter en opp ønsket topologi og velger hendelser som skal skje, som for eksempel at TCP trafikk skal kjøre mellom to hoster, link går ned eller lignende. Når alt er klart simuleres trafikken. I etterkant kan du spille av trafikken og se pakkene forflytte seg gjennom linkene i topologien. [55 har testet Mininet og EstiNet opp mot hverandre og har funnet at ved større nettverk yter EstiNet bedre. Men på grunn av store begrensninger i gratislisensen (30 dager, maks 10 noder og 30 sekunder simuleringstid) har jeg valgt å ikke bruke EstiNet videre i mine laboratorieoppgaver. Figur 13: EstiNet brukergrensesnitt 6 6 På grunn av utløpt prøveperiode, er bildet hentet fra EstiNets hjemmeside [92. Rev: v (68)

26 5.2.3 Wireshark Wireshark [56 er et verktøy for å fange og analyse pakker, og støtter også OpenFlow pakker. Programmet kjøres enten via GUI eller rett fra kommandolinjen og henter inn pakker mens programmet kjører for senere analyse. Programmet har mange filtreringsmuligheter som hjelper for å finne frem dataen en er interessert i. Med å filtrere etter «openflow_v4» får jeg bare OpenFlow 1.3 trafikk. Merk at for å støtte OpenFlow 1.3 trengs Wireshark v.1.12.x eller nyere [57. Alt ettersom hva data jeg er på jakt etter kan programmet kjøres på kontrolleren, på Mininet VM eller direkte på enhetene i Mininet nettverket. Et eksempel på sporing av OpenFlow-pakker vises i Figur 14. Figur 14: Wireshark med støtte for OpenFlow SDN kontrollere Det finnes mange valg til SDN kontrollere [58. For å bli kjent med OpenFlow har jeg prøvd ut en del ulike controllers. Det har gitt meg et innblikk i installasjonsprosedyrer, brukergrensesnitt og funksjonalitet til ulike controllers, og kommunikasjon med OpenFlow OpenDaylight OpenDaylight (ODL) er en kontroller med åpen kildekode (open source) og med mange utviklere [58, p. 29. Den ble lansert av Linux Foundation [59 i 2013, for å fremme utvikling og støtte for SDNteknologi [60. I tillegg til støtte for OpenFlow støtter også ODL mange andre SDN protokoller [61. Den er enkel i bruk og har muligheter for tilpasning og videreutvikling. Mange av de kommersielle kontrollerene er basert på ODL. Den er skrevet i Java, og kjøres fra Linux. I mine tester har jeg installert det på Ubuntu Linux. Siste versjon ODL Beryllium ble lansert 22. februar [62. ODL har et enkelt grafisk brukergrensesnitt som en når via nettleseren som vist i Figur 15. Rev: v (68)

27 Figur 15: OpenDaylight brukergrensesnitt Floodlight Floodlight [63 er open source kontroller som er enkel i bruk med et enkelt og oversiktlig grafisk brukergrensesnitt. Versjon 1.2 er siste utgivelse i skrivende stund og har blant annet støtte for IPv6, og forbedret beskyttelse mot loop-problemer mellom ulike SDN nettverk [64. Floodlight støtter OpenFlow v1.3 og v1.0. Det er enkelt å komme i gang med Floodlight, da det er mulig å laste ned er ferdig VM klar til bruk med både Floodlight, Mininet, Open vswitch og Wireshark installert [65. Floodlight har et enkelt og oversiktlig brukergrensesnitt som en når via nettleseren, som vist i Figur 16. Figur 16: Floodlight brukergrensesnitt Rev: v (68)

28 5.3.3 HP VAN SDN Controller HP er en av de store selskapene har satset mest på SDN [24, og de fleste nye switchene støtter OpenFlow (noen trenger firmware oppdatering [66). De har sin egen kommersielle kontroller, HP VAN SDN Controller [67 som det er mulig å teste kostnadsfritt i 60 dager. HP har også en AppStore [68 hvor det er mulig å laste ned profesjonelle applikasjoner med ulik funksjonalitet. Kontrolleren har et moderne grafisk brukergrensesnitt som er oversiktlig og enkelt i bruk. Figur 17 viser et skjermbilde av brukergrensesnittet. I tillegg har de en tjeneste hvor en kan teste og kommuniserer med API via et grafisk brukergrensesnitt, og på den måten lære seg mulige spørringer en applikasjon kan bruke med kommunikasjon med kontrolleren. Figur 17: HP VAN SDN brukergrensesnitt Ryu Ryu [69 er en kontroller uten et grafisk brukergrensesnitt. Den har derimot et kommandolinjebasert brukergrensesnitt som vist i Figur 18. Ryu er skrevet i Python, og er laget for at det skal være enkelt å skrive egne utvidelser eller applikasjoner. Ryu støtter OpenFlow v1.3 og 1.0, men også noen andre SDN-protokoller. I tillegg finnes det mye god dokumentasjon [70 samt eksempler på kode for tilleggstjenester [71. På grunn av den lave terskelen for å videreutvikle kontrollerens funksjonalitet er denne godt egnet til eksperimentering og for å teste mulighetene til applikasjoner. Rev: v (68)

29 Figur 18: Ryu kommandolinje 5.4 Vurderinger av programvare og kontrollere Av praktiske årsaker valgte jeg å gjøre alt arbeid lokalt på min bærbare datamaskin. Ved hjelp av VirtualBox har det vært enkelt å komme i gang. Ved å bruke virtuelle maskiner er det ikke så farlig om noe ikke fungerer som det skal. Det har gjort det enkelt å kunne prøve mange ulike kontrollere og programvarer. Selv om EstiNet har flere muligheter var Mininet å foretrekke for å sette og for å simulere nettverk. Det fantes lite god dokumentasjon om EstiNet og prøveversjonen hadde store begrensninger i bruk. Mininet er gratis i bruk, enkel å komme i gang med i tillegg til at det finnes mye dokumentasjon og hjelp på internett. Det var interessant å se på ulike controller-alternativ. OpenDaylight har støtte for mange protokoller og gode muligheter for videreutvikling med tillegg, men også den mest kompliserte i bruk basert på mine erfaringer. Standardimplementasjonen hadde begrenset funksjonalitet. HP sin kontroller var den eneste kommersielle jeg prøvde. Med medfølgende app store med et godt utvalg applikasjoner var dette den med størst potensiale som en reel implementasjon i et bedriftsnettverk. Floodlight var enklest å komme i gang med og den hadde også god funksjonalitet i det grafiske brukergrensesnittet. For å utforske funksjonalitet til SDN og OpenFlow var denne å foretrekke for meg. Andre kontroller som jeg har blitt kjent med, men ikke skrevet om her er ONOS, NOX, POX og OneController. Rev: v (68)

30 6 Testing I denne delen gjennomføres enkle tester som demonstrerer ulike muligheter med OpenFlow og SDN teknologi. 6.1 Trafikkstyring på ulike lag Ifølge OpenFlow dokumentasjon presentert i kan en OpenFlow switch behandle pakker med mange ulike treffkriterier. For å utforske match-mulighetene i OpenFlow, vil jeg her teste og vise at OpenFlow kan matche trafikk på flere ulike lag i OSI modellen [37. For å enkelt kunne demonstrere match i en switch sin flow table settes oppføringene manuelt inn istedenfor å la switchen bli styrt av en kontroller [72. Fra switchens perspektiv vil dette bli det samme, switchen vil fremdeles kun behandle pakker som oppgitt i en flow table entry. Jeg tar med utdrag fra utskriftene under, se hele tabellutskriften i Appendiks F. Figur 19: Enkel topologi med en switch og fire hoster LAB-miljøet opprettes i Mininet med kommandoen sudo mn --controller=none --topo=single,4 - -mac som oppretter et nettverk med en switch med 4 maskiner tilkoblet. Topologien vises i Figur 19. De øvrige valgene i kommandoen sørger for at kontakt med kontroller unngås og at maskinene får enkle MAC-adresser (host 1: 00:00..01, host 2: 00: osv.). Siden switchen ikke er koblet til noen kontroller starter den med en tom flow table, og ingen pakker vil bli videresendt. Dette vises med kommandoen sh ovs-ofctl dump-flows s1 som skriver ut flow table entries på skjermen. Hostene har ikke kontakt med hverandre som en ser ut fra ping-forsøkene i Figur 20. X-ene i utskriften betyr mislykket pingforsøk. Rev: v (68)

31 mininet> sh ovs-ofctl dump-flows s1 NXST_FLOW reply (xid=0x4): mininet> pingall *** Ping: testing ping reachability h1 -> X X X h2 -> X X X h3 -> X X X h4 -> X X X *** Results: 100% dropped (0/12 received) Figur 20: Kommandoutskrift: Ingen kontakt mellom hostene Lag 1 For å demonstrere trafikkstyring via lag 1 i OSI modellen, altså via de fysiske portene, lager jeg to oppføringer i flyttabellen som gjør at host 1 og host 2 kan kommunisere. For å manuelt sette inn table flow entry bruker jeg kommandoen sh ovs-ofctl add-flow s1 sammen med ønsket match og action valg. Oppføringene som settes inn i Figur 21 spesifiserer at trafikk som kommer inn på port 1 skal ut på port 2, og omvendt. mininet> sh ovs-ofctl add-flow s1 in_port=1,actions=output:2 mininet> sh ovs-ofctl add-flow s1 in_port=2,actions=output:1 mininet> sh ovs-ofctl dump-flows s1 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=71.598s, table=0, n_packets=0, n_bytes=0, idle_age=71, in_port=1 actions=output:2 cookie=0x0, duration=70.317s, table=0, n_packets=0, n_bytes=0, idle_age=70, in_port=2 actions=output:1 mininet> pingall *** Ping: testing ping reachability h1 -> h2 X X h2 -> h1 X X h3 -> X X X h4 -> X X X *** Results: 83% dropped (2/12 received) Figur 21: Kommandoutskrift: To av hostene har kontakt via ping Som en kan se i Figur 21 har host 1 og host 2 kontakt med hverandre, mens resten av pingforsøkene mislykkes. Rev: v (68)

32 6.1.2 Lag 2 For å demonstrere trafikkstyring via lag 2 i OSI modellen, nå ved hjelp av MAC adressene til hostene, vil oppføringene forklare at pakker som kommer fra host 1 sin MAC-adresse skal sendes til host 2 sin MAC-adresse og omvendt. Jeg sørger for at hostene kan lære MAC-adressene med å floode alle ARP meldinger (ethertype 0x806 [73). mininet> sh ovs-ofctl add-flow s1 dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,actions=output:2 mininet> sh ovs-ofctl add-flow s1 dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01,actions=output:1 mininet> sh ovs-ofctl add-flow s1 dl_type=0x806,nw_proto=1,actions=flood mininet> sh ovs-ofctl dump-flows s1 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=32.058s, table=0, n_packets=0, n_bytes=0, idle_age=32, dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02 actions=output:2 cookie=0x0, duration=20.551s, table=0, n_packets=0, n_bytes=0, idle_age=20, dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01 actions=output:1 cookie=0x0, duration=6.123s, table=0, n_packets=0, n_bytes=0, idle_age=6, arp,arp_op=1 actions=flood mininet> pingall *** Ping: testing ping reachability h1 -> h2 X X h2 -> h1 X X h3 -> X X X h4 -> X X X *** Results: 83% dropped (2/12 received) Figur 22: Kommandoutskrift: MAC-adresser brukes for matching av pakker Kommandoutskriften i Figur 22 viser table flow entries som er brukt og at hostene får kontakt via ping. Tilsvarende som i har host 1 og host 2 mulighet å kommunisere, mens resten av nettverket ikke får kontakt med hverandre. Rev: v (68)

33 6.1.3 Lag 3 I OpenFlow kan flow table entries også styre trafikken i nettet ved hjelp av hostene sine IP-adresser. For enkelhetens skyld byttes ethertype ut med nøkkelordene som fungerer i Open vswitch, altså arp istedenfor 0x806 og ip istedenfor 0x800. mininet> sh ovs-ofctl add-flow s1 arp,nw_dst= ,actions=output:1 mininet> sh ovs-ofctl add-flow s1 arp,nw_dst= ,actions=output:2 mininet> sh ovs-ofctl add-flow s1 ip,nw_src= ,nw_dst= ,actions=output:2 mininet> sh ovs-ofctl add-flow s1 ip,nw_src= ,nw_dst= ,actions=output:1 mininet> pingall *** Ping: testing ping reachability h1 -> h2 X X h2 -> h1 X X h3 -> X X X h4 -> X X X *** Results: 83% dropped (2/12 received) mininet> sh ovs-ofctl dump-flows s1 NXST_FLOW reply (xid=0x4): cookie=0x0, duration= s, table=0, n_packets=2, n_bytes=196, idle_age=77, ip,nw_src= ,nw_dst= actions=output:2 cookie=0x0, duration= s, table=0, n_packets=2, n_bytes=196, idle_age=77, ip,nw_src= ,nw_dst= actions=output:1 cookie=0x0, duration= s, table=0, n_packets=8, n_bytes=336, idle_age=36, arp,arp_tpa= actions=output:2 cookie=0x0, duration= s, table=0, n_packets=8, n_bytes=336, idle_age=39, arp,arp_tpa= actions=output:1 Figur 23: Kommandoutskrift: IP adresser i flow table Figur 23 viser at IP adressene med mottaker og avsender blir brukt i flow table, og at de to oppgitte hostene får pinget hverandre. Altså samme resultat som i testene over, bare på et høyere lag i OSI modellen Lag 4 For å demonstrere lag 4 trafikkmatching, lager jeg en TCP server/klientløsning, der host 2 er en server som lytter på port 80. Via oppføringene i flyttabellen sørger jeg for at alle pakker som har destinasjonsport 80 blir sendt mot host 2. Samtidig lar jeg pakker fra host 2 bli switchet med tradisjonell switching med actions=normal. Hostene har altså kun lov å kontakte host 2 med TCP trafikk til port 80. ICMP trafikk fungerer ikke, og ingen hoster kan kommunisere med hverandre på andre måter, som Figur 24 viser. Rev: v (68)

34 mininet> sh ovs-ofctl add-flow s1 arp,actions=normal mininet> sh ovs-ofctl add-flow s1 ip,nw_proto=6,tp_dst=80,actions=output:2 mininet> sh ovs-ofctl add-flow s1 ip,nw_src= ,actions=normal mininet> pingall *** Ping: testing ping reachability h1 -> X X X h2 -> X X X h3 -> X X X h4 -> X X X *** Results: 100% dropped (0/12 received) mininet> sh ovs-ofctl dump-flows s1 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=333.69s, table=0, n_packets=11, n_bytes=828, idle_age=231, tcp,tp_dst=80 actions=output:2 cookie=0x0, duration= s, table=0, n_packets=10, n_bytes=760, idle_age=157, ip,nw_src= actions=normal cookie=0x0, duration= s, table=0, n_packets=42, n_bytes=1764, idle_age=92, arp actions=normal Figur 24: Kommandoutskrift: TCP port 80 som matchkriterie i flow table. Ingen ping Utskriftene i Figur 25 nedenfor er fra endemaskinene sine kommandobaserte brukergrensesnitt, og viser at host 2 får meldingene sendt fra Netcat [74 via TCP port 80 fra host 1 og host 3. root@mininet-vm:~# # HOST 1 root@mininet-vm:~# nc Test TCP fra H1 til H2 root@mininet-vm:~# # HOST 3 root@mininet-vm:~# nc Test TCP fra H3 til H2 root@mininet-vm:~# # HOST 2 root@mininet-vm:~# nc -l 80 Test TCP port 80 fra host 1 til host 2 root@mininet-vm:~# nc -l 80 Test TCP port 80 fra host 3 til host 2 Figur 25: Kommandoutskrift: Kommunikasjon mellom hoster via TCP port 80 Rev: v (68)

35 6.2 Pakkemodifikasjoner I dette eksempelet vil jeg vise hvordan en OpenFlow enhet kan endre pakkeinformasjon i en pakkes header. For å enkelt vise dette lager jeg et enkelt eksempel med en switch og to tilkoblete maskiner som Figur 26 viser. Host 1 kommuniserer med host 2 gjennom IP-adresse , selv om maskinen egentlig har IP-adresse Som tidligere programmerer jeg flow table manuelt istedenfor å bruke ekstern kontroller. Figur 26: Pakkemodifikasjon i switch Først så sørger jeg for at det ikke blir problemer med ARP, ved å sette en falsk IP gateway med en statisk falsk arp-oppføring på begge hostene. Figur 27 viser dette. Host 2 sin IP-adresse endres til Til slutt får switchen 2 enkle oppføringer som modifiserer avsender og destinasjonsadresse, og sender pakkene ut riktig port. Avsender endres til når host 2 kommuniserer, og mottaker endres til når host 1 kommuniserer. mininet> h1 route add default gw h1-eth0 mininet> h1 arp -s :11:11:11:11:11 mininet> mininet> h2 ifconfig h2-eth netmask mininet> h2 route add default gw h2-eth0 mininet> h2 arp -s :22:22:22:22:22 mininet> mininet> sh ovs-ofctl add-flow s1 ip,nw_dst= ,actions=mod_nw_src: ,mod_dl_dst:00:00:00:00:00:01,output:1 mininet> sh ovs-ofctl add-flow s1 ip,nw_dst= ,actions=mod_nw_dst: ,mod_dl_dst:00:00:00:00:00:02,output:2 Figur 27: Kommandoutskrift: Statisk ARP og IP gateway Rev: v (68)

36 Utskriften i Figur 28 viser at ping gjennomføres uten problemer, og hostene kan kommunisere. mininet> h1 ping PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=64 time=0.304 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.129 ms 64 bytes from : icmp_seq=3 ttl=64 time=0.149 ms 64 bytes from : icmp_seq=4 ttl=64 time=0.105 ms ping statistics packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 0.105/0.171/0.304/0.079 ms mininet> h2 ping PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=64 time=0.242 ms 64 bytes from : icmp_seq=2 ttl=64 time=0.096 ms 64 bytes from : icmp_seq=3 ttl=64 time=0.098 ms 64 bytes from : icmp_seq=4 ttl=64 time=0.102 ms ping statistics packets transmitted, 4 received, 0% packet loss, time 3002ms rtt min/avg/max/mdev = 0.096/0.134/0.242/0.063 ms Figur 28: Kommandoutskrift: Kommunikasjon via ping mellom hostene På Wireshark-utskriftene i Figur 29 og Figur 30 kan en se at host 2 sin IP-adresse endres uten at maskinene er klar over dette. Figur 29: Wireshark H1 Rev: v (68)

37 Figur 30: Wireshark H2 I dette eksempelet har switchen endret informasjon i pakkenes IP-header, og i praksis fungert som en NAT-enhet (Network Address Translation). 6.3 VLANs For å demonstrere bruk av VLAN tag i OpenFlow og Open vswitch settes to switcher opp med tre maskiner koblet til hver, som Figur 31 viser. Figur 32 konfigurerer hver switch til at host 1 blir satt til VLAN 10, host 2 til VLAN 20 og host 3 til VLAN 30. Switchene får en flow table entry hver som sørger for tradisjonell switching. Linken mellom switchene gjøres om til en trunk-link som støtter alle tre VLAN. Figur 31: VLAN lab topologi Rev: v (68)

38 mininet> sh ovs-vsctl set port s1-eth1 tag=10 mininet> sh ovs-vsctl set port s2-eth1 tag=10 mininet> sh ovs-vsctl set port s1-eth2 tag=20 mininet> sh ovs-vsctl set port s2-eth2 tag=20 mininet> sh ovs-vsctl set port s1-eth3 tag=30 mininet> sh ovs-vsctl set port s2-eth3 tag=30 mininet> sh ovs-vsctl set port s1-eth3 trunks=10,20,30 mininet> sh ovs-vsctl set port s2-eth3 trunks=10,20,30 mininet> sh ovs-ofctl add-flow s1 actions=normal mininet> sh ovs-ofctl add-flow s2 actions=normal Figur 32: Kommandoutskrift: Konfigurering av VLAN tag i Open vswitch Figur 33 viser at pingforsøk mellom alle enheter viser at kun maskinene innenfor samme VLAN får muligheten til å kommunisere, til tross for at IP-adressene er naboer i samme nettverk. mininet> pingall *** Ping: testing ping reachability h1s1 -> h1s2 X X X X h1s2 -> h1s1 X X X X h2s1 -> X X h2s2 X X h2s2 -> X X h2s1 X X h3s1 -> X X X X h3s2 h3s2 -> X X X X h3s1 *** Results: 80% dropped (6/30 received) Figur 33: Kommandoutskrift: Ping vellykket innenfor samme VLAN Rev: v (68)

39 Det vil også kunne være mulig å endre VLAN-taggene i flyttabellene. I eksempelet Figur 34 modifiseres VLAN-headeren slik at maskinene på en switch kan nå både VLAN 10 og 20 på motsatt switch. sh ovs-ofctl add-flow s1 ip,nw_src= ,nw_dst= ,actions=mod_vlan_vid:20,output:2 sh ovs-ofctl add-flow s1 arp,nw_src= ,nw_dst= ,actions=mod_vlan_vid:20,output:2 sh ovs-ofctl add-flow s1 ip,nw_src= ,nw_dst= ,actions=mod_vlan_vid:20,output:4 sh ovs-ofctl add-flow s1 arp,nw_src= ,nw_dst= ,actions=mod_vlan_vid:20,output:4 sh ovs-ofctl add-flow s1 ip,nw_src= ,nw_dst= ,actions=mod_vlan_vid:10,output:1 sh ovs-ofctl add-flow s1 arp,nw_src= ,nw_dst= ,actions=mod_vlan_vid:10,output:1 sh ovs-ofctl add-flow s1 ip,nw_src= ,nw_dst= ,actions=mod_vlan_vid:10,output:4 sh ovs-ofctl add-flow s1 arp,nw_src= ,nw_dst= ,actions=mod_vlan_vid:10,output:4 sh ovs-ofctl add-flow s1 priority=0,actions=normal sh ovs-ofctl add-flow s2 ip,nw_src= ,nw_dst= ,actions=mod_vlan_vid:20,output:2 sh ovs-ofctl add-flow s2 arp,nw_src= ,nw_dst= ,actions=mod_vlan_vid:20,output:2 sh ovs-ofctl add-flow s2 ip,nw_src= ,nw_dst= ,actions=mod_vlan_vid:20,output:4 sh ovs-ofctl add-flow s2 arp,nw_src= ,nw_dst= ,actions=mod_vlan_vid:20,output:4 sh ovs-ofctl add-flow s2 ip,nw_src= ,nw_dst= ,actions=mod_vlan_vid:10,output:1 sh ovs-ofctl add-flow s2 arp,nw_src= ,nw_dst= ,actions=mod_vlan_vid:10,output:1 sh ovs-ofctl add-flow s2 ip,nw_src= ,nw_dst= ,actions=mod_vlan_vid:10,output:4 sh ovs-ofctl add-flow s2 arp,nw_src= ,nw_dst= ,actions=mod_vlan_vid:10,output:4 sh ovs-ofctl add-flow s2 priority=0,actions=normal mininet> pingall *** Ping: testing ping reachability h1s1 -> h1s2 X h2s2 X X h1s2 -> h1s1 h2s1 X X X h2s1 -> X h1s2 h2s2 X X h2s2 -> h1s1 X h2s1 X X h3s1 -> X X X X h3s2 h3s2 -> X X X X h3s1 *** Results: 66% dropped (10/30 received) Figur 34: Kommandoutskrift: Endring av VLAN ID Rev: v (68)

40 6.4 Eksempel på bruk av STP i OpenFlow fra Ryu Selv om de fleste kontrollere ikke tar i bruk STP, viser [75 at det er mulig å bruke STP i et SDN nettverk. Med Ryu-kontrolleren følger det med en applikasjon [76 som bruker STP i et nettverk med OpenFlow-switcher, inkludert utveksling av BPDU og blokkering av porter. Jeg satt opp en enkel topologi i Mininet (Figur 35) som sørger for to stier mellom alle maskiner, og altså mulighet for loop. Så snart Ryu applikasjonen starter begynner switchene med STP og utvelgelse av root (se tabellutskrift i Appendiks E ). Her vinner S1 på grunn av den laveste dpid (datapath-id) Etter alle kalkulasjoner blir port 2 på s3 blokkert, og STP har unngått muligheter for looping i OpenFlow. Figur 35: STP i et SDN-nettverk Dersom en port går ned, sendes en OFPT_PORT_STATUS melding fra gjeldende switch til kontrolleren med flagg som markerer link down, og kontrolleren iverksetter rekalkulering av STP. Rev: v (68)

41 6.5 Flere tabeller og prioritet For å demonstrere bruk av flere tabeller i OpenFlow, lager jeg nettverkstopologien vist i Figur 36. Dette nettverket flooder all trafikk som ikke skal til den lokalt tilkoblete host-maskinen. For å unngå looping, benyttes reverse path forwarding (RPF) [77. Dette kan enkelt designes med de to tabellene som vises i Figur 37. Figur 36: Topologi. Hver switch flooder innkommende meldinger, og benytter seg av RPF S1 Tabell 0 S1 Tabell 1 Destinasjon Send til tabell 2 Avsender og inport 2? Lever til H1 Alle andre pakker FLOOD Avsender og inport 3? Lever til H1 (har lavere prioritet) Andre pakker DROP (implicit deny) Figur 37: Tabeller som trengs for å bruke RPF Table flow entries som trengs på alle switcher vises i Figur 38. Det brukes også ulik prioritering. Prioritet 0 vil bli brukt på pakker som ikke finner treff i oppføringene med høyere prioritet. Uten å spesifisere blir prioritet satt til default, som er Resubmit sender pakker som matcher videre til neste tabell. Dette resulterer i at nettverket fungerer som det skal, alle får kontakt med alle, og det forekommer ingen looping. Rev: v (68)

42 # S1 table=0,ip,nw_dst= ,actions=resubmit(,1) table=0,arp,nw_dst= ,actions=resubmit(,1) table=0,priority=0,actions=flood table=1,ip,nw_src= ,in_port=2,actions=output:1 table=1,arp,nw_src= ,in_port=2,actions=output:1 table=1,ip,nw_src= ,in_port=3,actions=output:1 table=1,arp,nw_src= ,in_port=3,actions=output:1 # S2 table=0,ip,nw_dst= ,actions=resubmit(,1) table=0,arp,nw_dst= ,actions=resubmit(,1) table=0,priority=0,actions=flood table=1,ip,nw_src= ,in_port=1,actions=output:2 table=1,arp,nw_src= ,in_port=1,actions=output:2 table=1,ip,nw_src= ,in_port=3,actions=output:2 table=1,arp,nw_src= ,in_port=3,actions=output:2 # S3 table=0,ip,nw_dst= ,actions=resubmit(,1) table=0,arp,nw_dst= ,actions=resubmit(,1) table=0,priority=0,actions=flood table=1,ip,nw_src= ,in_port=1,actions=output:3 table=1,arp,nw_src= ,in_port=1,actions=output:3 table=1,ip,nw_src= ,in_port=2,actions=output:3 table=1,arp,nw_src= ,in_port=2,actions=output:3 Figur 38: Nødvendige kommandoer i de tre OVS-switchene Fordelen med to tabeller er at interessant trafikk kan videresendes til neste tabell for behandling, mens resterende pakker floodes. Flere tabeller gjør flyttabellen mer oversiktlig og mer effektiv. [78 bruker RPF som et eksempel, og forklarer at med bruk av en tabell trenger en N 2 oppføringer med en tabell, men 2*N oppføringer ved bruk av flere tabeller. 6.6 Nordgående interface, RESTful API Jeg skal i dette avsnittet se på hvordan tredjeparts applikasjoner kan bruke det nordgående interface til å få info fra kontroller, og til å gjøre endringer i det underliggende nettverket. Jeg bruker Floodlights VM [79 som har ferdiginstallert kontroller og Mininet, samt at Floodlight har god dokumentasjon [80 på bruk av det nordgående interface. [81 har også en beskrivelse på hvordan en kan komme i gang med å bruke REST mot OpenDaylight. Kontrolleren startes med sudo java -jar target/floodlight.jar, og jeg har laget en enkel topologi som vist i Figur 40. Topologien er skrevet i Python (kodeutskrift i Figur 39). Nettverket startes med kommandoen sudo mn -- custom=mininet_topo_alt_paths.py --topo=mytopo --controller=remote,ip= ,port= mac. Kommandoen spesifiseres at python-koden skal brukes til topologi, og at kontrolleren befinner seg lokalt på port Rev: v (68)

43 mininet_topo_alt_paths.py from mininet.topo import Topo class MyTopo ( Topo ): def init ( self ): Topo. init ( self ) # add switches and hosts lefthost = self.addhost('h1') righthost = self.addhost('h2') leftswitch = self.addswitch('s1') centreswitchtop = self.addswitch('s2') centreswitchbottom = self.addswitch('s3') rightswitch = self.addswitch('s4') # add links self.addlink(lefthost, leftswitch) self.addlink(leftswitch, centreswitchtop) self.addlink(leftswitch, centreswitchbottom) self.addlink(centreswitchtop, rightswitch) self.addlink(centreswitchbottom, rightswitch) self.addlink(rightswitch, righthost) topos = { 'mytopo': ( lambda: MyTopo() ) } Figur 39: Python-kode for topologien i Mininet Figur 40: Topologi, ping mellom maskinene tar ulik sti frem og tilbake For å hente info om nettverket via REST bruker jeg CURL [82 som tar av seg sending av spørringene. Jeg filtrerer svaret gjennom Python sitt JSON verktøy som viser utskriften med et oppsett som er enkelt å lese. Uten dette filteret kommer hele utskriften i en linje. Kommandoen curl python -m json.tool leverer tilbake infoen om switchene i Figur 41. Rev: v (68)

44 curl python -m json.tool % Total % Received % Xferd Average Dload Speed Upload Time Total Time Spent Time Left Current Speed :--:-- --:--:-- --:--: [ { "connectedsince": , "inetaddress": "/ :45948", "switchdpid": "00:00:00:00:00:00:00:01" }, { "connectedsince": , "inetaddress": "/ :45950", "switchdpid": "00:00:00:00:00:00:00:02" }, { "connectedsince": , "inetaddress": "/ :45949", "switchdpid": "00:00:00:00:00:00:00:03" }, { "connectedsince": , "inetaddress": "/ :45944", "switchdpid": "00:00:00:00:00:00:00:04" } floodlight@floodlight:~/floodlight$ Figur 41: Kommandoutskrift: Svar på spørring mot controller I tillegg til å hente info er det også mulig å gjøre endringer i nettverket via det nordgående interface. Det er for eksempel mulig å legge inn manuelle oppføringer i switchenes flow table. For å vise dette setter jeg inn manuelle oppføringer på switchene via REST som gjør at trafikk fra H1 til H2 går via S2, mens trafikk fra H2 til H1 går via S3. Kommandoene vises i Figur 42. Rev: v (68)

45 curl -X POST -d '{"switch": "00:00:00:00:00:00:00:01", "name":"flow-mod-1", "cookie":"0", "priority":"100", "in_port":"1","active":"true", "actions":"output=2"}' curl -X POST -d '{"switch": "00:00:00:00:00:00:00:02", "name":"flow-mod-2", "cookie":"0", "priority":"100", "in_port":"1","active":"true", "actions":"output=2"}' curl -X POST -d '{"switch": "00:00:00:00:00:00:00:04", "name":"flow-mod-3", "cookie":"0", "priority":"100", "in_port":"1","active":"true", "actions":"output=3"}' curl -X POST -d '{"switch": "00:00:00:00:00:00:00:04", "name":"flow-mod-4", "cookie":"0", "priority":"100", "in_port":"3","active":"true", "actions":"output=2"}' curl -X POST -d '{"switch": "00:00:00:00:00:00:00:03", "name":"flow-mod-5", "cookie":"0", "priority":"100", "in_port":"2","active":"true", "actions":"output=1"}' curl -X POST -d '{"switch": "00:00:00:00:00:00:00:01", "name":"flow-mod-6", "cookie":"0", "priority":"100", "in_port":"3","active":"true", "actions":"output=1"}' Figur 42: Kommandoutskrift: Endringer i switchers flow table Prioriteten på 100 overskriver switchenes oppføring for kontakt til kontroller som har prioritet 0. Den overskriver også oppføringer som kontrolleren selv lager som har prioritet 1. Rev: v (68)

46 Jeg kan få bekreftet at oppføringene er på plass ved å sende en ny spørring. Flow table entries til S1 vises i Figur 43. floodlight@floodlight:~/floodlight$ curl python -m json.tool { "00:00:00:00:00:00:00:01": [ { "flow-mod-1": { "command": "ADD", "cookie": " ", "cookiemask": "0", "flags": "1", "hardtimeoutsec": "0", "idletimeoutsec": "0", "instructions": { "instruction_apply_actions": { "actions": "output=2" } }, "match": { "in_port": "1" }, "outgroup": "any", "outport": "any", "priority": "100", "version": "OF_13" } }, { "flow-mod-6": { "command": "ADD", "cookie": " ", "cookiemask": "0", "flags": "1", "hardtimeoutsec": "0", "idletimeoutsec": "0", "instructions": { "instruction_apply_actions": { "actions": "output=1" } }, "match": { "in_port": "3" }, "outgroup": "any", "outport": "any", "priority": "100", "version": "OF_13" } } } Figur 43: Kommandoutskrift: Spørring via REST, info om S1 Rev: v (68)

47 For å se om trafikken tar de ønskede stiene gjennom switchene, sendes det mange ping-meldinger mellom de to host-maskinene. Figur 44 viser switchenes flyttabeller, og at all trafikk passerer som ønsket. mininet> sh ovs-ofctl dump-flows s1 NXST_FLOW reply (xid=0x4): cookie=0xa d1a6, duration= s, table=0, n_packets=1551, n_bytes=151886, idle_age=0, priority=100,in_port=1 actions=output:2 cookie=0xa d1ab, duration= s, table=0, n_packets=2568, n_bytes=311827, idle_age=0, priority=100,in_port=3 actions=output:1 cookie=0x0, duration= s, table=0, n_packets=1602, n_bytes=283498, idle_age=0, priority=0 actions=controller:65535 mininet> sh ovs-ofctl dump-flows s2 NXST_FLOW reply (xid=0x4): cookie=0xa d1a7, duration= s, table=0, n_packets=2062, n_bytes=231986, idle_age=0, priority=100,in_port=1 actions=output:2 cookie=0x0, duration= s, table=0, n_packets=1043, n_bytes=178931, idle_age=1, priority=0 actions=controller:65535 mininet> sh ovs-ofctl dump-flows s3 NXST_FLOW reply (xid=0x4): cookie=0xa d1aa, duration= s, table=0, n_packets=2043, n_bytes=229358, idle_age=0, priority=100,in_port=2 actions=output:1 cookie=0x0, duration= s, table=0, n_packets=1952, n_bytes=347795, idle_age=2, priority=0 actions=controller:65535 mininet> sh ovs-ofctl dump-flows s4 NXST_FLOW reply (xid=0x4): cookie=0xa d1a8, duration= s, table=0, n_packets=2574, n_bytes=312579, idle_age=0, priority=100,in_port=1 actions=output:3 cookie=0xa d1a9, duration= s, table=0, n_packets=1559, n_bytes=152670, idle_age=0, priority=100,in_port=3 actions=output:2 cookie=0x0, duration= s, table=0, n_packets=1252, n_bytes=217136, idle_age=4, priority=0 actions=controller:65535 Figur 44: Kommandoutskrift: Switchenes flow tables, med antall pakker sendt. Trafikk bruker begge stier. 6.7 Observasjoner gjort fra testene Det var enkelt å sette seg inn i OpenFlow sin funksjonalitet. Ved å lage manuelle oppføringen ble det enklere for meg å teste hvordan trafikk kan påvirkes og manipuleres fra flow table entries. På denne måten fikk jeg få et innblikk i hvorfor NFV vil gjøre det mulig å flytte tidligere hardware-enheter over i software. Det er mange valg i hvordan en pakke skal matches og hvordan den skal bli behandles før videresending. På denne måten kan avanserte funksjoner fra for eksempel rutere eller brannmurer kjøres direkte i en enkel OpenFlow-aktivert switch. I et vanlig nettverk befinner det seg i dag utrolig mange ulike enheter som flytter seg og endrer behov. Det å kunne sette i bruk funksjoner der de trengs og raskt kunne flytte funksjonalitet ser jeg på som en viktig brikke til hvorfor SDN har fått så mye oppmerksomhet. Rev: v (68)

48 VLAN separering av nettverk er en vanlig og viktig del av bedriftsnettverk for å kunne separere ulike avdelinger eller sikkerhetsnivåer. Trafikk blir adskilt selv om den flyter på samme switch. Siden OpenFlow støtter matching og modifikasjon av VLAN-tags vil denne funksjonaliteten leve videre i et OpenFlow nettverk. Før jeg satte i gang med oppgaven var jeg usikker på hvordan looping kunne bli unngått i nettverket når ikke STP var i bruk. Men siden alle avgjørelser blir tatt hos kontroller, som har oversikt over hele nettverkstopologien, vil det ikke oppstå looping så lenge kontrolleren er programmert til å ta hensyn til dette. Eksempelapplikasjonen i Ryu viser også at det er mulig å benytte seg av STP på samme måte som i et tradisjonelt nettverk, bare at OpenFlow switchenes DPID benyttes for istedenfor bridge-id. OpenFlow hadde i versjon 1.0 kun støtte for en enkelt flow table. Versjon 1.3 støtter flere tabeller, og det å kunne videresende trafikk til annen tabell for videre prosessering gjør det enklere å ha oversikt over switchens pakkebehandling. Det vil også senke antall nødvendige oppføringer betraktelig og dermed kjøre raskere i systemet. Jeg ønsket å teste det nordgående interface selv om jeg ikke skulle skrive en applikasjon til denne oppgaven. REST gjorde det enkelt både å hente ut informasjon om nettverket fra kontrolleren, og å gjøre egne endringer i nettverket. Det var enkelt å skrive mitt eksempel som valgte hvilken sti trafikken skulle ta gjennom nettverket mellom to hoster. Det vil selvfølgelig bli mer komplisert når det skal skrives mer avanserte programmer i større nettverk, men utfordringene her står ikke på selve kommunikasjonen mellom kontroller og programmet. Dersom nettverksadministrator ønsker å programmere en applikasjon med en bestemt funksjonalitet må det gjøres med forsiktighet. Om noen går galt kan dette få konsekvenser for hele nettverket. 7 Vurdering. SDN i dag I denne delen diskuteres mulighetene og utfordringene med å gå over til SDN i dag slik utviklingen har vært til nå. 7.1 Applikasjoner Utviklingen rundt internett går raskt. Allerede i dag er de en selvfølge at datamaskiner og mobile enheter har tilgang til internett i de aller fleste bedrifter, samt hjemme. Nettverk er ikke nødvendigvis statisk plasserte topologier, og antall enheter som deltar i et nettverk blir større. Fordelene rundt å separere dataplanet og kontrollplanet er mange, og det er liten tvil om at SDNteknologien er kommet for å bli. Ved å sentralisere kontrollogikken i nettverket får kontrolleren total oversikt over det underliggende nettverket. Dette gir alle nordgående applikasjoner samme informasjon om nettverket, og kontrolleren gir applikasjonene mulighet til å gjøre endringer i hele nettverket. Standardiserte protokoller gjør det lettere å programmere sofistikerte applikasjoner som har dynamiske nettverksfunksjoner og tjenester [83. Det er mange ulike protokoller og kontrollere, og mange utviklere og leverandører som utforsker SDN og tilbyr SDN relaterte løsninger. En av hovedfordelene til SDN er muligheten for å tilby tredjeparts applikasjoner (i det nordgående interface) og dermed kunne tilpasse tjenester for ulike nettverk etter behov. For at SDN skal bli et reelt valg for mindre bedrifter trengs det et stort utvalg SDN-applikasjoner. Men før dette kan komme på plass må utviklingen spisse seg inn på et sett med Rev: v (68)

49 standarder som med bred støtte. Som Curt Beckmann fra ONF sier i en samtale med PacketPushers [84, er det i dag liten eller ingen utvikling av profesjonelle applikasjoner (nordgående), fordi det rett og slett finnes for mange kontrollere, og de underliggende parameterne endrer seg til stadighet. I det sørgående interface er OpenFlow i dag den ledende protokollen. Dette er mye takket være at Open Networking Foundation [1 har overtatt utviklingen, og har et stort nettverk av utviklere og arbeidgrupper som jobber med videre utvikling. De aller fleste kontrollerne støtter også OpenFlow, hovedsakelig versjon 1.0 og etter hvert versjon 1.3. Men til tross for at OpenFlow er mye tatt i bruk kunne den vært enda mer optimalisert. [85 har sammenlignet OpenFlow og ProGFE som er en annen sørgående SDN-protokoll. Resultatet viser at ProGFE har bedre ytelse i alle de ulike testscenarioer. Som vist tidligere finnes det også svært mange kontrollere, både kommersielle levert av større leverandører og via fri utvikling med åpen kildekode. Kontrollerne i seg selv tilbyr vanligvis ikke så mye funksjonalitet ut v boksen. Det følger som oftest med et grafisk (eller kommandolinjebasert) brukergrensesnitt, grunnleggende lag 2 pakkesending, som vanligvis benytter seg av SPF algoritmer (Shortest Path First), samt støtte for applikasjoner og programtillegg. Nyttige og velutviklede applikasjoner kommer trolig ikke før utviklingen av kontrollere er stabilisert seg. I dag er det mye som tyder på at OpenDaylight til slutt kommer til å bli den ledende kontrolleren. OpenDaylight har fått mye oppmerksomhet og har mange utviklere, hovedsakelig på grunn av at det blir utviklet av The Linux Foundation. I tillegg støtter OpenDaylight mange ulike protokoller, og ikke bare OpenFlow. Programmering av applikasjoner kan gi nettverksadministrator store muligheter for kontroll og oversikt over sitt nettverk. Applikasjoner kan designes til å utføre spesifikke handlinger og tilpasses som det måtte ønskes. I tillegg kan en applikasjon automatisk reagere på endringer i nettverket og gjøre nødvendige tilpasninger i trafikkflyten. Men for mellomstore bedrifter som bare en liten gruppe nettverksadministratorer vil det være komplisert å ta i bruk det nordgående interfacet uten velutviklede kommersielle applikasjoner. En gjennomsnittlig nettverksadministrator har begrenset med programmeringskunnskaper, og det vil kreve mye arbeid å sikre feilfri programkode. Selv små feil kan få store konsekvenser for nettverket. Den enkleste måten å komme i gang med det nordgående interfacet er med API REST, men den har begrensninger. REST benytter seg av request/response forespørsler. Dette gjør at den bare er i stand til å ta proaktive beslutninger [81. For å kunne gjøre reaktive beslutninger trenger applikasjonen å få tak i kontrollerens PACKET-IN pakker, altså pakkene som switch sender kontroller når den ikke vet hva den skal gjøre [86. Dette er mulig gjennom OpenDaylights OSGi komponent [87, men dette er også en mer komplisert programmeringsutfordring. 7.2 Sikkerhet Det er mange fordeler med å sentralisere kontrollplanet, men det dukker også opp nye utfordringer spesielt innen sikkerhet. Det umiddelbare problemet er controllers single point of failure. Dersom det oppstår en feil på controller, kan dette gå ut over hele nettverket. Heldigvis kan det skapers controller redundans ved å benytte seg av master/slave funksjonalitet, og ha backup controller som automatisk tar over når problemer oppstår. Det er også mulig å ha flere controller som styrer ulike deler av nettverket. I [88 tar forfatterne en grundig gjennomgang av sikkerhet i SDN. På grunn av sentralisert kontroll er nettverket mer sårbar for DoS (Denial of Service) angrep. En angriper kan fylle kontroller med falske Rev: v (68)

50 forespørsler eller fylle switchen med falske flow table entries, og på den måte hindre systemet i å fungere som det skal. Dersom en angriper får tilgang til kontrolleren vil han ha full oversikt og kontroll over hele nettverket. Kommunikasjon mellom switch og kontroller bør være kryptert. OpenFlow støtter TLS, men dette er enda ikke tatt så mye i bruk i praksis. Nye utfordringer kommer også ved applikasjonslaget. Ved å tilby tredjeparts applikasjoner tilgang til å gjøre endringer i nettverket må det være helt sikkert at applikasjonene ikke er ondsinnet eller at de inneholder feil. Det sentraliserte designet gjør at selv små feil kan få konsekvenser for hele nettverket. [89 konkluderer med at sikkerhet i SDN har fått lite fokus og at sikkerheten i kommunikasjon mellom switch og kontroller trenger mer arbeid. 7.3 Overgang til SDN Som testene i kapittel 6 har vist, byr OpenFlow og SDN på mange muligheter i et nettverk. På grunn av at avgjørelsene blir tatt i software og OpenFlows muligheter for match og actions i switchens flow table, kan en switch utføre mange av nettverkstjenestene som i dagens nettverk er fysiske nettverksenheter. Med NFV flyttes tjenester som load balancing, QoS, brannmurer og IDS (Intrution Detection System) over i software. I tillegg til å være fleksible tjenester som kan tas i bruk hvor og når det trengs, vil dette være kostnadsbesparende for bedrifter. Nettverkene blir med tiden mer kompliserte, og med fremgangen av IoT (Internet of Things) skal flere og flere ulike enheter ha tilgang til nettverket. Ved å bruke SDN-teknologi, kan en forenkle de mer og mer komplekse nettverkene. Et fungerende SDN-nettverk automatiserer mange av en nettverksadministrators oppgaver. Design med sentralisert kontroll forenkler mange ulike utfordringer med nettverket. Nettverksadministrator har et godt grunnlag for avansert monitorering. Hele nettverket kan dynamisk tilpasse seg endringer, som minimerer omfanget av nedetid ved problemer med nettverksenhet. Det blir også eklere å innføre nye policy regler eller endre trafikkmønsteret ved stor belastning på en link. Testene som er gjort i oppgaven har vist at det er enkelt å komme i gang med SDN. Det finnes mange kontrollere på markedet, og mer og mer fysisk utstyr støtter OpenFlow og andre SDN-protokoller. Slik det er i dag vil det kreve mye arbeid for en nettverksadministrator å kunne administrere et fullt SDN nettverk. Det er enda mange sikkerhetsutfordringer og det er ikke et stort utvalg av applikasjoner som kan støtte mange tenkelige scenarioer. For å unngå problemer bør SDN introduseres gradvis i en bedrifts nettverk. Et fornuftig sted å starte er i datasenteret, mellom virtuelle datamaskiner. ONF anbefaler 4 steg på veien mot SDN i en bedrifts nettverk [90. Først vurdere hvordan SDN vil hjelpe bedriften og kundene, og vurdere hvordan SDN vil påvirke nettverket. Ansatte må læres opp til å beherske nødvendig kunnskap, og migreringen må skje forsiktig. I en større rapport [91 presenterer ONF også noen reelle eksempler på bedrifter som har migrert til SDN, Google sitt WAN nettverk, NTT sin BGP edge-router og deler av Stanford University sin Campus. Dette er spesielle løsninger, og bedrifter med store team av nettverksadministratorer. Eksemplene er derfor ikke direkte overførbare til vanlige bedrifter. Rev: v (68)

51 Ved å gå over til white boxes, kan bedrifter redusere store innkjøpskostnader, og spare seg for store utgifter. Åpne nettverksoperativsystem gir administratorer store tilpasningsmuligheter, og gjør det billigere og raskere å introdusere nye funksjoner og tjenester i switchene. Disse løsningene kan også støtte SDN protokoller og senke barrieren for å introdusere SDN i deler av nettverket. 8 Konklusjon SDN handler hovedsakelig om å separere hardware og software funksjonalitet. På denne måten vil nettverk blir mer dynamisk og tilpasningsdyktig til nye og oppdaterte tjenester i nettverket. OpenFlow er en protokoll som gjør at nettverksenheter blir rene forwarding enheter, mens alle avgjørelser hvordan pakkene skal bli behandlet blir tatt i en sentral enhet. OpenFlow har mye støtte av store aktører og gir nye egenskaper til enkel forwarding enheter ved hjelp av kommunikasjon med controller og en flow table med mange match og action alternativer. Google og flere andre store bedrifter bruker SDN teknologi i sine underliggende nettverk. Jeg var interessert i om teknologien er klar i dag til å tas i brukes i vanlige bedriftsnettverk med få nettverksadministratorer og et antall nettverksenheter som er overkommelig å administrere manuelt. Den programmerbare nordgående interfacet, og introduksjon til NFV funksjonalitet vil gjøre introduksjon av nye nettverksfunksjoner billigere og mer fleksibelt. Men den underliggende teknologien, kontrollplanet, har ikke standardisert seg nok til at proffe kommersielle applikasjonsløsninger er utviklet. Det finnes mange valg av controller på markedet. OpenDaylight er den med flest utviklere og støtte for mange ulike protokoller. Slik jeg ser det er SDN et felt som nettverksadministratorer må følge med på å lære seg opp i. Det er enda ikke utviklet nok til å erstatte det tradisjonelle nettverket i bedriften, men kan etter hvert gradvis implementeres, med start mellom virtuelle servermaskiner, og i bedriftens data senter. Ved interesse etter ytterlig informasjon om SDN, vil jeg spesielt anbefale hjemmesiden til Open Networking Foundation [1, artikkelen Software-Defined Networking: A Comprehensive Survey [83 og GNS3 Academy sitt videokurs Practical SDN and OpenFlow Fundamentals [92. Rev: v (68)

52 Appendiks A Litteraturliste [1 Open Networking Foundation, «Software-Defined Networking (SDN) Definition,» [Internett. Available: [Funnet 22 Januar [2 Open Networking Foundation, «OpenFlow,» Open Networking Foundation, [Internett. Available: [Funnet 13 Mai [3 D. Pitt, «The Secret of the 5G Bandwagon: SDN Is the Engine,» Light Reading, 4 April [Internett. Available: [Funnet 18 Mai [4 S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh, S. Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. Hölzle, S. Stuart og A. Vahdat, «B4: Experience with a Globally-Deployed Software Defined WAN,» Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM (SIGCOMM '13), nr. DOI= pp. 3-14, [5 Google - Urs Hoelzle, Google,» Open Networking Summit, 7 Mai [Internett. Available: [Funnet 25 April [6 Y. Bachar og A. Simpkins, «Introducing Wedge and FBOSS, the next steps toward a disaggregated network,» Facebook, 18 Juni [Internett. Available: [Funnet 23 April [7 Microsoft Azure, «Software-defined networking solutions,» [Internett. Available: [Funnet 23 April [8 The Cisco Learning Network, «CCNA Routing and Switching Certification,» Mai [Internett. Available: [Funnet 30 Mai [9 R. Enns, M. Bjorklund, J. Schoenwaelder og A. Bierman, «RFC Network Configuration Protocol (NETCONF),» IETF, [10 [11 J. Case, M. Fedor, M. Schoffstall og J. Davin, «RFC A Simple Network Management Protocol (SNMP),» IETF, Open Networking Foundation, «OpenFlow Configuration and Management Protocol 1.0,» [Internett. Available: [Funnet 20 Mai Rev: v (68)

53 [12 [13 [14 [15 [16 [17 [18 [19 [20 [21 [22 [23 Open Networking Foundation, «ONF TS-016 : OpenFlow Management and Configuration Protocol 1.2,» [Internett. Available: [Funnet 20 Mai «Open vswitch,» [Internett. Available: [Funnet 25 April D. Bombal, «GNS3 Academy: Practical SDN and OpenFlow Fundamentals - Raspberry pi Part 1,» GNS3, 12 Oktober [Internett. Available: [Funnet 23 Mai Raspberry Pi Foundation, «Teach, learn and make with Raspberry Pi,» [Internett. Available: [Funnet 23 Mai B. Pfaff og E. B. Davie, «RFC The Open vswitch Database Management Protocol,» IETF, Cumulus Networks, «Cumulis Linux,» [Internett. Available: [Funnet 25 April Pica8 Inc., «Pica8,» [Internett. Available: [Funnet 25 April PacketPushers, «List Of Network Operating Systems,» PacketPushers, [Internett. Available: [Funnet 27 April Y. Bachar, «Introducing 6-pack : the first open hardware modular switch,» Facebook, 11 Februar [Internett. Available: [Funnet 18 Mai C. Matsumoto, «HP Launches OpenSwitch, Yet Another Open Network OS,» SDxCentral, 5 October [Internett. Available: [Funnet 18 Mai HPE LP, «OpenSwitch,» [Internett. Available: [Funnet 18 Mai Hewlett Packard Enterprise Development LP, «Fixed Port L3 Managed Ethernet Switches - HPE Altoline 6920 Switch Series,» [Internett. Available: [Funnet 18 Mai Rev: v (68)

54 [24 [25 [26 [27 [28 [29 [30 [31 [32 [33 [34 [35 [36 J. Duffy, «HP serves up its open switches,» Network World, 24 August [Internett. Available: [Funnet 18 Mai SDxCentral, «2016 Mega NFV Report Pt. 1: MANO and NFVI,» SDxCentral, SDxCentral, «Which is Better SDN or NFV?,» [Internett. Available: [Funnet 22 April R. White, «What Is Service Chaining?,» PacketPushers, 9 August [Internett. Available: [Funnet 24 Mai J. Guichard, «RFC Service Function Chaining (SFC) Architecture,» IETF, 28 Mars [Internett. Available: [Funnet 24 Mai M. Casado, «The Virtual Network System,» Stanford University, Stanford, N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker og J. Turner, «OpenFlow: Enabling Innovation in Campus Networks,» SIGCOMM Comput. Commun. Rev., vol. 38, nr. 2, pp , Open Networking Foundation, «Board of Directors,» [Internett. Available: [Funnet 20 Mai Cisco, «OpFlex: An Open Policy Protocol White Paper,» Cisco, 17 Oktober [Internett. Available: [Funnet 30 Mai P. Lapukhov og E. Nkposong, «Centralized Routing Control in BGP Networks Using Link-State Abstraction,» Network Working Group, 2 September [Internett. Available: [Funnet 30 Mai Open Network Foundation, «OpenFlow Switch Specification, Version (Protocol version 0x06),» Open Network Foundation, Open Networking Foundation, «OpenFlow Switch Specification, Version (Wire Protocol 0x01),» Open Networking Foundation, Open Networking Foundation, «OpenFlow Switch Specification, Version (Wire Protocol 0x04),» ONF TS-006, Rev: v (68)

55 [37 [38 [39 [40 [41 [42 [43 [44 [45 [46 [47 [48 Wikipedia, «OSI model,» 8 Mai [Internett. Available: [Funnet 10 Mai S. Y. Wang, C. C. Wu og C. L. Chou, «Constructing an optimal spanning tree over a hybrid network with SDN and legacy switches,» 2015 IEEE Symposium on Computers and Communication (ISCC), nr. doi: /ISCC , pp , IEEE Corporate, «IEEE P802.3ad Link Aggregation Task Force,» 16 November [Internett. Available: [Funnet 10 Mai N. Finn, «Port Aggregation Protocol,» IEEE, Cisco Systems, Ryu, «simple_switch_lacp_13.py,» 18 Februar [Internett. Available: [Funnet 4 Mai RYU project team, «Ryu 1.0 Documentation: Link Aggregation,» Ryu, [Internett. Available: [Funnet 27 April A. Al-Najjar, S. Layeghy og M. Portmann, «Pushing SDN to the End-Host, Network Load Balancing using OpenFlow,» 2016 IEEE International Conference on Pervasive Computing and Communication Workshops (PerCom Workshops), Sydney, Australia, vol. 13, nr. doi: /PERCOMW , pp. 1-6, Hewlett Packard Enterprise Development LP, «Fixed Port L3 Managed Ethernet Switches - HP 3800 Switch Series,» HP, [Internett. Available: [Funnet 25 April D. Bombal, «OpenFlow pipelines on physical switches explained,» Pakiti, [Internett. Available: [Funnet 27 April Hewlett Packard Enterprise Development LP, «Fixed Port L3 Managed Ethernet Switches - HP 5500 EI Switch Series,» HP, [Internett. Available: [Funnet 25 April S. Lowe, «Some Insight into Open vswitch Configuration,» 4 Oktober [Internett. Available: [Funnet April Oracle, «VirtualBox,» [Internett. Available: [Funnet 19 April Rev: v (68)

56 [49 [50 [51 [52 [53 [54 [55 [56 [57 [58 [59 [60 [61 [62 [63 Microsoft, «Using Microsoft Loopback Adapter,» [Internett. Available: [Funnet 27 April Mininet Team, «Mininet,» [Internett. Available: [Funnet 04 Mai «Mininet VM Images,» Mininet Team, 22 Januar [Internett. Available: [Funnet 04 Mai Mininet Team, «Mininet Sample Workflow,» [Internett. Available: [Funnet 4 Mai B. Lantz, «Mini Edit App,» Mininet Team, 28 August [Internett. Available: [Funnet 4 Mai EstiNet Technologies Inc., «Estinet,» [Internett. Available: [Funnet 04 Mai S.-Y. Wang, «Comparison of SDN OpenFlow Network Simulator and Emulators: EstiNet vs. Mininet,» 2014 IEEE Symposium on Computers and Communications (ISCC), nr. doi: /ISCC , pp. 1-6, Wireshark Foundation, «Wireshark - Go Deep,» Wireshark Foundation, [Internett. Available: [Funnet 4 Mai J. Morriss, «OpenFlow - The Wireshark Wiki,» Wireshark, 26 Februar [Internett. Available: [Funnet 4 Mai SDxCentral, «SDN Controllers Report,» SDxCentral, Sunnyvale, The Linux Foundation, «Collaborative Projects,» [Internett. Available: [Funnet 9 Mai SDxCentral, «What is the OpenDaylight Project (ODL)?,» [Internett. Available: [Funnet 9 Mai O. Project, «OpenDaylight Features List,» Linux Foundation, [Internett. Available: [Funnet 9 Mai Linux Foundation, «ODL Beryllium (Be) - The Fourth Release of OpenDaylight,» Linux Foundation, [Internett. Available: [Funnet 4 Mai «Floodlight Is an Open SDN Controller,» Project Floodlight, [Internett. Available: [Funnet 4 Mai Rev: v (68)

57 [64 [65 [66 [67 [68 [69 [70 [71 [72 [73 [74 [75 [76 Floodlight, «Floodlight v1.2,» 7 Februar [Internett. Available: [Funnet 9 Mai R. Izard, «Floodlight VM,» Project Floodlight, 26 April [Internett. Available: [Funnet 9 Mai Masa, «HP OpenFlow capable firmware is now GA,» OpenFlow Blog, 7 Desember [Internett. Available: [Funnet 19 Mai HP Development Company, L.P., «HP VAN SDN Controller,» HP Development Company, L.P., [Internett. Available: [Funnet 4 Mai HPED LP, «SDN APP Store,» Hewlett Packard Enterprise, [Internett. Available: [Funnet 4 Mai Ryu SDN Framework Community, «RYU SDN Framework,» Ryu SDN Framework Community, [Internett. Available: [Funnet 4 Mai Ryu, «Resources,» [Internett. Available: [Funnet 9 Mai RYU Project Team, RYU SDN Framework, Using OpenFlow 1.3, Amazon Digital Services LLC, D. Mahler, «OpenFlow flow entries on Open vswitch (OVS),» YouTube, 17 Februar [Internett. Available: [Funnet 19 Mai A. Cherenson, «IEEE 802 Numbers,» IANA, 6 Oktober [Internett. Available: [Funnet 19 Mai a3alex, techtonik og vapier, «NetCat: The TCP/IP Swiss Army,» sourceforge, 16 September [Internett. Available: [Funnet 13 Mai RYU project team, «Ryu 1.0 Documentation: Spanning Tree,» Ryu, [Internett. Available: [Funnet 27 April Ryu, «simple_switch_stp_13.py,» 18 Februar [Internett. Available: [Funnet 4 Mai Rev: v (68)

58 [77 [78 [79 [80 [81 [82 [83 [84 [85 [86 [87 [88 [89 Ashirkar, «Understanding Basics of Multicast RPF (Reverse Path Forwarding),» Cisco, 8 Januar [Internett. Available: [Funnet 19 Mai Open Networking Foundation, «The Benefits of Multiple Flow Tables and TTP,» ONF TR-510, R. Izard, «Floodlight VM,» Atlassian, 26 April [Internett. Available: [Funnet 9 Mai Floodlight, «Floodlight Documentation,» Atlassian, [Internett. Available: [Funnet 20 April F. Dürr, «OpenDaylight: Programming Flows with the REST Interface and curl,» Networked and Mobile Systems Blog, CURL, «curl and libcurl,» 18 Mai [Internett. Available: [Funnet 19 Mai D. Kreutz, F. M. V. Ramos, P. Verissimo, C. E. Rothenberg, S. Azodolmolky og S. Uhlig, «Software-Defined Networking: A Comprehensive Survey, vol. 103,» Proceedings of the IEEE, vol. 1, nr. doi: /JPROC , pp , E. Banks, «Show 231 OpenFlow s Possible Futures with Curt Beckmann,» PacketPushers, 3 April [Internett. Available: openflows-possible-futures-with-curt-beckmann/. [Funnet 27 Mars A. Gelberger, N. Yemini og R. Giladi, «Performance Analysis of Software-Defined Networking (SDN),» 2013 IEEE 21st International Symposium on Modelling, Analysis and Simulation of Computer and Telecommunication Systems, San Francisco, CA, vol. 21, nr. doi: /MASCOTS , pp , F. Dürr, «Developing OSGi Components for OpenDaylight,» 18 Januar [Internett. Available: [Funnet 02 Mai OpenDaylight, «OpenDaylight User Guide,» [Internett. Available: [Funnet 02 Mai S. Scott-Hayward, S. Natarajan og S. Sezer, «A Survey of Security in Software Defined Networks,» IEEE COMMUNICATION SURVEYS & TUTORIALS, vol. 18, nr. 1, pp , R. Smeliansky, «SDN for network security,» Science and Technology Conference (Modern Networking Technologies) (MoNeTeC), nr. doi: /MoNeTeC , pp. 1-5, Rev: v (68)

59 [90 [91 [92 [93 [94 Open Networking Foundation, «ONF Blog: Four Steps to SDN,» 21 Oktober [Internett. Available: [Funnet 21 Mai Open Networking Foundation, «Migration Use Cases and Methods,» [Internett. Available: [Funnet 21 Mai D. Bombal, «GNS3 Academy: Practical SDN and OpenFlow Fundamentals,» GNS3 Academy, 12 Oktober [Internett. Available: [Funnet 30 Mai B. Koley, «Software Defined Networking at Scale,» [Internett. Available: f. [Funnet 23 April EstiNet, «EstiNet:OpenFlow add-on,» [Internett. Available: [Funnet 30 Mai Rev: v (68)

60 Appendiks B Forkortelser og ordforklaringer ACL API ARP BGP BPDU DHCP DoS DPI DPID GUI ICMP IETF IDS IoT IP JSON LAN MAC NAT NETCONF NFV NOS ODL OF-CONFIG ONF OSGi OSI OVS OVSDB QoS REST RPF SDN SFC SNMP SPF SSH STP TCP TFTP TLS TTL UDP URL VLAN VM WAN XML Access Control List Application Program Interface Address Resolution Protocol Border Gateway Protocol Bridge Protocol Data Unit Dynamic Host Configuration Protocol Denial of Service Deep Packet Inspection Datapath identifier Graphical User Interface Internet Control Message Protocol Internet Engineering Task Force Intrusion Detection System Internet of Things Internet Protocol JavaScript Object Notation Local Area Network Media Access Control Address Network Address Translation Network Configuration Protocol Network Function Virtualization Network Operating System OpenDaylight OpenFlow Management and Configuration Protocol Open Networking Foundation Open Service Gateway Initiative Open Systems Interconnection model Open vswitch Open vswitch Database Management Protocol Quality of Service Representational State Transfer Reverse Path Forwarding Software-Defined Networking Service Function Chaining Simple Network Management Protocol Shortest Path First Secure Shell Spanning Tree Protocol Transmission Control Protocol Trivial File Transfer Protocol Transport Layer Security Time to Live User Datagram Protocol Uniform Resource Locator Virtual LAN (Local Area Network) Virtual Machine Wide Area Network Extensible Markup Language Rev: v (68)

61 Appendiks C Prosjektledelse og styring C.1 Prosjektorganisasjon Oppgaven er gjort av en person, og det har ikke vært behov for å organisere arbeidsoppgaver. C.2 Fremdriftsplan C.3 Risikoliste Risiko Utfall Tiltak Har ikke konkret problemstilling fra start Kan ta tid å spesifisere arbeidsoppgaver Bruke tid på research, lære mer om temaet Problemer med installasjon av Får ikke prøvd programvare som er Finne gode alternativer programvare relevant for oppgaven Sykdom Mister tid til å jobbe med oppgaven Jobbe fra bærbar maskin, kunne jobbe hjemmefra Jobber alene Ingen å diskutere med Finne hjelp hos veileder og medstudenter Appendiks D Figurliste Figur 1: Oversikt over lagstruktur og typiske koblinger... 4 Figur 2: SDN-kontrollers interface... 9 Figur 3: Tradisjonell switching Figur 4: SDN Switching Figur 5: Ulik trafikk må innom ulike nettverkstjenester Figur 6: STP konfigurasjonsflagg i OpenFlow Figur 7: Konfigurasjon av OpenFlow på fysisk HP switch Figur 8: VirtualBox med ulike virtuelle maskiner som er blitt brukt Figur 9: Virtuelt nettverkskort Figur 10: Enkel DHCP-server Figur 11: Mininet kommando for oppretting av emulert nettverk Rev: v (68)