Software-Defined Networking - HVLhome.hvl.no/ai/elektro/2016/BO16E-45.pdf · Software-Defined Networking Rev: v1.00 5(68) 31.05.16 Det blir presentert ulike begreper og teknologier

SOFTWARE-DEFINED NETWORKING

Magne Hjertaker

13HKOM

31. mai 2016

Dokumentkontroll

Rapportens tittel:

Software-Defined Networking Dato/Versjon

31.05.16/v1.00 Rapportnummer:

Forfatter(e):

Magne Hjertaker

Studieretning:

13HKOM Antall sider m/vedlegg

68 Høgskolens veileder:

[email protected] Gradering:

Eventuelle Merknader:

Oppdragsgiver: Høgskolen i Bergen

Oppdragsgivers referanse:

Knut Øvsthus

Oppdragsgivers kontaktperson(er) (inklusiv kontaktinformasjon):

Revisjon Dato Status Utført av

v.0.11 16.01.16 Første utkast Magne Hjertaker

v.0.12 18.01.16 Revidert utkast Magne Hjertaker

v.0.15 07.03.16 Info om LAB-miljø Magne Hjertaker

v.0.16 11.03.16 STP info Magne Hjertaker

v.0.17 19.03.16 OpenFlow generelt Magne Hjertaker

v.0.18 30.03.16 LAB utførelser Magne Hjertaker

v.0.19 02.04.16 Figurer og LAB dokumentasjon Magne Hjertaker

v.0.20 05.04.16 Gjennomgang Magne Hjertaker

v.0.21 13.04.16 Diskusjon Magne Hjertaker

v.0.22 19.04.16 Korrektur Magne Hjertaker

v.0.23 22.04.16 NFV info Magne Hjertaker

v.0.24 25.04.16 Kilder Magne Hjertaker

v.0.25 02.05.16 Reverse path forwarding LAB Magne Hjertaker

v.0.26 04.05.16 REST LAB Magne Hjertaker

v.0.30 09.05.16 Ordne struktur på innhold Magne Hjertaker

v.0.31 10.05.16 Kravspesifikasjon korrektur Magne Hjertaker

v.0.32 11.05.16 Ordne overskrifter og format kildehenvisninger Magne Hjertaker

v.0.33 18.05.16 Endringer i white box kapittel, innledning Magne Hjertaker

v.0.34 21.05.16 Diskusjon: overgang Magne Hjertaker

v.0.40 23.05.16 Korrektur Magne Hjertaker

v.0.50 26.05.16 Sammendrag Magne Hjertaker

v.0.90 30.05.16 Gjennomgang, finskriving Magne Hjertaker

v.1.00 31.05.16 Klargjøring innlevering Magne Hjertaker

Software-Defined Networking

Rev: v1.00 3(68) 31.05.16

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 4(68) 31.05.16

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 5(68) 31.05.16

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 6(68) 31.05.16

1 Innhold Dokumentkontroll ................................................................................................................................... 2

Forord ...................................................................................................................................................... 3

Sammendrag ........................................................................................................................................... 4

1 Innledning ........................................................................................................................................ 9

1.1 Organisering av rapporten .................................................................................................... 10

1.2 Oppdragsgiver ....................................................................................................................... 10

1.3 Problemstilling ....................................................................................................................... 10

2 Gjennomføring av oppgaven ......................................................................................................... 10

3 Bakgrunnsteori .............................................................................................................................. 11

3.1 Forskjellen på tradisjonell switching og SDN switching ........................................................ 11

3.1.1 Tradisjonell switching ................................................................................................ 11

3.1.2 SDN switching ............................................................................................................ 12

3.2 Proactive eller Reactive ......................................................................................................... 12

3.3 NETCONF og OF-CONFIG ....................................................................................................... 13

3.4 Open vSwitch ......................................................................................................................... 13

3.5 Nettverksoperativsystem ...................................................................................................... 14

3.6 Network Function Virtualization (NFV) ................................................................................. 14

3.7 Service Chaining .................................................................................................................... 15

4 Teori. Software-Defined Networking - OpenFlow ......................................................................... 15

4.1 OpenFlow versjoner .............................................................................................................. 15

4.2 Grunnleggende OpenFlow funksjonalitet ............................................................................. 16

4.2.1 OpenFlow porter ....................................................................................................... 16

4.2.2 OpenFlow tabeller ..................................................................................................... 17

4.2.3 Matching og actions .................................................................................................. 17

4.2.4 Kommunikasjon ......................................................................................................... 17

4.3 Spanning-Tree og OpenFlow ................................................................................................. 18

4.3.1 Spanning-Tree utfordringer i hybride nettverk ......................................................... 19

4.4 Lastbalansering og portaggregering i OpenFlow ................................................................... 19

4.5 VLAN og trafikkseparering i OpenFlow og Open vSwitch ..................................................... 20

4.5.1 Kontrollere og behandling av trafikk fra ulike VLAN ................................................. 20

4.5.2 Fysiske OpenFlow switcher og VLAN ......................................................................... 20

4.5.3 Virtuelle switcher og VLAN ........................................................................................ 20

5 Realisering av valgt løsning ........................................................................................................... 21


Rev: v1.00 7(68) 31.05.16

5.1 Testmiljø ................................................................................................................................ 21

5.2 Testet programvare ............................................................................................................... 23

5.2.1 Mininet ...................................................................................................................... 23

5.2.2 EstiNet ....................................................................................................................... 25

5.2.3 Wireshark .................................................................................................................. 26

5.3 SDN kontrollere ..................................................................................................................... 26

5.3.1 OpenDaylight ............................................................................................................. 26

5.3.2 Floodlight ................................................................................................................... 27

5.3.3 HP VAN SDN Controller ............................................................................................. 28

5.3.4 Ryu ............................................................................................................................. 28

5.4 Vurderinger av programvare og kontrollere ......................................................................... 29

6 Testing ........................................................................................................................................... 30

6.1 Trafikkstyring på ulike lag ...................................................................................................... 30

6.1.1 Lag 1 ........................................................................................................................... 31

6.1.2 Lag 2 ........................................................................................................................... 32

6.1.3 Lag 3 ........................................................................................................................... 33

6.1.4 Lag 4 ........................................................................................................................... 33

6.2 Pakkemodifikasjoner ............................................................................................................. 35

6.3 VLANs ..................................................................................................................................... 37

6.4 Eksempel på bruk av STP i OpenFlow fra Ryu ....................................................................... 40

6.5 Flere tabeller og prioritet ...................................................................................................... 41

6.6 Nordgående interface, RESTful API ....................................................................................... 42

6.7 Observasjoner gjort fra testene ............................................................................................ 47

7 Vurdering. SDN i dag ..................................................................................................................... 48

7.1 Applikasjoner ......................................................................................................................... 48

7.2 Sikkerhet ................................................................................................................................ 49

