software-defined networking - hvlhome.hvl.no/ai/elektro/2016/bo16e-45.pdf · software-defined...
Post on 29-Jun-2020
6 Views
Preview:
TRANSCRIPT
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:
Knut.Ovsthus@hib.no 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.
Software-Defined Networking
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
Software-Defined Networking
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).
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
Rev: v1.00 8(68) 31.05.16
Appendiks D Figurliste .................................................................................................................... 61
Appendiks E RYU STP utskrift ......................................................................................................... 62
Appendiks F LAB-utskrifter ............................................................................................................. 65
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
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.
Software-Defined Networking
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
Software-Defined Networking
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.
Software-Defined Networking
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].
Software-Defined Networking
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.
Software-Defined Networking
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
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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
# S2 table=0,ip,nw_dst=10.0.0.2,actions=resubmit(,1) table=0,arp,nw_dst=10.0.0.2,actions=resubmit(,1) table=0,priority=0,actions=flood
table=1,ip,nw_src=10.0.0.1,in_port=1,actions=output:2 table=1,arp,nw_src=10.0.0.1,in_port=1,actions=output:2 table=1,ip,nw_src=10.0.0.3,in_port=3,actions=output:2 table=1,arp,nw_src=10.0.0.3,in_port=3,actions=output:2
# S3 table=0,ip,nw_dst=10.0.0.3,actions=resubmit(,1) table=0,arp,nw_dst=10.0.0.3,actions=resubmit(,1) table=0,priority=0,actions=flood
table=1,ip,nw_src=10.0.0.1,in_port=1,actions=output:3 table=1,arp,nw_src=10.0.0.1,in_port=1,actions=output:3 table=1,ip,nw_src=10.0.0.2,in_port=2,actions=output:3 table=1,arp,nw_src=10.0.0.2,in_port=2,actions=output:3
Figur 38: Nødvendige kommandoer i de tre OVS-switchene
Fordelen med to tabeller er at interessant trafikk kan videresendes til neste tabell for behandling,
mens resterende pakker floodes. Flere tabeller gjør flyttabellen mer oversiktlig og mer effektiv. [78]
bruker RPF som et eksempel, og forklarer at med bruk av en tabell trenger en 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.
Software-Defined Networking
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.
Software-Defined Networking
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.
Software-Defined Networking
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
curl -X POST -d '{"switch": "00:00:00:00:00:00:00:02", "name":"flow-mod-2", "cookie":"0", "priority":"100", "in_port":"1","active":"true", "actions":"output=2"}' http://127.0.0.1:8080/wm/staticflowpusher/json
curl -X POST -d '{"switch": "00:00:00:00:00:00:00:04", "name":"flow-mod-3", "cookie":"0", "priority":"100", "in_port":"1","active":"true", "actions":"output=3"}' http://127.0.0.1:8080/wm/staticflowpusher/json
curl -X POST -d '{"switch": "00:00:00:00:00:00:00:04", "name":"flow-mod-4", "cookie":"0", "priority":"100", "in_port":"3","active":"true", "actions":"output=2"}' http://127.0.0.1:8080/wm/staticflowpusher/json
curl -X POST -d '{"switch": "00:00:00:00:00:00:00:03", "name":"flow-mod-5", "cookie":"0", "priority":"100", "in_port":"2","active":"true", "actions":"output=1"}' http://127.0.0.1:8080/wm/staticflowpusher/json
curl -X POST -d '{"switch": "00:00:00:00:00:00:00:01", "name":"flow-mod-6", "cookie":"0", "priority":"100", "in_port":"3","active":"true", "actions":"output=1"}' 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.
Software-Defined Networking
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
Software-Defined Networking
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.
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
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.
Software-Defined Networking
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].
Software-Defined Networking
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].
Software-Defined Networking
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].
Software-Defined Networking
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.
Software-Defined Networking
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.
[Funnet 4 Mai 2016].
[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:
http://www8.hp.com/us/en/products/networking-switches/product-detail.html?oid=5171624.
[Funnet 25 April 2016].
[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:
http://www8.hp.com/us/en/products/networking-switches/product-detail.html?oid=4174795.
[Funnet 25 April 2016].
[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].
Software-Defined Networking
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/.
[Funnet 04 Mai 2016].
[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].
Software-Defined Networking
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.
[Funnet 9 Mai 2016].
[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.
[Funnet 4 Mai 2016].
Software-Defined Networking
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.
Software-Defined Networking
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.
[Funnet 21 Mai 2016].
[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].
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
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.
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
Rev: v1.00 65(68) 31.05.16
Appendiks F LAB-utskrifter =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2016.03.30 10:38:13 =~=~=~=~=~=~=~=~=~=~=~= login as: mininet mininet@192.168.50.10'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
Software-Defined Networking
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
Software-Defined Networking
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
Software-Defined Networking
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
top related