7.3 Overgang til SDN .................................................................................................................... 50

8 Konklusjon ..................................................................................................................................... 51

Appendiks A Litteraturliste ............................................................................................................. 52

Appendiks B Forkortelser og ordforklaringer ................................................................................. 60

Appendiks C Prosjektledelse og styring .......................................................................................... 61

C.1 Prosjektorganisasjon ............................................................................................................. 61

C.2 Fremdriftsplan ....................................................................................................................... 61

C.3 Risikoliste ............................................................................................................................... 61


Rev: v1.00 8(68) 31.05.16

Appendiks D Figurliste .................................................................................................................... 61

Appendiks E RYU STP utskrift ......................................................................................................... 62

Appendiks F LAB-utskrifter ............................................................................................................. 65


Rev: v1.00 9(68) 31.05.16

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 analysering1.

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 10(68) 31.05.16

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: v1.00 11(68) 31.05.16

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.

3.1.1 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 enhet2. 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: v1.00 12(68) 31.05.16

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: v1.00 13(68) 31.05.16

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 tabell3, 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 [12].

3.4 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 konfigurasjonen4. Nettverkssimulatoren Mininet som presenteres i 5.2.1 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: v1.00 14(68) 31.05.16

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 [16].

3.5 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 [24].

3.6 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 NFV-

lø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: v1.00 15(68) 31.05.16

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

[9].

4.1 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: v1.00 16(68) 31.05.16

Den første versjonen etter betalanseringer, altså versjon 1.0, ble lansert 31 desember 2009. 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.

4.2.1 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: v1.00 17(68) 31.05.16

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.

4.2.2 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 65535 (16-bits). Dersom prioritet ikke

blir angitt får linjen en standard prioritet på 32768. 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).

4.2.3 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).

4.2.4 Kommunikasjon

Kommunikasjon mellom kontroller og switch foregår på et ikke-OpenFlow interface og over en TCP

tilkobling som standard via port 6633. 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: v1.00 18(68) 31.05.16

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

modus. 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: v1.00 19(68) 31.05.16

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

4.3.1 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å looping-

muligheter. 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: v1.00 20(68) 31.05.16

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.

4.5.1 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.

4.5.2 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 192.168.50.70 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.

4.5.3 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: v1.00 21(68) 31.05.16

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: v1.00 22(68) 31.05.16

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

maskinene5. 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: v1.00 23(68) 31.05.16

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.

5.2.1 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: v1.00 24(68) 31.05.16

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=192.168.50.11 --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 192.168.50.11.

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

program 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: v1.00 25(68) 31.05.16

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 brukergrensesnitt6

6 På grunn av utløpt prøveperiode, er bildet hentet fra EstiNets hjemmeside [92].


Rev: v1.00 26(68) 31.05.16

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 1.3

5.3 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.

5.3.1 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 SDN-

teknologi [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: v1.00 27(68) 31.05.16

Figur 15: OpenDaylight brukergrensesnitt

5.3.2 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: v1.00 28(68) 31.05.16

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

5.3.4 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: v1.00 29(68) 31.05.16

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: v1.00 30(68) 31.05.16

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 4.2.3 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:00..02 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: v1.00 31(68) 31.05.16

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

6.1.1 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: v1.00 32(68) 31.05.16

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 6.1.1 har host 1 og host 2 mulighet å kommunisere, mens resten av

nettverket ikke får kontakt med hverandre.


Rev: v1.00 33(68) 31.05.16

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=10.0.0.1,actions=output:1 mininet> sh ovs-ofctl add-flow s1 arp,nw_dst=10.0.0.2,actions=output:2 mininet> sh ovs-ofctl add-flow s1 ip,nw_src=10.0.0.1,nw_dst=10.0.0.2,actions=output:2 mininet> sh ovs-ofctl add-flow s1 ip,nw_src=10.0.0.2,nw_dst=10.0.0.1,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=103.852s, table=0, n_packets=2, n_bytes=196, idle_age=77, ip,nw_src=10.0.0.1,nw_dst=10.0.0.2 actions=output:2 cookie=0x0, duration=103.041s, table=0, n_packets=2, n_bytes=196, idle_age=77, ip,nw_src=10.0.0.2,nw_dst=10.0.0.1 actions=output:1 cookie=0x0, duration=103.863s, table=0, n_packets=8, n_bytes=336, idle_age=36, arp,arp_tpa=10.0.0.2 actions=output:2 cookie=0x0, duration=103.873s, table=0, n_packets=8, n_bytes=336, idle_age=39, arp,arp_tpa=10.0.0.1 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.

6.1.4 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: v1.00 34(68) 31.05.16

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=10.0.0.2,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=333.038s, table=0, n_packets=10, n_bytes=760, idle_age=157, ip,nw_src=10.0.0.2 actions=NORMAL cookie=0x0, duration=333.729s, 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 10.0.0.2 80 Test TCP fra H1 til H2

root@mininet-vm:~# # HOST 3 root@mininet-vm:~# nc 10.0.0.2 80 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: v1.00 35(68) 31.05.16

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 30.0.0.3, selv om maskinen

egentlig har IP-adresse 20.0.0.2. 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

20.0.0.2. Til slutt får switchen 2 enkle oppføringer som modifiserer avsender og destinasjonsadresse,

og sender pakkene ut riktig port. Avsender endres til 30.0.0.3 når host 2 kommuniserer, og mottaker

endres til 20.0.0.2 når host 1 kommuniserer.

mininet> h1 route add default gw 10.0.0.254 h1-eth0 mininet> h1 arp -s 10.0.0.254 11:11:11:11:11:11 mininet> mininet> h2 ifconfig h2-eth0 20.0.0.2 netmask 255.255.255.0 mininet> h2 route add default gw 20.0.0.254 h2-eth0 mininet> h2 arp -s 20.0.0.254 22:22:22:22:22:22 mininet> mininet> sh ovs-ofctl add-flow s1 ip,nw_dst=10.0.0.1,actions=mod_nw_src:30.0.0.3,mod_dl_dst:00:00:00:00:00:01,output:1 mininet> sh ovs-ofctl add-flow s1 ip,nw_dst=30.0.0.3,actions=mod_nw_dst:20.0.0.2,mod_dl_dst:00:00:00:00:00:02,output:2

Figur 27: Kommandoutskrift: Statisk ARP og IP gateway


Rev: v1.00 36(68) 31.05.16

Utskriften i Figur 28 viser at ping gjennomføres uten problemer, og hostene kan kommunisere.

mininet> h1 ping 30.0.0.3 PING 30.0.0.3 (30.0.0.3) 56(84) bytes of data. 64 bytes from 30.0.0.3: icmp_seq=1 ttl=64 time=0.304 ms 64 bytes from 30.0.0.3: icmp_seq=2 ttl=64 time=0.129 ms 64 bytes from 30.0.0.3: icmp_seq=3 ttl=64 time=0.149 ms 64 bytes from 30.0.0.3: icmp_seq=4 ttl=64 time=0.105 ms --- 30.0.0.3 ping statistics --- 4 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 10.0.0.1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.242 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.096 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.098 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.102 ms --- 10.0.0.1 ping statistics --- 4 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: v1.00 37(68) 31.05.16

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: v1.00 38(68) 31.05.16

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: v1.00 39(68) 31.05.16

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=10.0.0.1,nw_dst=10.0.0.3,actions=mod_vlan_vid:20,output:2 sh ovs-ofctl add-flow s1 arp,nw_src=10.0.0.1,nw_dst=10.0.0.3,actions=mod_vlan_vid:20,output:2 sh ovs-ofctl add-flow s1 ip,nw_src=10.0.0.1,nw_dst=10.0.0.4,actions=mod_vlan_vid:20,output:4 sh ovs-ofctl add-flow s1 arp,nw_src=10.0.0.1,nw_dst=10.0.0.4,actions=mod_vlan_vid:20,output:4 sh ovs-ofctl add-flow s1 ip,nw_src=10.0.0.3,nw_dst=10.0.0.1,actions=mod_vlan_vid:10,output:1 sh ovs-ofctl add-flow s1 arp,nw_src=10.0.0.3,nw_dst=10.0.0.1,actions=mod_vlan_vid:10,output:1 sh ovs-ofctl add-flow s1 ip,nw_src=10.0.0.3,nw_dst=10.0.0.2,actions=mod_vlan_vid:10,output:4 sh ovs-ofctl add-flow s1 arp,nw_src=10.0.0.3,nw_dst=10.0.0.2,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=10.0.0.2,nw_dst=10.0.0.4,actions=mod_vlan_vid:20,output:2 sh ovs-ofctl add-flow s2 arp,nw_src=10.0.0.2,nw_dst=10.0.0.4,actions=mod_vlan_vid:20,output:2 sh ovs-ofctl add-flow s2 ip,nw_src=10.0.0.2,nw_dst=10.0.0.3,actions=mod_vlan_vid:20,output:4 sh ovs-ofctl add-flow s2 arp,nw_src=10.0.0.2,nw_dst=10.0.0.3,actions=mod_vlan_vid:20,output:4 sh ovs-ofctl add-flow s2 ip,nw_src=10.0.0.4,nw_dst=10.0.0.2,actions=mod_vlan_vid:10,output:1 sh ovs-ofctl add-flow s2 arp,nw_src=10.0.0.4,nw_dst=10.0.0.2,actions=mod_vlan_vid:10,output:1 sh ovs-ofctl add-flow s2 ip,nw_src=10.0.0.4,nw_dst=10.0.0.1,actions=mod_vlan_vid:10,output:4 sh ovs-ofctl add-flow s2 arp,nw_src=10.0.0.4,nw_dst=10.0.0.1,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: v1.00 40(68) 31.05.16

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) 00…1. 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: v1.00 41(68) 31.05.16

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 10.0.0.1 Send til tabell 2 Avsender 10.0.0.2 og inport 2? Lever til H1

Alle andre pakker FLOOD (har lavere prioritet)

Avsender 10.0.0.3 og inport 3? Lever til H1

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 32768. 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: v1.00 42(68) 31.05.16

# S1 table=0,ip,nw_dst=10.0.0.1,actions=resubmit(,1) table=0,arp,nw_dst=10.0.0.1,actions=resubmit(,1) table=0,priority=0,actions=flood

table=1,ip,nw_src=10.0.0.2,in_port=2,actions=output:1 table=1,arp,nw_src=10.0.0.2,in_port=2,actions=output:1 table=1,ip,nw_src=10.0.0.3,in_port=3,actions=output:1 table=1,arp,nw_src=10.0.0.3,in_port=3,actions=output:1





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 N2 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=127.0.0.1,port=6653 --

mac. Kommandoen spesifiseres at python-koden skal brukes til topologi, og at kontrolleren befinner

seg lokalt på port 6653.


Rev: v1.00 43(68) 31.05.16

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 http://127.0.0.1:8080/wm/core/controller/switches/json | python -m json.tool

leverer tilbake infoen om switchene i Figur 41.


Rev: v1.00 44(68) 31.05.16

floodlight@floodlight:~/floodlight$ curl http://127.0.0.1:8080/wm/core/controller/switches/json | python -m json.tool % Total % Received % Xferd Average Dload Speed Upload Time Total Time Spent Time Left Current Speed 100 421 0 421 0 0 66184 0 --:--:-- --:--:-- --:--:-- 84200 [ { "connectedSince": 1461153184215, "inetAddress": "/127.0.0.1:45948", "switchDPID": "00:00:00:00:00:00:00:01" }, { "connectedSince": 1461153176057, "inetAddress": "/127.0.0.1:45950", "switchDPID": "00:00:00:00:00:00:00:02" }, { "connectedSince": 1461153176062, "inetAddress": "/127.0.0.1:45949", "switchDPID": "00:00:00:00:00:00:00:03" }, { "connectedSince": 1461153175166, "inetAddress": "/127.0.0.1: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: v1.00 45(68) 31.05.16

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"}' http://127.0.0.1:8080/wm/staticflowpusher/json






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: v1.00 46(68) 31.05.16

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 http://127.0.0.1:8080/wm/staticflowpusher/list/00:00:00:00:00:00:00:01/json | python -m json.tool { "00:00:00:00:00:00:00:01": [ { "flow-mod-1": { "command": "ADD", "cookie": "45035997351236006", "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": "45035997351236011", "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: v1.00 47(68) 31.05.16

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=0xa000004039d1a6, duration=1041.740s, table=0, n_packets=1551, n_bytes=151886, idle_age=0, priority=100,in_port=1 actions=output:2 cookie=0xa000004039d1ab, duration=1040.786s, table=0, n_packets=2568, n_bytes=311827, idle_age=0, priority=100,in_port=3 actions=output:1 cookie=0x0, duration=1429.172s, 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=0xa000004039d1a7, duration=1043.050s, table=0, n_packets=2062, n_bytes=231986, idle_age=0, priority=100,in_port=1 actions=output:2 cookie=0x0, duration=1432.033s, 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=0xa000004039d1aa, duration=1044.011s, table=0, n_packets=2043, n_bytes=229358, idle_age=0, priority=100,in_port=2 actions=output:1 cookie=0x0, duration=1433.034s, 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=0xa000004039d1a8, duration=1045.752s, table=0, n_packets=2574, n_bytes=312579, idle_age=0, priority=100,in_port=1 actions=output:3 cookie=0xa000004039d1a9, duration=1045.739s, table=0, n_packets=1559, n_bytes=152670, idle_age=0, priority=100,in_port=3 actions=output:2 cookie=0x0, duration=1434.735s, 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: v1.00 48(68) 31.05.16

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

teknologien 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: v1.00 49(68) 31.05.16

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: v1.00 50(68) 31.05.16

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: v1.00 51(68) 31.05.16

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: v1.00 52(68) 31.05.16

Appendiks A Litteraturliste

[1] Open Networking Foundation, «Software-Defined Networking (SDN) Definition,» 2016.

[Internett]. Available: https://www.opennetworking.org/sdn-resources/sdn-definition. [Funnet

22 Januar 2016].

[2] Open Networking Foundation, «OpenFlow,» Open Networking Foundation, 2016. [Internett].

Available: https://www.opennetworking.org/sdn-resources/openflow. [Funnet 13 Mai 2016].

[3] D. Pitt, «The Secret of the 5G Bandwagon: SDN Is the Engine,» Light Reading, 4 April 2016.

[Internett]. Available: http://www.lightreading.com/mobile/5g/the-secret-of-the-5g-

bandwagon-sdn-is-the-engine/a/d-id/722362. [Funnet 18 Mai 2016].

[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=http://dx.doi.org/10.1145/2486001.2486019, pp. 3-14, 2013.

[5] «OpenFlow @ Google - Urs Hoelzle, Google,» Open Networking Summit, 7 Mai 2012.

[Internett]. Available: https://www.youtube.com/watch?v=VLHJUfgxEO4. [Funnet 25 April

2016].

[6] Y. Bachar og A. Simpkins, «Introducing “Wedge” and “FBOSS,” the next steps toward a

disaggregated network,» Facebook, 18 Juni 2014. [Internett]. Available:

https://code.facebook.com/posts/681382905244727/introducing-wedge-and-fboss-the-next-

steps-toward-a-disaggregated-network/. [Funnet 23 April 2016].

[7] Microsoft Azure, «Software-defined networking solutions,» [Internett]. Available:

https://www.microsoft.com/en/server-cloud/solutions/software-defined-networking.aspx.

[Funnet 23 April 2016].

[8] The Cisco Learning Network, «CCNA Routing and Switching Certification,» Mai 2016. [Internett].

Available: https://learningnetwork.cisco.com/community/ccna-rs-certification. [Funnet 30 Mai

2016].

[9] R. Enns, M. Bjorklund, J. Schoenwaelder og A. Bierman, «RFC 6241 - Network Configuration

Protocol (NETCONF),» IETF, 2011.

[10

]

J. Case, M. Fedor, M. Schoffstall og J. Davin, «RFC 1157 - A Simple Network Management

Protocol (SNMP),» IETF, 1990.

[11

]

Open Networking Foundation, «OpenFlow® Configuration and Management Protocol 1.0,»

2011. [Internett]. Available: https://www.opennetworking.org/images/stories/downloads/sdn-

resources/onf-specifications/openflow-config/of-config1dot0-final.pdf. [Funnet 20 Mai 2016].


Rev: v1.00 53(68) 31.05.16

[12

]

Open Networking Foundation, «ONF TS-016 : OpenFlow Management and Configuration

Protocol 1.2,» 2014. [Internett]. Available:

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-

specifications/openflow-config/of-config-1.2.pdf. [Funnet 20 Mai 2016].

[13

]

«Open vSwitch,» [Internett]. Available: http://openvswitch.org/. [Funnet 25 April 2016].

[14

]

D. Bombal, «GNS3 Academy: Practical SDN and OpenFlow Fundamentals - Raspberry pi Part 1,»

GNS3, 12 Oktober 2015. [Internett]. Available: http://academy.gns3.com/courses/a-practical-

sdn-and-openflow-introduction/lectures/672223. [Funnet 23 Mai 2016].

[15

]

Raspberry Pi Foundation, «Teach, learn and make with Raspberry Pi,» 2016. [Internett].

Available: https://www.raspberrypi.org/. [Funnet 23 Mai 2016].

[16

]

B. Pfaff og E. B. Davie, «RFC 7047 - The Open vSwitch Database Management Protocol,» IETF,

2013.

[17

]

Cumulus Networks, «Cumulis Linux,» [Internett]. Available:

https://cumulusnetworks.com/cumulus-linux/overview/. [Funnet 25 April 2016].

[18

]

Pica8 Inc., «Pica8,» [Internett]. Available: http://www.pica8.com/. [Funnet 25 April 2016].

[19

]

PacketPushers, «List Of Network Operating Systems,» PacketPushers, 2016. [Internett].

Available: https://packetpushers.net/virtual-toolbox/list-network-operating-systems/. [Funnet

27 April 2016].

[20

]

Y. Bachar, «Introducing “6-pack”: the first open hardware modular switch,» Facebook, 11

Februar 2015. [Internett]. Available:

https://code.facebook.com/posts/717010588413497/introducing-6-pack-the-first-open-

hardware-modular-switch/. [Funnet 18 Mai 2016].

[21

]

C. Matsumoto, «HP Launches OpenSwitch, Yet Another Open Network OS,» SDxCentral, 5

October 2015. [Internett]. Available: https://www.sdxcentral.com/articles/news/hp-launches-

openswitch-yet-another-open-network-os/2015/10/. [Funnet 18 Mai 2016].

[22

]

HPE LP, «OpenSwitch,» 2015. [Internett]. Available: http://www.openswitch.net/. [Funnet 18

Mai 2016].

[23

]

Hewlett Packard Enterprise Development LP, «Fixed Port L3 Managed Ethernet Switches - HPE

Altoline 6920 Switch Series,» 2016. [Internett]. Available:

http://www8.hp.com/us/en/products/networking-switches/product-detail.html?oid=8370373.

[Funnet 18 Mai 2016].


Rev: v1.00 54(68) 31.05.16

[24

]

J. Duffy, «HP serves up its open switches,» Network World, 24 August 2015. [Internett].

Available: http://www.networkworld.com/article/2974782/data-center/hp-serves-up-its-open-

switches.html. [Funnet 18 Mai 2016].

[25

]

SDxCentral, «2016 Mega NFV Report Pt. 1: MANO and NFVI,» SDxCentral, 2016.

[26

]

SDxCentral, «Which is Better – SDN or NFV?,» 2016. [Internett]. Available:

https://www.sdxcentral.com/nfv/resources/which-is-better-sdn-or-nfv/. [Funnet 22 April

2016].

[27

]

R. White, «What Is Service Chaining?,» PacketPushers, 9 August 2014. [Internett]. Available:

http://packetpushers.net/service-chaining/. [Funnet 24 Mai 2016].

[28

]

J. Guichard, «RFC 7665 - Service Function Chaining (SFC) Architecture,» IETF, 28 Mars 2015.

[Internett]. Available: https://datatracker.ietf.org/doc/rfc7665/?include_text=1. [Funnet 24

Mai 2016].

[29

]

M. Casado, «The Virtual Network System,» Stanford University, Stanford, 2005.

[30

]

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. 69-74, 2008.

[31

]

Open Networking Foundation, «Board of Directors,» 2016. [Internett]. Available:

https://www.opennetworking.org/about/board-of-directors. [Funnet 20 Mai 2016].

[32

]

Cisco, «OpFlex: An Open Policy Protocol White Paper,» Cisco, 17 Oktober 2014. [Internett].

Available: https://www.cisco.com/c/en/us/solutions/collateral/data-center-

virtualization/application-centric-infrastructure/white-paper-c11-731302.html. [Funnet 30 Mai

2016].

[33

]

P. Lapukhov og E. Nkposong, «Centralized Routing Control in BGP Networks Using Link-State

Abstraction,» Network Working Group, 2 September 2013. [Internett]. Available:

https://tools.ietf.org/html/draft-lapukhov-bgp-sdn-00. [Funnet 30 Mai 2016].

[34

]

Open Network Foundation, «OpenFlow Switch Specification, Version 1.5.0 (Protocol version

0x06),» Open Network Foundation, 2014.

[35

]

Open Networking Foundation, «OpenFlow Switch Specification, Version 1.0.0 (Wire Protocol

0x01),» Open Networking Foundation, 2009.

[36

]

Open Networking Foundation, «OpenFlow Switch Specification, Version 1.3.0 (Wire Protocol

0x04),» ONF TS-006, 2012.


Rev: v1.00 55(68) 31.05.16

[37

]

Wikipedia, «OSI model,» 8 Mai 2016. [Internett]. Available:

https://en.wikipedia.org/wiki/OSI_model. [Funnet 10 Mai 2016].

[38

]

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: 10.1109/ISCC.2015.7405564, pp. 502-507, 2015.

[39

]

IEEE Corporate, «IEEE P802.3ad Link Aggregation Task Force,» 16 November 2001. [Internett].

Available: http://grouper.ieee.org/groups/802/3/ad/index.html. [Funnet 10 Mai 2016].

[40

]

N. Finn, «Port Aggregation Protocol,» IEEE, Cisco Systems, 1998.

[41

]

Ryu, «simple_switch_lacp_13.py,» 18 Februar 2014. [Internett]. Available:

https://github.com/osrg/ryu-book/blob/master/en/source/sources/simple_switch_lacp_13.py.


[42

]

RYU project team, «Ryu 1.0 Documentation: Link Aggregation,» Ryu, 2014. [Internett].

Available: https://osrg.github.io/ryu-book/en/html/link_aggregation.html. [Funnet 27 April

2016].

[43

]

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:

10.1109/PERCOMW.2016.7457129, pp. 1-6, 2016.

[44

]

Hewlett Packard Enterprise Development LP, «Fixed Port L3 Managed Ethernet Switches - HP

3800 Switch Series,» HP, [Internett]. Available:



[45

]

D. Bombal, «OpenFlow pipelines on physical switches explained,» Pakiti, [Internett]. Available:

http://pakiti.com/openflow-pipelines-physical-switches-explained-1-0-1-3-hp-procurve-

comware-switches-hp-van-sdn-controller/. [Funnet 27 April 2016].

[46

]

Hewlett Packard Enterprise Development LP, «Fixed Port L3 Managed Ethernet Switches - HP

5500 EI Switch Series,» HP, 2016. [Internett]. Available:



[47

]

S. Lowe, «Some Insight into Open vSwitch Configuration,» 4 Oktober 2012. [Internett].

Available: http://blog.scottlowe.org/2012/10/04/some-insight-into-open-vswitch-

configuration/. [Funnet April 27 2016].

[48

]

Oracle, «VirtualBox,» [Internett]. Available: https://www.virtualbox.org/. [Funnet 19 April

2016].


Rev: v1.00 56(68) 31.05.16

[49

]

Microsoft, «Using Microsoft Loopback Adapter,» 2016. [Internett]. Available:

https://technet.microsoft.com/en-us/library/cc708341(v=ws.10).aspx. [Funnet 27 April 2016].

[50

]

Mininet Team, «Mininet,» 2016. [Internett]. Available: http://mininet.org/. [Funnet 04 Mai

2016].

[51

]

«Mininet VM Images,» Mininet Team, 22 Januar 2016. [Internett]. Available:

https://github.com/mininet/mininet/wiki/Mininet-VM-Images. [Funnet 04 Mai 2016].

[52

]

Mininet Team, «Mininet Sample Workflow,» 2016. [Internett]. Available:

http://mininet.org/sample-workflow/. [Funnet 4 Mai 2016].

[53

]

B. Lantz, «Mini Edit App,» Mininet Team, 28 August 2012. [Internett]. Available:

https://github.com/mininet/mininet/wiki/Mini-Edit-App. [Funnet 4 Mai 2016].

[54

]

EstiNet Technologies Inc., «Estinet,» 2016. [Internett]. Available: http://www.estinet.com/.


[55

]

S.-Y. Wang, «Comparison of SDN OpenFlow Network Simulator and Emulators: EstiNet vs.

Mininet,» 2014 IEEE Symposium on Computers and Communications (ISCC), nr. doi:

10.1109/ISCC.2014.6912609, pp. 1-6, 2014.

[56

]

Wireshark Foundation, «Wireshark - Go Deep,» Wireshark Foundation, 2016. [Internett].

Available: https://www.wireshark.org/. [Funnet 4 Mai 2016].

[57

]

J. Morriss, «OpenFlow - The Wireshark Wiki,» Wireshark, 26 Februar 2016. [Internett].

Available: https://wiki.wireshark.org/OpenFlow. [Funnet 4 Mai 2016].

[58

]

SDxCentral, «SDN Controllers Report,» SDxCentral, Sunnyvale, 2015.

[59

]

The Linux Foundation, «Collaborative Projects,» 2016. [Internett]. Available:

http://collabprojects.linuxfoundation.org/. [Funnet 9 Mai 2016].

[60

]

SDxCentral, «What is the OpenDaylight Project (ODL)?,» 2016. [Internett]. Available:

https://www.sdxcentral.com/resources/sdn/opendaylight-project/. [Funnet 9 Mai 2016].

[61

]

O. Project, «OpenDaylight Features List,» Linux Foundation, 2016. [Internett]. Available:

https://www.opendaylight.org/opendaylight-features-list. [Funnet 9 Mai 2016].

[62

]

Linux Foundation, «ODL Beryllium (Be) - The Fourth Release of OpenDaylight,» Linux

Foundation, 2016. [Internett]. Available: https://www.opendaylight.org/odlbe. [Funnet 4 Mai

2016].

[63

]

«Floodlight Is an Open SDN Controller,» Project Floodlight, 2016. [Internett]. Available:

http://www.projectfloodlight.org/floodlight/. [Funnet 4 Mai 2016].


Rev: v1.00 57(68) 31.05.16

[64

]

Floodlight, «Floodlight v1.2,» 7 Februar 2016. [Internett]. Available:

https://floodlight.atlassian.net/wiki/display/floodlightcontroller/Floodlight+v1.2. [Funnet 9 Mai

2016].

[65

]

R. Izard, «Floodlight VM,» Project Floodlight, 26 April 2016. [Internett]. Available:

https://floodlight.atlassian.net/wiki/display/floodlightcontroller/Floodlight+VM. [Funnet 9 Mai

2016].

[66

]

Masa, «HP OpenFlow capable firmware is now GA,» OpenFlow Blog, 7 Desember 2011.

[Internett]. Available: http://archive.openflow.org/wp/2011/12/hp-openflow-capable-

firmware-is-now-ga/. [Funnet 19 Mai 2016].

[67

]

HP Development Company, L.P., «HP VAN SDN Controller,» HP Development Company, L.P.,

2016. [Internett]. Available: http://www8.hp.com/us/en/products/oas/product-

detail.html?oid=5443917. [Funnet 4 Mai 2016].

[68

]

HPED LP, «SDN APP Store,» Hewlett Packard Enterprise, 2016. [Internett]. Available:

https://saas.hpe.com/marketplace/sdn#/Home/Show. [Funnet 4 Mai 2016].

[69

]

Ryu SDN Framework Community, «RYU SDN Framework,» Ryu SDN Framework Community,

2014. [Internett]. Available: https://osrg.github.io/ryu/. [Funnet 4 Mai 2016].

[70

]

Ryu, «Resources,» 2016. [Internett]. Available: https://osrg.github.io/ryu/resources.html.


[71

]

RYU Project Team, RYU SDN Framework, Using OpenFlow 1.3, Amazon Digital Services LLC,

2014.

[72

]

D. Mahler, «OpenFlow flow entries on Open vSwitch (OVS),» YouTube, 17 Februar 2014.

[Internett]. Available: https://www.youtube.com/watch?v=FyV4MoQ3T0I. [Funnet 19 Mai

2016].

[73

]

A. Cherenson, «IEEE 802 Numbers,» IANA, 6 Oktober 2015. [Internett]. Available:

https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml. [Funnet 19

Mai 2016].

[74

]

a3alex, techtonik og vapier, «NetCat: The TCP/IP Swiss Army,» sourceforge, 16 September

2013. [Internett]. Available: http://nc110.sourceforge.net/. [Funnet 13 Mai 2016].

[75

]

RYU project team, «Ryu 1.0 Documentation: Spanning Tree,» Ryu, 2014. [Internett]. Available:

https://osrg.github.io/ryu-book/en/html/spanning_tree.html. [Funnet 27 April 2016].

[76

]

Ryu, «simple_switch_stp_13.py,» 18 Februar 2014. [Internett]. Available:

https://github.com/osrg/ryu-book/blob/master/en/source/sources/simple_switch_stp_13.py.



Rev: v1.00 58(68) 31.05.16

[77

]

Ashirkar, «Understanding Basics of Multicast RPF (Reverse Path Forwarding),» Cisco, 8 Januar

2015. [Internett]. Available:

https://supportforums.cisco.com/document/128461/understanding-basics-multicast-rpf-

reverse-path-forwarding. [Funnet 19 Mai 2016].

[78

]

Open Networking Foundation, «The Benefits of Multiple Flow Tables and TTP,» ONF TR-510,

2015.

[79

]

R. Izard, «Floodlight VM,» Atlassian, 26 April 2016. [Internett]. Available:

https://floodlight.atlassian.net/wiki/display/floodlightcontroller/Floodlight+VM. [Funnet 9 Mai

2016].

[80

]

Floodlight, «Floodlight Documentation,» Atlassian, [Internett]. Available:

https://floodlight.atlassian.net/wiki/display/floodlightcontroller/. [Funnet 20 April 2016].

[81

]

F. Dürr, «OpenDaylight: Programming Flows with the REST Interface and cURL,» Networked and

Mobile Systems Blog, 2014.

[82

]

CURL, «curl and libcurl,» 18 Mai 2016. [Internett]. Available: https://curl.haxx.se/. [Funnet 19

Mai 2016].

[83

]

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: 10.1109/JPROC.2014.2371999, pp. 14-76, 2014.

[84

]

E. Banks, «Show 231 – OpenFlow’s Possible Futures with Curt Beckmann,» PacketPushers, 3

April 2015. [Internett]. Available: https://packetpushers.net/podcast/podcasts/show-231-

openflows-possible-futures-with-curt-beckmann/. [Funnet 27 Mars 2016].

[85

]

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:

10.1109/MASCOTS.2013.58, pp. 389-393, 2013.

[86

]

F. Dürr, «Developing OSGi Components for OpenDaylight,» 18 Januar 2014. [Internett].

Available: http://www.frank-durr.de/?p=84. [Funnet 02 Mai 2016].

[87

]

OpenDaylight, «OpenDaylight User Guide,» [Internett]. Available:

https://www.opendaylight.org/sites/opendaylight/files/bk-user-guide.pdf. [Funnet 02 Mai

2016].

[88

]

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. 623-654, 2016.

[89

]

R. Smeliansky, «SDN for network security,» Science and Technology Conference (Modern

Networking Technologies) (MoNeTeC), nr. doi: 10.1109/MoNeTeC.2014.6995602, pp. 1-5, 2014.


Rev: v1.00 59(68) 31.05.16

[90

]

Open Networking Foundation, «ONF Blog: Four Steps to SDN,» 21 Oktober 2014. [Internett].

Available: https://www.opennetworking.org/?p=1492&option=com_wordpress&Itemid=474.


[91

]

Open Networking Foundation, «Migration Use Cases and Methods,» 2013. [Internett].

Available: https://www.opennetworking.org/images/stories/downloads/sdn-resources/use-

cases/Migration-WG-Use-Cases.pdf. [Funnet 21 Mai 2016].

[92

]

D. Bombal, «GNS3 Academy: Practical SDN and OpenFlow Fundamentals,» GNS3 Academy, 12

Oktober 2015. [Internett]. Available: http://academy.gns3.com/courses/a-practical-sdn-and-

openflow-introduction. [Funnet 30 Mai 2016].

[93

]

B. Koley, «Software Defined Networking at Scale,» 2014. [Internett]. Available:

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/42948.pd

f. [Funnet 23 April 2016].

[94

]

EstiNet, «EstiNet:OpenFlow add-on,» 2016. [Internett]. Available:

http://www.estinet.com/es/wp-

content/themes/royal/upload/product/20150303171648260.png. [Funnet 30 Mai 2016].


Rev: v1.00 60(68) 31.05.16

Appendiks B Forkortelser og ordforklaringer

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


Rev: v1.00 61(68) 31.05.16

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 programvare

Får ikke prøvd programvare som er relevant for oppgaven

Finne gode alternativer

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 ............................................................................................................... 11

Figur 4: SDN Switching........................................................................................................................... 12

Figur 5: Ulik trafikk må innom ulike nettverkstjenester ........................................................................ 15

Figur 6: STP konfigurasjonsflagg i OpenFlow ........................................................................................ 19

Figur 7: Konfigurasjon av OpenFlow på fysisk HP switch ...................................................................... 20

Figur 8: VirtualBox med ulike virtuelle maskiner som er blitt brukt ..................................................... 21

Figur 9: Virtuelt nettverkskort ............................................................................................................... 22

Figur 10: Enkel DHCP-server .................................................................................................................. 23

Figur 11: Mininet kommando for oppretting av emulert nettverk ....................................................... 23


Rev: v1.00 62(68) 31.05.16

Figur 12: MiniEdit .................................................................................................................................. 24

Figur 13: EstiNet brukergrensesnitt ...................................................................................................... 25

Figur 14: Wireshark med støtte for OpenFlow 1.3 ................................................................................ 26

Figur 15: OpenDaylight brukergrensesnitt ............................................................................................ 27

Figur 16: Floodlight brukergrensesnitt .................................................................................................. 27

Figur 17: HP VAN SDN brukergrensesnitt .............................................................................................. 28

Figur 18: Ryu kommandolinje ................................................................................................................ 29

Figur 19: Enkel topologi med en switch og fire hoster .......................................................................... 30

Figur 20: Kommandoutskrift: Ingen kontakt mellom hostene .............................................................. 31

Figur 21: Kommandoutskrift: To av hostene har kontakt via ping ........................................................ 31

Figur 22: Kommandoutskrift: MAC-adresser brukes for matching av pakker ....................................... 32

Figur 23: Kommandoutskrift: IP adresser i flow table ........................................................................... 33

Figur 24: Kommandoutskrift: TCP port 80 som matchkriterie i flow table. Ingen ping ........................ 34

Figur 25: Kommandoutskrift: Kommunikasjon mellom hoster via TCP port 80.................................... 34

Figur 26: Pakkemodifikasjon i switch .................................................................................................... 35

Figur 27: Kommandoutskrift: Statisk ARP og IP gateway ...................................................................... 35

Figur 28: Kommandoutskrift: Kommunikasjon via ping mellom hostene ............................................. 36

Figur 29: Wireshark H1 .......................................................................................................................... 36

Figur 30: Wireshark H2 .......................................................................................................................... 37

Figur 31: VLAN lab topologi ................................................................................................................... 37

Figur 32: Kommandoutskrift: Konfigurering av VLAN tag i Open vSwitch ............................................ 38

Figur 33: Kommandoutskrift: Ping vellykket innenfor samme VLAN .................................................... 38

Figur 34: Kommandoutskrift: Endring av VLAN ID ................................................................................ 39

Figur 35: STP i et SDN-nettverk ............................................................................................................. 40

Figur 36: Topologi. Hver switch flooder innkommende meldinger, og benytter seg av RPF ................ 41

Figur 37: Tabeller som trengs for å bruke RPF ...................................................................................... 41

Figur 38: Nødvendige kommandoer i de tre OVS-switchene ................................................................ 42

Figur 39: Python-kode for topologien i Mininet .................................................................................... 43

Figur 40: Topologi, ping mellom maskinene tar ulik sti frem og tilbake ............................................... 43

Figur 41: Kommandoutskrift: Svar på spørring mot controller ............................................................. 44

Figur 42: Kommandoutskrift: Endringer i switchers flow table ............................................................ 45

Figur 43: Kommandoutskrift: Spørring via REST, info om S1 ................................................................ 46

Figur 44: Kommandoutskrift: Switchenes flow tables, med antall pakker sendt. Trafikk bruker begge

stier. ....................................................................................................................................................... 47

Appendiks E RYU STP utskrift [STP][INFO] dpid=0000000000000002: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000002: [port=2] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000003: Join as stp bridge. [STP][INFO] dpid=0000000000000002: [port=3] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000003: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000003: [port=2] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: Join as stp bridge.


Rev: v1.00 63(68) 31.05.16

[STP][INFO] dpid=0000000000000003: [port=3] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=2] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=2] Receive superior BPDU. [STP][INFO] dpid=0000000000000001: [port=3] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=1] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000001: [port=2] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000001: [port=3] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000001: Root bridge. [STP][INFO] dpid=0000000000000001: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=2] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=3] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000003: [port=2] Receive superior BPDU. [STP][INFO] dpid=0000000000000003: [port=1] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000003: [port=2] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000003: [port=3] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000003: Non root bridge. [STP][INFO] dpid=0000000000000003: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000003: [port=2] ROOT_PORT / LISTEN [STP][INFO] dpid=0000000000000003: [port=3] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000002: [port=3] Receive superior BPDU. [STP][INFO] dpid=0000000000000002: [port=1] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000002: [port=2] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000002: [port=3] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000002: Root bridge. [STP][INFO] dpid=0000000000000002: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000002: [port=2] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000002: [port=3] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=3] Receive superior BPDU. [STP][INFO] dpid=0000000000000001: [port=1] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000001: [port=2] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000001: [port=3] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000001: Root bridge. [STP][INFO] dpid=0000000000000001: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=2] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=3] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000002: [port=2] Receive superior BPDU. [STP][INFO] dpid=0000000000000002: [port=1] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000002: [port=2] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000002: [port=3] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000002: Non root bridge. [STP][INFO] dpid=0000000000000002: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000002: [port=2] ROOT_PORT / LISTEN [STP][INFO] dpid=0000000000000002: [port=3] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000003: [port=3] Receive superior BPDU. [STP][INFO] dpid=0000000000000003: [port=1] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000003: [port=2] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000003: [port=3] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000003: Non root bridge. [STP][INFO] dpid=0000000000000003: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000003: [port=2] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000003: [port=3] ROOT_PORT / LISTEN


Rev: v1.00 64(68) 31.05.16

[STP][INFO] dpid=0000000000000001: [port=3] Receive superior BPDU. [STP][INFO] dpid=0000000000000001: [port=1] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000001: [port=2] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000001: [port=3] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000001: Root bridge. [STP][INFO] dpid=0000000000000001: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=2] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=3] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000003: [port=2] Receive superior BPDU. [STP][INFO] dpid=0000000000000003: [port=1] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000003: [port=2] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000003: [port=3] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000003: Non root bridge. [STP][INFO] dpid=0000000000000003: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000003: [port=2] NON_DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000003: [port=3] ROOT_PORT / LISTEN [STP][INFO] dpid=0000000000000002: [port=3] Receive superior BPDU. [STP][INFO] dpid=0000000000000002: [port=1] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000002: [port=2] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000002: [port=3] DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000002: Non root bridge. [STP][INFO] dpid=0000000000000002: [port=1] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000002: [port=2] ROOT_PORT / LISTEN [STP][INFO] dpid=0000000000000002: [port=3] DESIGNATED_PORT / LISTEN [STP][INFO] dpid=0000000000000001: [port=1] DESIGNATED_PORT / LEARN [STP][INFO] dpid=0000000000000001: [port=2] DESIGNATED_PORT / LEARN [STP][INFO] dpid=0000000000000001: [port=3] DESIGNATED_PORT / LEARN [STP][INFO] dpid=0000000000000003: [port=1] DESIGNATED_PORT / LEARN [STP][INFO] dpid=0000000000000003: [port=2] NON_DESIGNATED_PORT / LEARN [STP][INFO] dpid=0000000000000003: [port=3] ROOT_PORT / LEARN [STP][INFO] dpid=0000000000000002: [port=1] DESIGNATED_PORT / LEARN [STP][INFO] dpid=0000000000000002: [port=2] ROOT_PORT / LEARN [STP][INFO] dpid=0000000000000002: [port=3] DESIGNATED_PORT / LEARN [STP][INFO] dpid=0000000000000001: [port=1] DESIGNATED_PORT / FORWARD [STP][INFO] dpid=0000000000000001: [port=2] DESIGNATED_PORT / FORWARD [STP][INFO] dpid=0000000000000001: [port=3] DESIGNATED_PORT / FORWARD [STP][INFO] dpid=0000000000000003: [port=1] DESIGNATED_PORT / FORWARD [STP][INFO] dpid=0000000000000003: [port=3] ROOT_PORT / FORWARD [STP][INFO] dpid=0000000000000002: [port=1] DESIGNATED_PORT / FORWARD [STP][INFO] dpid=0000000000000003: [port=2] NON_DESIGNATED_PORT / BLOCK [STP][INFO] dpid=0000000000000002: [port=2] ROOT_PORT / FORWARD [STP][INFO] dpid=0000000000000002: [port=3] DESIGNATED_PORT / FORWARD


Rev: v1.00 65(68) 31.05.16

Appendiks F LAB-utskrifter =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2016.03.30 10:38:13 =~=~=~=~=~=~=~=~=~=~=~= login as: mininet [email protected]'s password: Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.13.0-24-generic x86_64) * Documentation: https://help.ubuntu.com/ Last login: Wed Mar 30 10:35:59 2016 from 192.168.50.3 mininet@mininet-vm:~$ mininet@mininet-vm:~$ mininet@mininet-vm:~$ mininet@mininet-vm:~$ # LAB START mininet@mininet-vm:~$ sudo mn --controller=none --topo=single,4 --mac *** Creating network *** Adding controller *** Adding hosts: h1 h2 h3 h4 *** Adding switches: s1 *** Adding links: (h1, s1) (h2, s1) (h3, s1) (h4, s1) *** Configuring hosts h1 h2 h3 h4 *** Starting controller *** Starting 1 switches s1 ... *** Starting CLI: mininet> net h1 h1-eth0:s1-eth1 h2 h2-eth0:s1-eth2 h3 h3-eth0:s1-eth3 h4 h4-eth0:s1-eth4 s1 lo: s1-eth1:h1-eth0 s1-eth2:h2-eth0 s1-eth3:h3-eth0 s1-eth4:h4-eth0 mininet> dump <Host h1: h1-eth0:10.0.0.1 pid=3080> <Host h2: h2-eth0:10.0.0.2 pid=3083> <Host h3: h3-eth0:10.0.0.3 pid=3085> <Host h4: h4-eth0:10.0.0.4 pid=3087> <OVSSwitch s1: lo:127.0.0.1,s1-eth1:None,s1-eth2:None,s1-eth3:None,s1-eth4:None pid=3092> mininet> mininet> 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


Rev: v1.00 66(68) 31.05.16

h4 -> X X X *** Results: 100% dropped (0/12 received) 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) mininet> sh ovs-ofctl del-flows s1 mininet> ovs-ofctl dump-flows s1 NXST_FLOW reply (xid=0x4): mininet> 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) mininet> sh ovs-ofctl add-flow s1 arp,nw_dst=10.0.0.1,actions=output:1 mininet> sh ovs-ofctl add-flow s1 arp,nw_dst=10.0.0.2,actions=output:2 mininet> sh ovs-ofctl add-flow s1 ip,nw_src=10.0.0.1,nw_dst=10.0.0.2,actions=output:2 mininet> sh ovs-ofctl add-flow s1 ip,nw_src=10.0.0.2,nw_dst=10.0.0.1,actions=output:1 mininet> mininet> pingall *** Ping: testing ping reachability h1 -> h2 X X h2 -> h1 X X h3 -> X X X


Rev: v1.00 67(68) 31.05.16

h4 -> X X X *** Results: 83% dropped (2/12 received) mininet> mininet> sh ovs-ofctl dump-flows s1 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=103.852s, table=0, n_packets=2, n_bytes=196, idle_age=77, ip,nw_src=10.0.0.1,nw_dst=10.0.0.2 actions=output:2 cookie=0x0, duration=103.041s, table=0, n_packets=2, n_bytes=196, idle_age=77, ip,nw_src=10.0.0.2,nw_dst=10.0.0.1 actions=output:1 cookie=0x0, duration=103.863s, table=0, n_packets=8, n_bytes=336, idle_age=36, arp,arp_tpa=10.0.0.2 actions=output:2 cookie=0x0, duration=103.873s, table=0, n_packets=8, n_bytes=336, idle_age=39, arp,arp_tpa=10.0.0.1 actions=output:1 mininet> mininet> sh ovs-ofctl del-flows s1 mininet> mininet> 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=10.0.0.2,actions=normal mininet> mininet> sh ovs-ofctl dump-flows s1 NXST_FLOW reply (xid=0x4): cookie=0x0, duration=112.216s, table=0, n_packets=11, n_bytes=828, idle_age=10, tcp,tp_dst=80 actions=output:2 cookie=0x0, duration=111.564s, table=0, n_packets=7, n_bytes=466, idle_age=10, ip,nw_src=10.0.0.2 actions=NORMAL cookie=0x0, duration=112.255s, table=0, n_packets=12, n_bytes=504, idle_age=15, arp 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=333.038s, table=0, n_packets=10, n_bytes=760, idle_age=157, ip,nw_src=10.0.0.2 actions=NORMAL cookie=0x0, duration=333.729s, table=0, n_packets=42, n_bytes=1764, idle_age=92, arp actions=NORMAL mininet> mininet> exit *** Stopping 0 controllers *** Stopping 6 terms


Rev: v1.00 68(68) 31.05.16

*** Stopping 4 links .... *** Stopping 1 switches s1 *** Stopping 4 hosts h1 h2 h3 h4 *** Done completed in 9140.566 seconds

Software-Defined Networking - HVLhome.hvl.no/ai/elektro/2016/BO16E-45.pdf · Software-Defined Networking Rev: v1.00 5(68) 31.05.16 Det blir presentert ulike begreper og teknologier

Documents