Divizarea resurselor de rețea pentru a construi [625811]

Universitatea “Politehnica” din București
Facultatea de Electronică, Telecomunicații și Tehnologia Informației

Divizarea resurselor de rețea pentru a construi
rețele virtua le independente folosind aplicaț ia
Flowvisor

Lucrare de disertație

prezentată ca cerință parțială pentru obținerea titlului de
Master în domeniul Telecomunicații
programul de studii de masterat Managementul serviciilor și rețelelor

Conducător științific Absolvent
Ș. L. Dr. Ing. Șerban OBREJA Student: [anonimizat] – Petronela NĂSTASE

2019

2

3

4

5

6

7
Cuprins
Lista figurilor ………………………….. ………………………….. ………………………….. ………………………….. ……………………. 9
Lista de acronime ………………………….. ………………………….. ………………………….. ………………………….. ………….. 11
Introducere ………………………….. ………………………….. ………………………….. ………………………….. ……………………….. 13
Scopul lucrării de disertație ………………………….. ………………………….. ………………………….. …………………………. 14
Conținutul lucrării ………………………….. ………………………….. ………………………….. ………………………….. ………….. 14
Capitolul 1 ………………………….. ………………………….. ………………………….. ………………………….. ……………………….. 15
1. Planurile de control si de date ………………………….. ………………………….. ………………………….. ………………. 15
1.1. Introducere ………………………….. ………………………….. ………………………….. ………………………….. ………….. 15
1.2. Planul de control ………………………….. ………………………….. ………………………….. ………………………….. …. 15
1.3. Planul de date ………………………….. ………………………….. ………………………….. ………………………….. ……… 17
1.4. Mutarea informațiilor între planuri ………………………….. ………………………….. ………………………….. ……… 18
1.5. De ce poate fi importantă separarea? ………………………….. ………………………….. ………………………….. …… 19
1.6. Planuri de control distribuite ………………………….. ………………………….. ………………………….. ……………… 21
1.7. Planuri de control centralizate ………………………….. ………………………….. ………………………….. ……………. 21
Capitolul 2 ………………………….. ………………………….. ………………………….. ………………………….. ……………………….. 23
2. Openflow ………………………….. ………………………….. ………………………….. ………………………….. ………………. 23
2.1. Pro tocol de sârmă ………………………….. ………………………….. ………………………….. ………………………….. … 25
2.2 Replicare ………………………….. ………………………….. ………………………….. ………………………….. ……………… 28
2.3. FAWG (Forwarding Abstraction Workgroup) ………………………….. ………………………….. ………………….. 29
Capitolul 3 ………………………….. ………………………….. ………………………….. ………………………….. ……………………….. 31
3. Controller -ul SDN ………………………….. ………………………….. ………………………….. ………………………….. ……….. 31
3.1 Introducere ………………………….. ………………………….. ………………………….. ………………………….. …………… 31
3.2 Mininet ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 32
3.3. Vmware ………………………….. ………………………….. ………………………….. ………………………….. ……………… 34
Capitolul 4 ………………………….. ………………………….. ………………………….. ………………………….. ……………………….. 35
4. Prezentarea to ol-urilor folosite ………………………….. ………………………….. ………………………….. ……………….. 35
4.1 Oracle Virtual Box Manager ………………………….. ………………………….. ………………………….. ………………. 35
4.2. Mininet ………………………….. ………………………….. ………………………….. ………………………….. ………………. 36
4.3. Mobaxtrem ………………………….. ………………………….. ………………………….. ………………………….. …………. 38
4.4. Legatura dintre mașină virtuală și terminalul Mobaxtrem ………………………….. ………………………….. …… 38
4.5. Flowvisor ………………………….. ………………………….. ………………………….. ………………………….. ……………. 41
Capitolul 5 ………………………….. ………………………….. ………………………….. ………………………….. ……………………….. 43
5. Implementarea topologiilor ………………………….. ………………………….. ………………………….. …………………….. 43

8
5.1. Mininet ………………………….. ………………………….. ………………………….. ………………………….. ………………. 43
5.1.1. Interacțiunea între gazde și switch -uri ………………………….. ………………………….. ……………………….. 45
5.1.2. Testarea conectivității dintre gazde ………………………….. ………………………….. ………………………….. . 45
5.1.3. Executarea unui test de regresie ………………………….. ………………………….. ………………………….. …… 46
5.1.4. Adăugarea latenței în rețeaua Mininet ………………………….. ………………………….. ……………………….. 46
5.1.5. Topologii personalizate ………………………….. ………………………….. ………………………….. ………………. 51
5.1.6. Utilizarea unui controler “la distanță” ………………………….. ………………………….. ……………………….. 52
5.2. Funcționarea Openflow -ului ………………………….. ………………………….. ………………………….. ………………. 53
5.3. Implementarea “felierii” ………………………….. ………………………….. ………………………….. ……………………. 58
5.3.1. Partea 1: „Feliere” de bază – topologie simplă ………………………….. ………………………….. ……………. 60
5.3.1.1. Crearea „feliilor” ………………………….. ………………………….. ………………………….. ………………….. 61
5.3.1.2. Crearea de spațiilor de flux ………………………….. ………………………….. ………………………….. ……. 62
5.3.1.3. Ștergerea „feliilor“ ………………………….. ………………………….. ………………………….. ……………….. 64
5.3.2. Partea a 2 -a: „Felierea” avansată a spațiilor de flux ………………………….. ………………………….. …….. 64
5.3.2.1. Crearea „feliilor” ………………………….. ………………………….. ………………………….. ………………….. 65
5.3.2.2. Crearea spațiilor de flux ………………………….. ………………………….. ………………………….. ……….. 66
5.3.2.3. Ștergerea “fe liilor” ………………………….. ………………………….. ………………………….. ……………….. 70
Concluzie ………………………….. ………………………….. ………………………….. ………………………….. …………………………. 71
SDN este cu adevărat despre operațiuni și management ………………………….. ………………………….. …………….. 71
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ………………………. 73
Anexa 1 ………………………….. ………………………….. ………………………….. ………………………….. ………………………….. .. 75
Topologie cu 4 switch -uri și 4 gazde ………………………….. ………………………….. ………………………….. ……………… 75

9
Lista figuri lor

Capitolul 1
Figura 1.1. Separarea planului de control și de date

Capitolul 2
Figura 2.1. Componentele cheie ale modelului OpenFlow
Figura 2.1. Primitive OpenFlow (sârma) versiunea 1.0
Figura 2.3. Modelul de redirecționare OpenFlow 1.0 ( model de masă partajat foarte simplu)

Capitolul 3
Figura 3.1. Un exemplu simplu de rețea Mininet
Figura 3.2. Reprezentarea grafica a rețelei cu 2, respectiv 4 gazde
Figura 3.3. Reprezentarea grafică a rețelei cu switch -uri pentru fiecare gazda, respectiv cu 2 rânduri de
switch -uri

Capitolul 4
Figura 4.1 . Oracle Virtual Box Manager
Figura 4.2 . Manager Virtual Box – opțiunea de import
Figura 4.3 . Import mininet
Figura 4.4 . Mașina Virtuală instalată
Figura 4.5 . Mobaxtrem
Figura 4.6 . Mașina virtuala în modul de funcționare
Figura 4.7 . Comanda ifconfig pentur aflarea IP -ului
Figura 4.8 . Configurare sesiune SSH Mobaxterm
Figura 4.9 . Logare Mobaxterm

Capitolul 5
Figura 5.1. 1. Test de ping pentru o topologie standard
Figura 5. 1.2. Topologie standard cu 2 switch -uri și 2 host -uri
Figura 5. 1.3. Introducerea latenței și a lungimii de bandă
Figura 5. 1.4. Captura pe interfața lo

10
Figura 5. 1.5. Pachete de echo reply
Figura 5. 1.6. Pachete capturate după pingall
Figura 5. 1.7. Reprezentarea grafica a rețelei cu 4 gazde
Figura 5. 1.8. Reprezentarea grafică a rețelei cu 4 switch -uri, fiecare cu cate o gazdă
Figura 5. 1.9. Reprezentarea grafică a rețelei cu 2 nivele de switch -uri și 2 gazde [5]
Figura 5. 1.10. Încărcarea procesorului la rularea unei topologii mai mari
Figura 5. 1.11. Înainte de sudo mn –mac
Figura 5. 1.12. După sudo mn –mac
Figura 5. 2.1. Pachet -IN/OUT
Figura 5.2.2 . Acțiunea de a redirecționa pacchetul pe portul 4
Figura 5. 2.3 Pachete capturate în Wireshark
Figura 5.2 .4 Mesajul SYN ACK
Figura 5.2.5 Mesajul de modifi care OpenFlow
Figura 5. 3.1 Topoloie principală
Figura 5.3.2. „Felierea” de bază
Figura 5.3.3. Ping-ul în h4 funcționează, dar nu și celelalte
Figura 5.3.4. „Felierea” avansată a spațiilor de flux
Figura 5.3.5. Portul 1 de ieșire de pe switch -ul 1
Figura 5.3.6. Portul 4 de ieșire de pe switch -ul 4
Figura 5.3.7 . Limitarea de bandă

11
Lista de acronime

Abreviere Denumire în limba engleză Denumire în limba română
ACL Access control list Lista de control de acces
ALU Alcatel Alcatel
API Application Programming Interface Interfața de programare a aplicației
BGP Border Gateway Protocol Protocolul gateway de frontieră
BSS Business support systems Sisteme de sprijin pentru afaceri
CLI Command Line Interface Interfața de linie de comandă
COS Class o f Service Clasa serviciu lui
CPU Central Processing U nit Unitatea centrală de procesare
ESX Elastic Sky X Cerul elastic X
FPGA Field Programmable Gate Array Matrice de porți programabile de câ mp
IEEE Institute of Electrical and Electronics
Engineers Institutul Inginerilor Electrotehniști și
Electroniști
MAC Media Access Control Control acces media
NETCONF Network Configuration Protocol Protocol de configurare a rețelei
OSPF Open Shortest Path First „Deschide întâi calea cea mai scurtă”
OSS Operations Support Systems Sisteme de asistență operațională
Qos Quality of Service Calitatea serviciului
SDN Software Defined Network Rețeaua definită de software
TCAM Ternary Content Address Memory Memorie de adresă ternară de conținut
TCP Transmis sion Control Protocol Protocol de control al transmisiei
TLS Transport Layer Security Securitatea stratului de transport
TOS Type of Service Tipul serviciului
UDP User Datagram Protocol Protocol de datagram de utilizator

12

13
Introducere
Până acum câțiva ani, resursele de stocare, calcul și rețea au fost menținute în mod intenționat,
separate fizic și operațional unele de altele. Chiar și sistemele folosite pentru gestionarea acestor resurse
au fost separate – adesea fizic. Într -adevăr, ab ia după introducerea (și cererea) de putere ieftină de calcul,
stocare și rețea în mediile din centrele de date, organizațiile au fost nevoite să reunească aceste elemente
diferite. A fost o schimbare de paradigmă care a adus, de asemenea, aplicații care g estionează și operează
aceste resurse mult mai aproape ca niciodată.
Acum aproximativ 10 ani a avut loc o transformare interesantă. O companie numită VMware a
inventat o tehnologie interesantă care a permis unui sistem de operare gazdă, cum ar fi una dintr e
distribuțiile Linux populare, să execute unul sau mai multe sisteme de operare client (de exemplu,
Windows). Ceea ce a făcut VMware a fost crearea unui mic program care a creat un mediu virtual care
a sintetizat un mediu de calcul real. Apoi a marcat res urse reale între mașinile virtuale. Acest program de
supraveghere a fost numit hipervizor.
Câțiva ingineri de la Universitatea Stanford au creat un protocol numit. OpenFlow a fost arhivat
pentru o serie de dispozitive care conțin numai planuri de date pent ru a răspunde comenzilor care le -au
fost trimise de la un controler centralizat (logic) care găzduia unicul plan de control pentru rețeaua
respectivă. Controlerul a fost responsabil de menținerea tuturor căilor de rețea, precum și de programarea
fiecăruia dintre dispozitivele de rețea pe care le -a controlat. Comenzile și răspunsurile la aceste comenzi
sunt descrise în protocolul OpenFlow.
Este interesant de observat că cel puțin una dintre părțile majore din ceea ce încearcă să propună
SDN și OpenFlow sunt programabilitatea mai mare și mai flexibilă a dispozitivelor de rețea. Aceasta nu
are neapărat nimic de -a face cu locația controlului rețelei și planurilor de date; cu toate acestea, este
preocupat de modul în care sunt programate. De reținut este că una dintre motivațiile pentru crearea SDN
și OpenFlow a fost flexibilitatea modului în care se poate programa un dispozitiv de rețea, nu doar acolo
unde este programat.
Dacă se observă ce se întâmplă în arhitectura SDN tocmai descrisă, ambele întrebări sunt
rezolvate. Întrebarea este dacă aspectul de programabilitate este sau nu cea mai optimă alegere.
Rețele definite de software (SDN): o abordare arhitecturală care optimizează și simplifică operațiunile
rețelei prin legarea mai strânsă a interacțiunii (adică f urnizarea, mesageria și alarmarea) între aplicații și
servicii și dispozitive de rețea, indiferent dacă sunt reale sau virtualizate. Deseori se realizează utilizând
un punct de control centralizat al rețelei – care este adesea realizat ca un controler SDN – care apoi

14
orchestrează, mediază și facilitează comunicarea între aplicațiile care doresc să interacționeze cu
elementele de rețea și elementele de rețea care doresc să transmită informații.

Scopul lucrării de disertaț ie
Scopul tezei este de a crea o top ologie cu câteva switch -uri și câteva gazde și de a implementa
“felierea” acesteia.
Software Defined Networking (SDN) și virtualizarea rețelelor oferă noi modalități de a proiecta,
construi și opera rețele. În ultimele două decenii, au avut loc o mulțime d e inovații în ceea ce privește
dispozitivele pe care le folosim pentru a accesa rețeaua, aplicațiile și serviciile de care depindem în viața
de zi cu zi, precum și soluțiile de calcul și de stocare pe care ne bazăm pentru a păstra aceste „Big data”;
cu toa te acestea, rețeaua de bază care conectează toate aceste lucruri a rămas practic neschimbată.
Cerințele oamenilor și dispozitivelor în continuă creștere care utilizează rețeaua îi forțează limitele

Conținutul lucră rii
Primul capitol conține ideea generală despre rețele definite software, despre cele 2 mari planuri de
control și de date. În capitolul 2 am scris o introducere despre protocolul Openflow, iar în capitolul 3 am
prezentat 2 controlere SDN. Unul dintre acestea, anume Mininet, este utilizat mai de parte în partea
practică a acestei lucrări. Capitolul 4 am explicat ceea ce am instalat și ce instrumente am folosit pentru
a putea sa fac această “feliere” a rețelei.
Ultimul capitol, dar și cel mai interesant, conține partea practică, anume câteva exemp le de moduri
de a împarți o rețea destul de simplă în două părți. Am început prin a explica anumite comenzi, pe care
le-am dat în terminal, împreună cu câteva capturi de schimb de pachete din Wireshark. Am explicat
practic, conceptul de Openflow, dar și ce l de Mininet. La final am aratat două modalități de a “felia”
rețeaua, dar și dovada că funcționează.

15
Capitolul 1
1. Planurile de control si de date
1.1. Introducere
Separarea planurilor de control și date este într -adevăr unul dintre principiile fund amentale ale
SDN – și de asemenea, unul dintre cele mai controversate. Deși nu este un concept nou, modul de gândire
contemporan are câteva răsuciri interesante asupra unei idei vechi: cât de departe poate fi localizat planul
de control de planul de date, câte cazuri sunt necesare pentru a satisface cerințele de rezistență și de înaltă
disponibilitate și dacă 100% din planul de control poate fi, de fapt, mutat mai departe decât câțiva
centimetri sunt toate dezbătute intens. Modul în care ne place să abordăm aceste idei este să ne gândim
la ele ca la un continuum al posibilităților care se întind între cele mai simple, fiind planul de control
complet distribuit canonic, la planul de control semi – sau logic centralizat, până la final planul de control
strict c entralizat. [1]
Să discutăm mai întâi componentele și comportamentele fundamentale ale planurilor de control
și date, de ce diferă și cum pot fi implementate.

1.2. Planul de control
La un nivel foarte ridicat, planul de control stabilește setul de date l ocale utilizat pentru crearea
intrărilor tabelului de redirecționare, care sunt la rândul lor utilizate de planul de date pentru a transmite
traficul între porturile de intrare și ieșire pe un dispozitiv. Setul de date utilizat pentru stocarea topologeia
rețelei se numește baza de informații de rutare (RIB). RIB -ul este adesea menținut consistent (adică, fără
bucle) prin schimbul de informații între alte instanțe de planuri de control din rețea. Înregistrările
tabelului de redirecționare sunt denumite în mo d obișnuit baza de informații de redirecționare (FIB) și
sunt adesea reflectate între planurile de control și date ale unui dispozitiv tipic. FIB -ul este programat
odată ce RIB -ul este considerat consistent și stabil. Pentru a efectua această sarcină, enti tatea / programul
de control trebuie să dezvolte o vedere a topologiei rețelei care satisface anumite constrângeri. Această
vizualizare a rețelei poate fi programată manual, învățată prin observație sau construită din informații
culese prin legături cu alt e cazuri de plane de control, care pot fi aflate prin utilizarea unuia sau a mai
multor protocoale de rutare, programare manuală sau o combinație de amandouă .

16
Un plan de control al stratului 2 se concentrează pe adrese hardware sau strat uri fizice, cum ar fi
adresele IEEE MAC. Un plan de control al stratului 3 este construit pentru a facilita adresele stratului de
rețea, cum ar fi cele ale protocolului IP. Într -o rețea de strat 2, comportamentele din jurul învățării MAC
adresele, mecanismele utilizate pentr u a garanta un grafic aciclic (familiar pentru majoritatea cititorilor
prin Protocolul Spanning Tree) și inundarea traficului BUM (broadcast, unicast necunoscut și multicast)
creează propriile provocări si a rată limitările scalabilității.
Ca generalizare, totuși, preocupările de scalare a stratului 2 și a stratului 3 și a proiectelor lor de
plan de control rezultate se îmbină sau hibridizează, deoarece rețelele de strat 2 nu se extind bine, datorită
numărului mare de gazde finale. În centrul acestor problem e se ocupă cu gazdele finale care se deplasează
între rețele, ceea ce duce la o transformare masivă a tabelelor de redirecționare – și trebuie să le
actualizeze suficient de repede pentru a nu perturba fluxul de trafic. Într -o rețea de nivel 2, redirecțion area
se concentrează pe accesibilitatea adreselor MAC. Astfel, rețelele de nivel 2 se ocupă în primul rând de
stocarea adreselor MAC în scopuri de redirecționare.
Deoarece adresele MAC ale gazdelor pot fi enorme într -o rețea de întreprindere mare,
administ rarea acestor adrese este dificilă. Mai rău, imaginați -vă gestionarea tuturor adreselor MAC în
mai multe întreprinderi sau pe Internet!
Într-o rețea de nivel 3, redirecționarea se concentrează pe accesibilitatea adreselor de rețea.
Informațiile privind acc esibilitatea rețelei de nivel 3 se referă în primul rând la accesibilitatea unui prefix
IP de destinație. Aceasta include prefixuri de rețea pentru mai multe familii de adrese atât pentru unicast,
cât și pentru multicast. În toate cazurile moderne, rețeaua stratului 3 este utilizată pentru a segmenta sau
a lega împreună domeniile stratului 2 pentru a depăși problemele de scară a nivelului 2. Mai exact,
podurile de nivel 2 care reprezintă unele seturi de subrețele IP sunt de obicei conectate împreună cu un
router de strat 3. Routerele de nivel 3 sunt conectate între ele pentru a forma rețele mai mari sau intervale
de adrese cu rețele subterane diferite. Rețelele mai mari se conectează la alte rețele prin routere gateway
care se specializează adesea în interco nectarea rețelelor mari. Cu toate acestea, în toate aceste cazuri,
routerul rutează traficul între rețelele de la nivelul 3 și va transmite pachetele doar la nivelul 2 atunci
când știe că pachetul a ajuns la rețeaua finală a stratului 3 care trebuie apoi l ivrat unei gazde specifice.
Unele estompări notabile ale acestor linii apar cu protocolul Switching Multiprotocol Label (MPLS),
protocolul Ethernet Virtual Private Network (EVPN) și Protocolul de separare a localizatorului / ID -ului
(LISP). Protocolul MPLS – într-adevăr o suită de protocoale – a fost format pe baza îmbinării celor mai
bune părți ale redirecționării stratului 2 (sau comutării) cu cele mai bune părți de rutare IP a stratului 3
pentru a forma o tehnologie care împărtășește expedierea extrem de rapidă a pachetelor care ATM -ul a

17
inventat cu tehnicile de semnalizare a căilor foarte flexibile și complexe adoptate din lumea IP. Protocolul
EVPN este o încercare de a rezolva problemele de scară de rețea a nivelului 2, care au fost descrise doar
prin t unelarea efectivă a punților de strat distanță 2 împreună cu o infrastructură MPLS (sau GRE) – doar
atunci informațiile privind abordarea și accesibilitatea stratului 2 sunt schimbate pe aceste tuneluri și
astfel nu contaminează (sau afectează) scara rețel elor stratului 3. Informațiile privind disponibilitatea
între podurile îndepărtate sunt schimbate ca date în cadrul unei noi familii de adrese BGP, din nou ne
contaminând rețeaua de bază. Există și alte optimizări care limitează cantitatea de adrese de niv el 2 care
sunt schimbate prin tuneluri, optimizând din nou nivelul de interacțiune între poduri. Acesta este un
design care minimizează nevoia de difuzare și multicast.
1.3. Planul de date
Planul de date gestionează dat agrame de intrare (pe fir, fibră sau în suporturi wireless) printr -o
serie de operațiuni la nivel de legături care colectează datagrama și efectuează verificări de sănătate de
bază. Un datagram3 bine format (adică corect) este procesat în planul de date prin efectuarea de căutări
în tabelul F IB (sau tabele, în unele implementări) care sunt programate mai devreme de planul de control.
Aceasta este uneori denumită calea rapidă pentru procesarea pachetelor, deoarece nu are nevoie de o altă
interogare decât identificarea destinației pachetului fol osind FIB preprogramat. O singură excepție de la
această procesare este atunci când pachetele nu pot fi corelate cu acele reguli, cum ar fi atunci când este
detectată o destinație necunoscută, iar aceste pachete sunt trimise către procesorul de rute, unde planul
de control le poate prelucra în continuare folosind RIB. Este important să înțelegem că tabelele FIB ar
putea să se afle într -o serie de obiective de redirecționare – software, software accelerat hardware (GPU
/ CPU, așa cum este exemplificat de Int el sau ARM), siliciu de mărfuri (NPU, așa cum sunt exemplificate
de Broadcom, Intel sau Marvell , pe piața switch -urilor Ethernet), FPGA și siliciu specializat (ASIC -uri
precum Juniper Trio), sau orice combinație – în funcție de designul elementului de reț ea.
Calea software din această expunere este exemplificată prin redirecționarea de către CPU a
elementului modern de rețea dedicat (de exemplu, router sau switch), care tranzacționează o căutare
intensivă a procesorului (indiferent dacă este vorba de nucl eu sau spațiul utilizatorului, este decizie legată
de un design specific in funcție de caracteristicile și infrastructura sistemului de operare gazdă) pentru
stocarea în tabel aparent nelimitată a memoriei procesorului.
Acțiunile obișnuite rezultate din c ăutarea de redirecționare a planului de date sunt „forward” (și
în cazuri speciale, cum ar fi multicast, replicare), „drop”, „re-mark” , „count” și „queue” . Unele dintre
aceste acțiuni pot fi combinate sau înlănțuite. În unele cazuri, decizia de redirecțion are returnează un port
local, indicând că traficul este destinat unui proces de rulare locală, cum ar fi OSPF sau BGP. Aceste

18
contexte de date iau ceea ce se numește calea punct prin care părăsesc calea de redirecționare hardware
și sunt redirecționate căt re procesorul de rute folosind un canal de comunicare intern. Această cale este,
în general, o cale de transfer relativ scăzută, deoarece nu este proiectată pentru redirecționarea de pachete
cu trafic mare; cu toate acestea, unele modele adaugă pur și simp lu o cale suplimentară la țesătura de
comutare internă în acest scop, ceea ce poate duce la o redirecție a ratei de linie aproape în interiorul
cutiei.
În plus față de decizia de redirecționare, planul de date poate implementa unele servicii /
caracteristi ci mici denumite în mod obișnuit ca funcții de redirecționare (exemplificate de Liste de control
de acces și QoS / Policy). În unele sisteme, aceste funcții folosesc propriile lor tabele discrete, în timp ce
altele funcționează ca extensii la tabelele de r edirecționare (creșterea lățimii intrării). În plus, modele
diferite pot implementa diferite caracteristici și ordinea operațiunilor de redirecționare (figura gfhdjk).
Unele comenzi pot face ca unele operațiuni de funcții să fie exclusiv altele.
Cu aceste caracteristici, se poate (într -o mică măsură) modifica sau preveni rezultatul căutării de
retrimitere. De exemplu:
 O intrare în lista de control de acces poate specifica o acțiune de scădere pentru un flux de
potrivire specific (rețineți că în ACL, un set mai larg de parametri poate fi implicat în decizia de
expediere). În lipsa acestuia, s -ar putea să fi existat o intrare legitimă de retransmitere și, astfel,
pachetul NU ar fi abandonat.
 O politică QOS poate, în cele din urmă, să mapeze un flux către o coa dă la ieșire sau să remarce
TOS / COS pentru a normaliza serviciul cu politicile din rețea. Și, la fel ca ACL, poate marca
pachetul ca să fie aruncat (în formă) indiferent de expedierea existentă pentru destinație / flux.

1.4. Mutarea informațiilor între planuri
Funcția internă a sistemelor de expediere distribuite multislot / multicard (bazate pe șasiu), azi
imită unele dintre comportamentele mecanismelor de control centralizate, dar distribuite fizic ale SDN.
În special, aspectele legate de distribuția t abelelor și instanțierea lor în hardware sunt de interes aici. O
examinare a funcționării interioare a unui switch distribuit tipic dezvăluie o serie de funcții și
comportamente care îi imită pe cele ale unui plan de control exteriorizat. De exemplu, în si stemele în
care planul de control se află pe un procesor / card de linie independent și există planuri de date pe alte
carduri de linie independente, trebuie să existe anumite comportamente în jurul comunicării între aceste
elemente pentru ca sistemul să f ie rezistent și tolerant la erori. Merită să investigăm dacă este nevoie sau

19
nu de toate dacă planul de control este scos din șasiu și relocat mai departe (adică, logic sau strict
centralizat).
Să începem mai întâi cu conceptul de bază de redirecționare a pachetelor. Când planul de date
este instruit de planul de control să înainteze pachetele, ascultă planul de date? Și ascultă fiecare pachet
pe care îl primește? Mai precis, există modalități prin care traficul poate fi redus în “gaura neagra” (adică,
aban donat fără nicio indicație în sistemele de expediere bazate pe hardware care sunt abordate în
implementările diferitelor furnizori)? Aceasta este o întrebare pe care trebuie să o punem, care este
independentă dacă entitatea / programul de control este sau nu centralizată, semicentralizată sau
sincronizată altfel cu alte elemente dintr -o rețea de control distribuită. În aceste sisteme, mecanismele de
detectare a erorilor de distribuție a tabelelor de redirecționare pot fi încorporate în date (de exemplu,
versiunea tabelelor) sau în mecanismul de transfer (de exemplu, semnarea tabelului cu o formă de hash
sau cookie generate din conținutul său). Aceste mecanisme asigură că versiunile software distribuite ale
tabelului sunt sincronizate și corecte odată program ate. În mod similar, rutine de verificare între
versiunea software a tabelului și versiunea hardware sunt implementate în software -ul driverului de
memorie (specific hardware -ului de redirecționare). [1]
Unii furnizori au implementat rutine pentru verifica rea intrărilor hardware post facto – după planul
de control programează planul de date – verificarea erorilor soft din cip -ul de expediere și memoriile
auxiliare. În aceste cazuri, există rutine asociate pentru a marca blocurile proaste, a muta intrările ș i
referințele. În general, aceste rutine de verificare hardware sunt costisitoare, astfel încât acestea sunt
adesea implementate ca procese de fundal (a.k.a. scavenger). În acest scop, atât rutinele de transfer cât și
cele de scriere a memoriei sunt, de as emenea, optimizate pentru a diminua tranzacțiile aeriene, în mod
obișnuit prin tehnici de batching și bulking.
Unele sisteme multislot / multicard efectuează căutări în două etape în care prima etapă de la
intrare identifică pur și simplu slotul / cardul d e ieșire pe care se efectuează o căutare secundară. În
funcție de modul în care este implementat, căutările în două etape pot permite o optimizare cu un fenomen
numit localizare care să reducă dimensiunea FIB de ieșire. În aceste cazuri, pot apărea scenari i în jurul
unei pierderi asincrone în două etape care necesită o anumită atenție și sunt de fapt dificil de detectat
până la eșec. Acestea au relevanță pentru controlul redirecționării SDN.

1.5. De ce poate fi importantă separarea?
Separarea planurilor de control și a datelor nu este un concept nou. De exemplu, orice router /
switch multislot construit în ultimii 10 ani sau mai mult are planul de control (adică creierul său) executat

20
pe un procesor / card dedicat (adesea două pentru redundanță) și funcțiil e de comutare a planului de date
executând independent pe una sau mai multe carduri de linie, fiecare având un procesor dedicat și / sau
procesor de pachete. Figura 1.1 ilustrează acest lucru arătând motorul procesorului de rută (notat drept
caseta proceso rului de rută din figura 1.1).
În figura 1.1, planul de date este implementat în caseta inferioară, care ar fi o placă de linie
separată cu ASIC -uri dedicate de procesare a porturilor conectate la porturile de intrare și ieșire de pe
cardul de linie (adică interfețe Ethernet). În funcționare normală, porturile din figura 1.1 au tabele de
redirecționare care dictează modul în care procesează comutarea interfaței de intrare la ieșire. Aceste
tabele sunt populate și gestionate de către programul sau programele procesorului / planului de control
al procesatorului de traseu. Când mesajele planului de control sau pachetele necunoscute sunt primite pe
aceste interfețe, acestea sunt, în general, împinse către procesorul de rută pentru procesare ulterioară.
Mai simpl u ar fi daca mă gândesc la procesorul de rute și la cardurile de linie ca fiind conectate printr -o
rețea internă mică, dar de mare viteză, deoarece, în realitate, aceasta este de fapt modul în care sunt
construite switch -urile moderne.

Figura 1.1. Separ area planului de control și de date

21
În plus, unele protocoale sunt de fapt concepute cu această arhitectură în minte pentru a optimiza
și îmbunătăți comportamentul acestora. De exemplu, protocolul Switching Multiprotocol Label (MPLS)
transportă controlul traficului folosind suita de protocoale IP, care, în mod ideal, ar fi implementat pe un
motor de procesor de rute dedicat, care rulează un procesor cu scop general, în timp ce se bazează pe o
paradigmă de comutare bazată pe etichetă, care este cel mai bun . Potrivit pentru un procesor de pachete
mai simplificat, dar cu performanțe mult mai mari, pe un card de linie diferit.
Până la disc uția SDN și separarea acestuia n planurile de control și de date la distanțe mai mari decât un
metru sa zicem (adică, într -un singur șasiu sau un sistem de șasiu multiplu direct legat), planurile de
control și planurile de date descrise în secțiunea precedentă au fost distribuite, dar construit și gestionat
ca un pachet de hardware și software strâns integrate (și relativ locali zate). În plus față de acele
componente și de o mulțime de infrastructură internă care a fost ascunsă în mare măsură de observatorul
extern al acestor sisteme, ambalarea rezultată a acestor componente a dus la proliferarea elementelor de
rețea bazate pe sc op. Aceste elemente au fost adesea construite pe aceeași bază de familie hardware și au
variat în eficiență (și complexitate) de transfer, bazându -se pe accentul pe echilibrul dintre serviciile,
managementul, controlul și planurile de date. Interdependențe le create de această cuplare foarte strânsă
de planuri creează probleme (motivație) care se învârt în jurul inovației, stabilității și scalei care duce în
cele din urmă la performanțe ridicate în toate aceste domenii. Cu toate acestea, aceste modele suferă de
costuri mari datorită complexității lor enorme, care este un unghi de motivație pentru SDN. [1]
1.6. Planuri de control distribuite
Paradigma de control care a evoluat odată cu internetul, care este problema noastră finală la nivel de
rețea până în pr ezent, este un model distribuit, eventual de consens. În acest model, elementele
individuale sau reprezentanții lor participă împreună la distribuirea informațiilor privind accesibilitatea
pentru a dezvolta o vizualizare localizată a unei rețele constante, fără bucle. Etichetăm modelul ca fiind
unul dintre eventualele consensuri din cauza întârzierilor de propagare a actualizărilor de accesibilitate,
inerente modelului planului de control distribuit în orice dincolo de o rețea de origine mică, formează un
grafic de rețea destul de complex. Prin proiectare, modelul este de nesincronizare intermitentă care ar
putea duce la căi de înaintare mai puțin optime, dar (sperăm) evitarea sau limitarea ciclurilor tranzitorii,
altfel cunoscute sub denumirea de micro -bucle în calea totală.
1.7. Planuri de control centralizate
Conceptul de plan de control centralizat nu este unic pentru mișcarea SDN. De fapt, modelul de control
distribuit există în parte, deoarece caracteristicile disponibile în bazele de date mai recent de zvoltate nu

22
existau. Astfel, a fost dificil să se realizeze sincronizarea fiabilă necesară pentru disponibilitate ridicată
și consecvență garantată între două sau mai multe puncte de control.
Avantajul principal al unui plan de control centralizat este pri virea de ansamblu a rețelei pe care o poate
oferi unei aplicații și simplificarea controlului programatic. Pentru a realiza o schimbare într-o rețea
mare, aplicația nu mai trebuie să cunoască sau să atingă direct elementele individuale, ci interacționează
în schimb cu câteva puncte de control care au grijă de aceste detalii. Deși nu sunt soluții SDN, există
unele modele actuale și istorice de centralizare parțială sau totală, în special serverul de rută din domeniul
IP și controlerul comutatorului ATM

23
Capitolul 2
2. Openflow
OpenFlow a fost inițial imaginat și implementat ca parte a cercetării în rețea la Universitatea Stanford.
Obiectivul său inițial a fost acela de a permite crearea de protocoale experimentale în rețelele de campus
care ar putea fi utilizate pentru cercetare și experimentare. Inainte de asta, universitățile au trebuit să -și
creeze de la zero propriile lor platforme de experimentare. Ceea ce a evoluat din acest nucleu inițial al
unei idei a fost viziunea că OpenFlow ar putea înlocui funcționalitatea protocoalelor stratului 2 și stratului
3 complet în comutatoare și routere comerciale. Această abordare este de obicei denumită propoziția cu
ardezie curată. [10]
Open Networking Foundation (ONF) a fost format dintr -un grup de furn izori de servicii pentru a
comercializa, standardiza și promova utilizarea OpenFlow în rețelele de producție. ONF este un nou tip
de Organizare pentru Dezvoltarea Standardelor, prin faptul că are un departament de marketing foarte
activ, care este utilizat pentru promovarea protocolului OpenFlow și a altor eforturi legate de SDN.
Componentele cheie ale modelului OpenFlow, așa cum se arată în figura 2.1 de mai jos , au devenit cel
puțin o parte a definiț iei comune a SDN, în principal [1]:
 Separarea planurilor de control și a datelor (în cazul ONF, planul de control este gestionat pe un
sistem de control centralizat logic).
 Utilizarea unui protocol standard între controler și un agent de pe elementul de rețea pentru starea
de instantanare (în cazul OpenFlow, de redirecționare).
 Asigurarea programabilității rețelei dintr -o vizualizare centralizată printr -o API modernă și
extensibilă.
Figura de mai jos prezintă arhitectură OpenFlow (având în vedere că unele dintre aplicațiile de plan
de control vor merge în partea de sus a controlerului – emulând comportamentul aplicațiilor tradiționale
de plan de control)

24

Figura 2.1 . Componentele cheie ale modelului OpenFlow

OpenFlow este un set de protocoale și un API, nu un produs în sine sau chiar o caracteristică
unică a un ui produs. Altfel spus, controlerul nu face nimic fără un program de aplicație (eventual mai
mult de unul) dând instrucțiuni despre fluxurile care merg pe ce elemente (din propriile motive)
În prezent, protocoalele OpenFlow sunt împărțite în două părți:
 Un protocol de sârmă (actualmente versiunea 1.3.x) pentru stabilirea unei sesiuni de control,
definirea unei structuri de mesaje pentru schimbul modificărilor fluxului (fluxmods) și colectarea
statisticilor și definirea structurii fundamentale a unui switch (porturi și tabele) Versiunea 1.1 a
adăugat capacitatea de a suporta mai multe tabele, executarea acțiunilor stocate și trecerea
metadatelor – creând în cele din urmă procesarea logică a conductelor într -un comutator pentru
gestionarea fluxurilor.

25
 Un proto col de configurare și de gestionare, de configurare (actualmente versiunea 1.1) bazat pe
NETCONF pentru a aloca porturi de comutare fizică unui anumit controler, pentru a defini
disponibilitate ridicată (activ / standby) și comportamente la defectarea cone xiunii controlerului.
Deși OpenFlow poate configura operația de bază a comenzii / controlului OpenFlow, nu poate
(încă) porni sau întreține un element.
Protocoalele OpenFlow nu furnizează direct „felierea” rețelei (o caracteristică atractivă care permite
capacitatea de a împărți un element în grupuri de porturi controlate separat sau o rețea în domenii
administrative separate). Cu toate acestea, instrumente precum FlowVisor (care acționează ca un proxy
transparent între mai multe controlere și elemente) și implementări specifice ale furnizorilor (agenți care
permit crearea mai multor comutatoare virtuale cu sesiuni de control separate) fac acest lucru posibil. [2]

2.1. Protocol de sârmă

Întrebarea cea mai importantă este: ce anume aduce Openflow în plus fa ță de ce știm deja?
În primul rând, introduce conceptul de înlocuire a stării efemere (intrările de flux nu sunt stocate în
stocare permanentă pe elementul de rețea) pentru semantica rigidă și neacordată a configurației
protocolului diferițilot furnizori. De asemenea, starea efemeră ocolește modelele mai lente de configurare
ale unor încercări anterioare de automatizare a rețelei.
Pentru majoritatea inginerilor de rețea, rezultatul final al unei astfel de configurații este crearea unei
stări de redirecționa re (deși distribuite și învățate într -un mediu de control distribuit). De fapt, pentru
mulți, testul configurației corecte constă în verificarea stării de redirecționare (examinarea tabelelor de
rutare, de redirecționare sau de legătură). Desigur, acest lu cru transferă o parte din povara de gestionare
la controlorul (controlerele) – cel puțin menținerea acestei stări (dacă dorim să fim proactivi și să avem
întotdeauna anumite reguli de redirecționare în tabelul de expediere) față de gestionarea distribuită a
strofelor de configurare pe elementele de rețea.
În al doilea rând, într -o intrare de flux OpenFlow, întregul antet de pachete (cel puțin straturile 2 și
câmpurile de strat 3) sunt disponibile pentru acțiuni de potrivire și modificare, așa cum se arată î n figura
2.1. Multe dintre provocări pot fi mascate. Acestea au evoluat de -a lungul diferitelor versiuni ale
OpenFlow. Figura 3 -2 ilustrează complexitatea implementării funcționalității de rediecționare L2 + L3
+ ACL (cu următoarea abstractizare a saltului pentru convergență rapidă) poate fi. Combinația de
primitive suportate de la tabel la tabel duce la o combinație foarte largă de contingențe de suport.

26

Figura 2.1 . Primitive OpenFlow (sârma) versiunea 1.0 [1]

Aceasta este o diferență izbitoare în lățim ea controlului operatorului în comparație cu modelul IP /
MPLS distribuit (OpenFlow are un spațiu de chibrituri de 11 tuple). O listă scurtă de posibilități include:
 Datorită capacității de mascare din instrucțiunile de potrivire, rețeaua poate imita
compo rtamentul de redirecționare a destinației IP.
 Atât la nivelul 2 cât și la nivelul 3, rețeaua poate prezenta un comportament de rutare sursă /
destinație.
 Nu există un echivalent standardizat (în prezent) la punctele tari de potrivire a pachetelor de
OpenFl ow, ceea ce îl face un substitut foarte puternic pentru rutare bazată pe politici sau alte
mecanisme de potrivire / direcționare în mediul de control distribuit.
În cele din urmă, există promisiunea acțiunii de modificare. Conceptul inițial a fost acela că
comutatorul (prin intermediul unei aplicații care rulează deasupra comutatorului) poate fi făcut să se
comporte ca un aparat de servicii, efectuând servicii precum NAT sau firewall). Indiferent dacă acest
lucru este sau nu realizabil în sistemele de redir ecționare bazate pe hardware, această capacitate depinde

27
în mare măsură de implementarea furnizorului (instrucțiunile acceptate, comanda acestora și numărul
bugetat de operațiuni pentru a menține performanța ratei de linie). Cu toate acestea, cu acțiunile de
manipulare a etichetelor adăugate la versiunea 1.3 a protocolului de sârmă, este posibil ca un element
controlat Open -Flow să poată emula cu ușurință comportamente integrate de platformă precum un MPLS
LSR (sau alte funcții tradiționale ale platformei d istribuite).
Protocolul OpenFlow este extensibil printr -o extensie EXPERIMENTER (care poate fi publică
sau privată) pentru mesaje de control, câmpuri de potrivire a fluxului, funcționare contor, statistici și
extensii specifice furnizorului (care pot fi pu blice sau private).
Înregistrările din tabel pot fi stabilite cu prioritate (în cazul înregistrărilor care se suprapun) și au
o scadență cronologică (economisirea operațiunii de curățare în unele cazuri și setarea unei eficiențe cu
scădere mortală pentru f luxurile într -unul dintre scenariile de pierdere a controlorului).
OpenFlow acceptă tipurile de porturi FIZICE, LOGICE și RESERVATE. Aceste porturi sunt
utilizate ca structuri de intrare, de ieșire sau bidirecționale.
Porturile RESERVED IN_PORT și ANY sunt explicative de la sine
TABLE a fost necesară pentru a crea o conductă multificată (OpenFlow acceptă până la 255 de
tabele netratate cu comandă GoTo arbitrară).
Porturile rezervate rămase permit comportamente importante (și interesante)
LOCAL
Un port exclu siv de ieșire (egress), acest port logic permite aplicațiilor OpenFlow porturi de acces
(și deci procese) ale sistemului de operare gazdă element.
NORMAL
Un port exclusiv de ieșire (egress), acest port logic permite comutatorului să funcționeze ca un
comutator Ethernet tradițional (cu comportamente de inundare / învățare asociate). Conform
specificațiilor funcționale ale protocolului, acest port este acceptat doar de un comutator hibrid
FLOOD
Un port exclusiv egress, acest port logic folosește motorul de replicare al elementului de rețea
pentru a trimite pachetul toate porturile standard (nerezervate). FLOOD diferă de TOATE (un alt port

28
rezervat) prin faptul că ALL include portul de intrare. FLOOD folosește motorul de replicare a pachetelor
de elemente.
CONTROLER
Permite regula fluxului să redirecționeze pachetele (peste canalul de control) de la calea de date
către controler (și invers). Aceasta permite comportamentul PACKET_IN și PACKET_OUT.
Paradigma de redirecționare oferă două moduri: proactiv (pre -furnizat) și reactiv (plan de date
condus). În modul proactiv, programul de control plasează înregistrările de retrimitere înaintea cererii.
Dacă fluxul nu se potrivește cu o intrare existentă, operatorul are două opțiuni (globale) – să renunțe la
flux sau s ă utilizeze opțiunea PACKET_IN pentru a lua o decizie de a crea o intrare de flux care să se
încadreze în pachet (cu o poziție pozitivă / înainte sau negativ / dispoziție) – în modul reactiv. [1]
Canalul de control a fost specificat inițial ca o sesiune TCP simetrică (securizată potențial de
TLS). Acest canal este utilizat pentru a configura, gestiona (plasa fluxuri, colecta evenimente și statistici)
și oferă calea pentru pachetele de la comutator la și de la controler / aplicații.
Asistența statistică acope ră fluxul, agregat ul, tabel ul, port ul, coada și counterii specifici
furnizorilor.
În versiunea 1.3 a protocolului, sunt permise mai multe conexiuni auxiliare (TCP, UDP, TLS sau
DTLS) care sunt capabile să gestioneze orice tip sau subtip de mesaj OpenFlow. Nu există nicio garanție
a comenzii pe canalele UDP și DTLS (Datagram TLS) , iar ghidul comportamental este stabilit în ghidul
de sarcini pentru a asigura operațiunile specifice pachetului că sunt simetrice (pentru a evita problemele
de comandă la controler )
OpenFlow acceptă mesajul BARRIER pentru a crea un mecanism de stimulare (crearea de
atomicitate sau controlul fluxului) pentru cazurile în care pot exista dependențe între mesajele ulterioare
(exemplul dat este o operație PACKET_OUT care necesită o primă plasare a fluxului pentru a se potrivi
cu pachetul care permite redirecționarea).
2.2 Replicare
OpenFlow oferă mai multe mecanisme pentru replicarea pachetelor.
Porturile virtuale ANY și FLOOD rezervate sunt utilizate în principal pentru a emula / susține
comportamentele protocoalelor existente (de exemplu, LLDP, folosit pentru a colecta topologia pentru
controler, folosește adesea FLOOD ca port de ieșire).

29
Tabelele de grup permit gruparea porturilor într -un set de porturi de ieșire pentru a suporta
multic asting, multipath, indirection și rapid -failover. Fiecare tabelă de grup este, în esență, o listă de
„găleți ” de acțiune (în care în mod evident se realizează una dintre acțiuni și este indicat un port de
ieșire). Există patru tipuri de tabele de grup, dar sunt necesare doar două:
All (Toate)
Folosit pentru multicast, toate „gălețile ’’ de acțiune din listă trebuie să fie executate
Indirect
Se folosește pentru a simula următorul comportament de convergență hop în redirecționarea IP
pentru o convergență ma i rapidă
Listele de acțiuni din acțiunea Aplicați (acțiunea Aplicare a fost un singleton în versiunea 1.0
OpenFlow) permit replici succesive prin crearea utilizării unei liste de acțiuni de ieșire / port.

2.3. FAWG (Forwarding Abstraction Workgroup)
Model ul pentru un comutator OpenFlow (Figura 3 -3) funcționează bine pe un comutator bazat
pe software (caracteristici eminamente flexibile la scară și caracteristici de manipulare a pachetelor)
sau la o entitate care execută hardware care se conformează unor pr esupuneri simplificatoare (de
exemplu, mari, largi, profunde și amintiri cu mai mulți participanți , precum TCAM ). Dar, deoarece nu
toate dispozitivele sunt construite în acest fel, există o mulțime de variații în suportul tuturor
manipulărilor de pachete a ctivate de setul de primitive OpenFlow, mai multe tabele și alte aspecte care
oferă OpenFlow întreaga sa lățime și putere.

Figura 2. 3. Modelul de redirecționare OpenFlow 1.0 (model de masă partajat foarte simplu)

30

31
Capitolul 3
3. Controller -ul SDN
3.1 Introducere
Cele mai rezonante trei concepte ale SDN sunt programabilitatea, separarea planurilor de control
și date și gestionarea stării efemere a rețelei într -un model de control centralizat, indiferent de gradul de
centralizare. În cele din urmă, aceste concepte sunt încorporate într -un cadru SDN idealizat. Controlerul
SDN este întruchiparea cadrului idealizat SDN și, în cele mai multe cazur i, este o reflectare a cadrului.
În teorie, un controler SDN oferă servicii care pot reali za un plan de control distribuit, precum și să
abordeze conceptele stării efemere de gestionare și de centralizare. În realitate, orice instanță dată unui
controller va oferi o „felie” sau subset din această funcționalitate, precum și asumarea proprie a ac estor
concepte. În acest capitol, vom menționa cele mai populare oferte de controlere SDN atât de la furnizorii
comerciali, cât și din comunitatea open source și vom discuta despre controller -ul folosit în această
lucrare. Am o parte de text care compară t ipul controlerului din text cu v iziunea ideală a unui controler.
Descrierea generală a unui controller SDN este un sistem software sau o colecție de sisteme care
furnizează împreună [4]:
 Gestionarea stării de rețea și, în unele cazuri, gestionarea și distr ibuția acestei stări, poate implica
o bază de date. Aceste baze de date servesc ca un depozit pentru informațiile derivate din
elementele de rețea controlate și software -ul aferent, precum și informațiile controlate de
aplicațiile SDN, inclusiv starea rețe lei, unele informații de configurare efemere, topologia
învățată și i nformațiile sesiunii de control . În unele cazuri, controlerul poate avea mai multe
procese de gestionare a datelor bazate pe scopuri (de exemplu, baze de date relaționale și
nerelaționale ). În alte cazuri, pot fi folosite și alte strategii de baze de date în memorie.
 Un model de date la nivel înalt care surprinde relațiile dintre resursele gestionate, politicile și alte
servicii furnizate de controler. În multe cazuri, aceste modele de dat e sunt construite folosind
limbajul de modelare Yang.
 O interfață de programare (API) modernă, adesea odihnitoare (transfer de stare reprezentativă)
este furnizată care expune serviciile controlerului la o aplicație. Acest lucru facilitează cea mai
mare pa rte a interacțiunii între controler și aplicație. Această interfață este redată ideal din
modelul de date care descrie serviciile și caracteristicile controlerului. În unele cazuri, controlerul
și API -ul său fac parte dintr -un mediu de dezvoltare care gene rează codul API din model. Unele

32
sisteme merg mai departe și oferă medii de dezvoltare solide care permit extinderea capabilităților
de bază și publicarea ulterioară a API -urilor pentru noi module, inclusiv cele care acceptă
extinderea dinamică a capabilit ăților controlerului .
 O sesiune de control TCP sigură între controler și agenții asociați din elementele rețelei .
 Un protocol bazat pe standarde pentru furnizarea stării de rețea bazate pe aplicații pe elemente de
rețea .
 Un mecanism, topologie și mecanism de descoperire a serviciilor; un sistem de calcul al căilor;
și, eventual, alte servicii de informare centrate pe rețea sau centrate pe resurse.
Peisajul actual al controlerelor include produsele comerciale ale VMware (vCloud / vSphere), Nicira
(NVP), NEC (Trema), Big Switch Networks (Floodlight / BNC) și Juniper / Contrail. De asemenea,
include o serie de controlere open source. [1]
Pe lângă utilizarea protocoalelor OpenFlow și a proprietăților, există controlere SDN care folosesc
funcționalitatea rețelei I P / MPLS pentru a crea VPN -uri MPLS ca model de separare a chiriașului cu 3
straturi peste 3 straturi pentru centrul de date sau LSP MPLS pentru suprapuneri în WAN.

3.2 Mininet
Înainte de a introduce unele dintre cele mai populare controlere SDN bazate pe Onix, ar trebui să
ne ocupăm de ceva timp pentru a descrie Mininet, care este un emulator de rețea care simulează o colecție
de gazde, switch -uri, routere și link -uri pe un singur kernel Linux. Fiecare dintre aceste elemente este
denumit „gazdă”. Utilizea ză virtualizarea ușoară pentru a face un singur sistem să pară o rețea completă,
care rulează același kernel, sistem și cod de utilizator. Mininet este important pentru comunitatea SDN
open source, deoarece este utilizat în mod obișnuit ca instrument de si mulare, verificare, testare și resursă.
Mininet este un proiect open source găzduit pe GitH ub [7].
O gazdă Mininet se comportă la fel ca o mașină reală și rulează în general același cod – sau cel
puțin poate. În acest fel, o gazdă Mininet reprezintă un she ll al unei mașini în care programele arbitrare
pot fi conectate și rulate. Aceste programe personalizate pot trimite, primi și prelucra pachete prin
intermediul a cee a ce programul pare a fi un Ethernet real, dar este de fapt un switch / interfață virtuală.
Pachetele sunt procesate de comutatoare virtuale, care pentru gazdele Mininet par a fi un adevărat
comutator sau router Ethernet, în funcție de modul în care sunt c onfigurate. De fapt, sunt disponibile
versiuni comerciale ale comutatoarelor Mininet, cum ar fi de la Cisco și altele, care imită destul de precis
caracteristicile comutatorilor cheie ale comutatoarelor lor comerciale, construite special, precum

33
adâncimea cozii, disciplina de procesare. Un efect secundar foarte interesant al acestei abordări este acela
că performanța măsurată a unei rețele găzduite de Mininet ar trebui să se apropie adesea de cea a
comutatoarelor, a router -urilor și a gazdelor reale (ne -emulate).
Figura 3.1 ilustrează o rețea Mininet simplă formată din trei gazde, un comutator virtual Open –
Flow și un controler OpenFlow. Toate componentele sunt conectate prin legături virtuale Ethernet cărora
li se atribuie adrese IP private net -10 pentru acc esabilitate. Așa cum am menționat, Mininet acceptă
topologii foarte complexe, cu o dimensiune și o comandă aproape arbitrare, astfel încât se poate, de
exemplu, copia și lipi switch -ul și gazdele sale atașate în configurație, să le redenumească și să atașe ze
noul switch la cel existent și rapid. au o rețea alcătuită din două comutatoare și șase gazde și așa mai
departe. [1]
Un motiv pentru care Mininet este utilizat pe scară largă pentru experimentare este că îmi permite
să creez topologii personalizate, mu lte dintre ele fiind demonstrate ca fiind destul de complexe și realiste,
cum ar fi topologii mai mari, de tip Internet, care pot fi utilizate pentru cercetarea BGP. O altă
caracteristică interesantă a Mininet este că permite personalizarea completă a redi recționării pachetelor.
După cum am menționat, există multe exemple de programe gazdă care aproximează comutatoarele
disponibile comercial. Pe lângă acestea, unele experimente noi și inovatoare au fost efectuate cu ajutorul
gazdelor programabile folosind p rotocolul OpenFlow.

Figura 3.1. Un exemplu simplu de rețea Mininet

34
3.3. Vmware
VMware oferă o soluție de orchestrare a centrelor de date cu un controler SDN și o implementare
a agentului, care a devenit un standard de facto. VMware a fost una dintre com paniile de geneză pentru
cloud computing, înființată în 1998. VMware oferă o suită de aplicații centrate pe setului de date
construite în jurul hypervisor -ului ESX (ESXi pentru versiunea 5.0 sau ulterioară) (și switch -ul
hypervisor, vSphere Distributed Sw itch [VDS]) ).
vSphere a introdus hypervisorul ESXi (cu versiunea 5.x) pentru a înlocui hypervisorul ESX mai
vechi, făcându -l mai ușor / mai mic (conform afirmațiilor de marketing; ESXi este 5% din dimensiunea
ESX) și independent de sistemul de operare. M odificarea adaugă, de asemenea, o interfață web la
opțiunile de gestionare ESX existente ale CLI, API -ului client și vizualizarea vCenter. De asemenea, a
eliminat un VM invitat necesar (adică, VM invitat pe gazdă) pentru o consolă de servicii pentru
admini strația locală.
VDS este o abstractizare (ca un singur switch logic) a ceea ce a fost anterior o colecție de
comutatoare virtuale individuale (vSphere Standard Switch / es) dintr -o perspectivă de gestionare – care
permite vCenter Server să acționeze ca un punct de management / control pentru toate instanțele VDS
(separând planurile de gestionare și date ale VSS individuale).
În cadrul VDS, VMware are abstractizări ale cardului fizic (vmnic), proprietăți ale legăturii (de
exemplu, asociere, reîncărcare și în cărcare a încărcăturii – dvuplink) și atribute de rețea (de exemplu,
alocare VLAN, modelare a traficului și securitate de facto dvportgroup). folosit de administrator ca
șabloane de configurare reutilizabile.
Odată furnizate, componentele necesare pentru f uncționarea rețelei (ESXi vswitch) vor continua
să funcționeze chiar dacă serverul vCenter eșuează / partiții din rețea.4 O mare parte din schema HA este
administrată în clustere organizaționale în care un singur agent este ales ca comandant al un domeniu
defect și celelalte sunt sclave. Acest lucru creează un sistem de monitorizare a sănătății VM foarte
scalabil, care tolerează partiția comunicării de management prin utilizarea bătăilor inimii prin intermediul
stocurilor de date partajate .

35
Capitolul 4
4. Prezentarea tool -urilor folosite

In acest capitol am prezentat descărcarea, instalarea și pregătirea maș inii virtuale cu Mininet ș i a
terminalului de lucru Mobaxtrem î n vederea creeării rețelei virtuale ș i modif icarea acesteia până la
subiectul propus inițial.

4.1 Oracle Virtual Box Manager

Oracle VirtualBox permite configurarea unei a sau mai multor mașini virtuale (VM) pe o singură
mașină fizică și se pot utiliza simultan, împreună cu mașina actuală. Fiecare mașină virtuală își poate
executa propriu l sistem de operare, inclusiv versiuni de Microsoft Windows, Linux, BSD și MS -DOS.
Aici am folosit o mașină Virtuală cu Mininet care are ca siste m de operare Ubuntu (32 – bit), descărcat
de pe site -ul oficial https://www.virtualbox.org/ [6].

Figura 4.1 . Oracle Virtual Box Manager

36
4.2. Mininet

Mininet este un emulator de rețea care creează o rețea de gazde virtuale, comutatoare, controlere și
legături. Gazdele Mininet rulează software de rețea Linux standard, iar comutatoarele sale susține
OpenFlow pentru rutare personalizată extrem de flexibilă și rețea definită prin software. [7]
Mininet acceptă cercetarea, dezvoltarea, învățarea, prototiparea, testarea, depanarea și orice alte
sarcini care ar putea beneficia de existența unei rețele experimentale complete pe un laptop sau pe alt
computer.
Mininet oferă o rețea de testare simplă și ieftină pentru dezvoltarea aplicațiilor OpenFlow. Este ușor
de instalat și oferă multe avantaje față de alte sisteme virtuale, p recum și bootarea mai rapidă (cateva
secunde) , lățimea de banda ș i altele.
OpenFlow (OF) este considerat unul dintre primele standarde de rețea definite de software (SDN).
Inițial, a definit protocolul de comunicare în mediile SDN care permite controlorulu i SDN să
interacționeze direct cu planul de redirecționare a dispozitivelor de rețea, cum ar fi switch -uri și routere,
atât fizice cât și virtuale (bazate pe hipervisor), astfel încât să se poată adapta mai bine la schimbarea
cerințelor de afaceri. Un cont roler SDN este “creierul” rețelei care transmite informații pentru
comutatoare/ routere și aplicații.
Descarcare Mininet 2.2.2 pe Ubuntu 14.04 LTS – 32 biți, deoarece este recomandat pentru aceasta
lucrare în care sistemul de operare este un Windows care utilizează VirtualBox. Hardware -ul folosit este
un laptop cu cu sistemul de operare Windows 2010

Figura 4.2 . Manager Virtual Box – oțiunea de import

37

Apoi, se dă Import Appliance – Selectare fiș ierul minin et descă rcat

Figura 4.3 . Import mininet

Figura 4.4 . Mașina Virtuală instalată

38
În partea dreaptă din figura 4.4 de mai sus, se observă mașina virtuală creată împreună cu detaliile
necesare . După instalare se apasă pe start pentru a porni. Din diverse motive, precum dimens iunile reduse
ale terminal ului ș i altele, am optat pentru instala rea unui server separat, Mobaxtrem, p entru windows cu
terminal SSH, î n special.

4.3. Mobaxtrem

Figura 4.5 . Mobaxtrem [9]

Mobaxtrem Home Edition v11.1 a fost descarcat de pe site -ul oficial urmator
https://mobaxterm.mobatek.net/download -home -edition.html [9]

MobaXterm este un instrument pentru accesare a computer -ului la distanță. Într -o singură aplicație
Windows, furnizează o mulțime de func ții adaptate pentru programatori, webmasteri, administratorii IT
și aproape toți utilizatorii care trebuie să se ocupe de lucrările de la dist anță într -o manieră mai simplă.
Moba Xterm oferă toate instrumentele importante de rețea la distanță (SSH, X11, RDP , VNC,
FTP, MOSH, …) și comenzile Unix (bash, ls, cat, sed, grep, awk, rsync, …) pentru desktopul Windows ,
într-un singur fișier exe portabil.

4.4. Legatura din tre mașină virtuală ș i terminalul Mobaxtrem

După deschiderea mașinii virtuale prin apă sarea but onului “Start”, se va desc hide terminalul
propriu. Credenț ialele de logare sunt urmă toarele – user: mininet, parola: mininet.

39

Figura 4.6 . Mașina virtuala în modul de funcționare

După logare este necesară aflarea IP -ului de reț ea internet pentru a crea o sesiune SSH pe
terminalul Mobaxterm , prezentat î n figura 4.7 de mai jos. În urma comenzii „ifconfig” î n terminal,
rezultatul IP -ului este 192.168.0.103.
SSH, cunoscut și sub numele de Secure Shell sau Secure Socket Shell, este un protocol de rețea
care oferă utilizatorilor, în special administratorilor de sistem, o modalitate sigură de a accesa computerul
printr -o rețea nesecurizată. SSH se referă, de asemenea, la suita de utilități care implementează protocolul
SSH. Secure Shell oferă o autentificar e puternică și comunicații de date criptate între două computere
care se conectează printr -o rețea deschisă, cum ar fi internetul. SSH este utilizat pe scară largă de
administratorii de rețea pentru gestionarea sistemelor și aplicațiilor de la distanță, pe rmițându -le să se
conecteze la un alt computer printr -o rețea, să execute comenzi și să mute fișierele de la un computer la
altul.

40

Figura 4.7 . Comanda ifconfig pentur aflarea IP -ului

Figura 4.8 . Configurare sesiune SSH Mobaxterm

Figura 4.8 de mai sus , reprezintă creea rea unei sesiuni SSH cu IP -ul găsit î n terminalul maș inii
virtuale: 192.168.0.103. Logarea î n acest terminal se face cu aceleași credențiale. După toți acești pași
am început dez voltarea subiectului prezentat în această lucrare.

41
Conectarea la adresa eth0 se poate face și prin fara a crea o sesiune ssh, ci direct prin conexiunea la
aceasta, ca exemplu am scris comanda urmatoare:
ssh -X mininet@172.20.10.11

Figura 4.9 Logare Mobaxterm

4.5. Flowvisor
FlowVisor este un controler de rețea definit prin software (SDN) care permite virtualizarea rețelei
prin împărțirea unei rețele fizice în mai multe rețele logice. FlowVisor se asigură că fiecare controler
atinge doar comutatoarele și resursele alocate acestuia. De asemenea, partiționează lăți mea de bandă și
resursele tabelului de flux de pe fiecare comutator și atribuie aceste par tiții controlerelor individuale [7].
FlowVisor face o rețea fizică în unități abstracte de lățime de bandă, topologie, trafic și unități
centrale de procesare a dispo zitivelor de rețea (CPU). Funcționează ca un controlor proxy transparent
între comutatoarele fizice ale unei rețele OpenFlow și alte controlere OpenFlow și permite mai multor
controlere să opereze aceeași infrastructură fizică, la fel ca un hipervizor de s erver care permite mai
multor sisteme de operare să utilizeze același hardware bazat pe x86. Alte controlere standard OpenFlow
operează apoi propriile felii de rețea individuale prin proxy -ul FlowVisor. Acest aranjament permite mai
multor controlere OpenFl ow să ruleze rețele virtuale pe aceeași infrastructură fizică.

42
FlowVisor este un controler de scop special pentru rețele OpenFlow.
Am instalat Java prin comanda urmatoare
sudo apt -get install build -essential sun -java6 -jdk ant eclipse
Descărcarea ș i rularea executabilului
$ git clone git://github.com/OPENNETWORKINGLAB/flowvisor.git
$ cd flowvisor
$ make
Instalarea FlowVisor
FlowVisor nu ar trebui să funcționeze ca root pentru probleme de securitate evidente. Prin urmare,
cele mai bune practici sunt crearea u nui utilizator FlowVisor. În scopul acestui document, vom folosi
numele de detector de nume și fluxul de grup și să presupunem c ă utilizatorul și grupul există [7].
sudo make fvuser=flowvisor fvgroup=flowvisor install
Dar user -ul flowvisor nu există, așa c ă mai întâi trebuie să creeăm un user prin comanda urmatoare:
$ sudo adduser flowvisor
Aceasta a instalat sistemul de control în /usr / local
Pentru a vedea grupurile la care este alocat contul curent de utilizator am folosit comanda
urmatorare
mininet@min inet-vm:~$ groups flowvisor
flowvisor : flowvisor
mininet@mininet -vm:~$

Running FlowVisor
FlowVisor poate fi rulat fie la linia de comandă, fie la scriptul de inițializare furnizat (și instalat).
sudo -u flowvisor flowvisor
Actualizarea FlowVisor
Când fac eți upgrade, FlowVisor poate actualiza structura bazei sale de date interne. Prin urmare, este
importantă salvarea fișierul de configurare înainte de actualizarea, executând:
fvctl dumpConfig config.json , iar apoi comanda
fvctl save -config config.json

43
Capi tolul 5
5. Implementarea topologiilor

5.1. Mininet
Pentru o înțelegere mai bună a Mininet -ului am rulat câteva exemple de exerciții. Pentru început am
rulat o comandă în care am creat o topologie și am executat cu succes un test de ping , între gazde. Acest
exemplu îl voi exemplifica mai jos.

mininet@mininet -vm:~$ sudo -n mn –test pingall

Figura 5.1. 1. Test de ping pentru o topologie standard

44

Comanda sudo mn creează o topologie existentă în mod implicit, minimă, standard cu 2 host –
uri, 2 switch -uri și un co ntroller, pe care am descris -o mai jos. În figura 5.2, am exemplificat o schemă
grafică, pentru o privire de ansamblu.

Figura 5. 1.2. Topologie standard cu 2 switch -uri și 2 host -uri

mininet@mininet -vm:~$ sudo mn
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1)
*** Configuring hosts
h1 h2
*** Starting controller
c0
*** Starting 1 switches
s1 …
*** Starting CLI:
mininet>

45
5.1.1. Interacțiunea între gazde și switc h-uri
Topologia standard, minimă cu de mai sus și automat a deschis linia de comandă (CLI) , unde
am încercat să aflu cât mai multe lucruri posibile despre această rețea, precum nodurile, detalii despre
ip-urile implicate, link -urile create între noduri.

mininet> nodes
available nodes are:
c0 h1 h2 s1

mininet> dump
<Host h1: h1 -eth0:10.0.0.1 pid=29969>
<Host h2: h2 -eth0:10.0.0.2 pid=29971>
<OVSSwitch s1: lo:127.0.0.1,s1 -eth1:None,s1 -eth2:None pid=29976>
<Controller c0: 127.0.0.1:6653 pid=29962>

mininet> n et
h1 h1-eth0:s1-eth1
h2 h2-eth0:s1-eth2
s1 lo: s1 -eth1:h1-eth0 s1-eth2:h2-eth0
c0
mininet>

5.1.2. Testarea conectivității dintre gazde
mininet> h1 ping h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=2.43 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.472 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.053 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.047 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=0.048 ms
^C
– 10.0.0.2 ping statist ics –
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 0.047/0.610/2.433/0.926 ms
mininet>

Cu CTRL + C se oprește sesiunea de ping.
Primul ping a durat mai mult decât celelalte două. Să ne amintim că este o rețea SD N folosind
Openflow. În primul pachet al oricărui flux, switch -ul trebuie să anunțe controlorul SDN în așteptarea
unei răspuns cu ce acțiu ni are de făcut cu acel pachet. Se poate vedea o latență suplimentară pentru
primul pachet, din cauza comunicării cu c ontrolerul. După primul mesaj de timp ICMP și răspuns,
fluxurile sunt salvate de comutator pentru o perioadă limitată de timp. Deci restul pachetelor nu trebuie
să fie verificate de controlerul SDN și nu au acea latență suplimentară.

46
O modalitate mai ușoa ră de a rula acest test este comanda Mininet CLI, pingall , care
realizează un ping între toate gazdele existente.

5.1.3. Executarea unui test de regresie
Un alt test util este iperf . Această comandă a rulat un server iperf pe o gazdă, a rulat un client
iperf pe a doua gazdă și a analizat lățimea de bandă TCP obținută , iar pentru UDP, avem comanda
iperfudp . După cateva secunde avem și rezultatul.

mininet> iperf
*** Iperf: testing TCP bandwidth between h1 and h2
.*** Results: ['26.8 Gbits/sec', '26.8 Gbits/ sec']
mininet>

mininet> iperfudp
*** Iperf: testing UDP bandwidth between h1 and h2
*** Results: ['10M', '10.0 Mbits/sec', '10.0 Mbits/sec']
mininet>

5.1.4. Adăugarea latenței în rețeaua Mininet
mininet> exit
Prima comandă este de ieșire din reșeaua Mini net. Acesta este un moment bun pentru a preciza
ca de fiecare dată când se iese din Mininet, este bine să rulez sudo mn -c, pentru a face o curațenie și a
închide orice proces agațat.
mininet@mininet -vm:~$ sudo mn –link tc,bw=15,delay=10ms

Figura 5. 1.3. Introducerea latenței și a lungimii de bandă

47
Cum mă așteptam, link -urile sunt de 15 Mbit/s și întarzierea artificiala introdusa este de 10 ms
pe fiecare sens. Dacă rulez din nou iperf, voi avea un alt rezultat , o lațime de bandă limitată .
mininet> iperf
*** Iperf: testing TCP bandwidth between h1 and h2
*** Results: ['14.1 Mbits/sec', '16.1 Mbits/sec']
mininet>

Propun să analizez schimbul de pachete cu programul Wireshark. Wireshark este deja instalat în
această mașina virtuală. Pentru a îl lansa, trebui e să deschid o a doua sesiune SSH. Voi folosi comanda
cu „&” la final pentru a rula procesul pe fundal.
$ sudo wireshark &
Voi incepe prin a face o captură pe interfața Loopback0.

Figura 5. 1.4. Captura pe interfața lo

Aplic un filtru pentru openflow, p entru a vedea doar pachetele Openflow, cum se observă în
imaginea de mai jos. Momentan sunt doar pachete de echo reply dintre controler și switch .

48

Figura 5. 1.5. Pachete de echo reply

În continuare am încercat un pingall pentru a vedea cateva pachete mai interesante și am
oprit captura wireshark pentru a analiza. Observ câteva pachete ale protocolului Openflow, alte pachete
cu mesaje de la switch la controler și câteva mesaje modificate de flux de la controler înapoi la switch .

Figura 5. 1.6. Pachete ca pturate după pingall

Înainte de a intra în detalii despre tipul de pachete și de informațiile pe care le conține, as vrea
să arat și alte tipuri de topologii, împreuna cu comenzile de bază.
$ sudo mn –topo=single,4 – Este acceași topologie ca mai devreme , dar de data aceasta
avem 4 gazde și un sin gur controler, ca în figura 5.7

49

Figura 5.1.7. Reprezentarea grafic a a rețelei cu 4 gazde [5]

Daca dorim o topologie liniara, vom avea rezultatul a 4 switch -uri, fiecare cu câte o gazdă.
$ sudo mn –topo=linear,4

Figura 5. 1.8. Reprezentarea grafică a rețelei cu 4 switch -uri, fiecare cu cate o gazdă

Iar în figura 5.9, este prezentată o topologie de tipul arbore cu 2 niveluri de switch -uri și 2 gazde
$ sudo mn –topo=tree,2,2

50

Figura 5.1.9. Reprezenta rea grafică a rețelei cu 2 nivele de switch -uri și 2 gazde [5]

De asemenea se poate contrui o topologie mult mai mare, dar aceasta necesită un consum mare
de resurse pentru creare, atât a timpului, cât și a memoriei RAM alocate. Un exemplu concret se poat e
vedea în imaginile urmatoare :

Figura 5. 1.10. Încărcarea procesorului la rularea unei topologii mai mari

După comanda $ sudo mn –topo=tree,2,10 , care înseamnă o topologie de tipul arbore, cu 2
nivele în adâncime și 10 gazde pentru fiecare din cele 10 switch -uri care se leaga la switch -ul 1.
Încar carea procesorului este de 100%,iar c a și memorie RAM 023 GB din 0,99 GB sunt utilizați.

51
5.1.5. Topologii personalizate

Topologiile personalizate pot fi, de asemenea, ușor definite, folosind API -ul Python, iar un
exemplu este furnizat în mininet/ custom/ topo -2sw-2host.py. Acest exemplu conectează două
comutatoare direct, cu o singură gazdă oprită pentru fiecare comutator. Un exemplu de cod se află în
anexa 1, la finalul acestei lucrări, dar voi menționa cat eva comanzi esențiale.
leftHost = self.addHost( 'h1' ) – Adăugarea unei gazde
rightSwitch = self.addSwitch( 's4' ) – Adăugarea unui switch
self.addLink( left Host, leftSwitch ) – Crearea unei legături între gazdă stângă și
switch -ul stâng
Când e ste furnizat un fișier mininet personalizat, acesta poate adăuga noi topologii, tipuri de
comutatoare și teste pe linia de comandă. De exemplu:
$ sudo mn –custom ~/mininet/custom/topo -2sw-2host.py –topo mytopo –test pingall

În mod implicit, gazdele înc ep cu adrese MAC alocate aleatoriu. Acest lucru poate face ca
depanarea să fie dură, deoarece de fiecare dată când Mininet este creat, MAC -urile se schimbă, deci
corelarea traficului de control cu gazdele specifice este dificilă.
Opțiunea –mac este super -utilă și stabilește adaosurile MAC și IP gazdă la ID -uri mici, unice,
ușor de citit.

Figura 5. 1.11. Înainte de sudo mn –mac

Figura 5. 1.12. După sudo mn –mac

52
5.1.6. Utilizarea unui controler “la distanță”

Este util în primul rând dacă aveți un contro ler care rulează în afara VM -ului, cum ar fi pe gazda
VM sau un alt computer fizic. Tutorialul OpenFlow folosește controller –remote pentru a porni un
comutator de învățare simplu pe care îl creați folosind un cadru de controlor precum POX, NOX, Beacon
sau Floodlight.
Când porniți o rețea Mininet, fiecare c omutator poate fi conectat la un controller “la distanță ”
care ar putea fi în VM, în afara VM și pe mașina locală sau oriunde în lume.
De exemplu, pentru a rula o mostră din controlerele de învățare POX , se poate da comanda
urmatoare într-o ferea stră.
$ cd ~/pox
$ ./pox.py forwarding.l2_learning
POX 0.2.0 (carp) / Copyright 2011 -2013 James McCauley, et al.
INFO:core:POX 0.2.0 (carp) is up
INFO:openflow.of_01:[00 -00-00-00-00-01 1] connected

În altă ferea stră am pornit Mininet -ul pentru a mă conecta la controlerul “ la dist anță” (care rulează
de fapt local, dar în afara controlului lui Mininet)
$ sudo mn –controller=remote,ip=127.0.0.1,port=6633
Acestea sunt de fapt adresa IP și valorile portului implicite .
Dacă generez un pic de trafic (de exemplu, h1 ping h2 ), ar trebui să pot observa o ieșire în
fereastra POX, arătând că switch -ul a fost conectat și că au fost instalate unele intrări din tabelul de flux.
O serie de cadre de control OpenFlow sunt disponib ile și ar trebui să funcționeze ușor cu Mininet,
atât timp cât le pornesc și specific opțiunea controlerului cu adresa IP corectă a mașinii în care rulează
controlerul și po rtul corect pe care îl ascultă.

53
5.2. Funcționarea Openflow -ului

Pentru a înțelege Openflow, am ales un exemplu cu un switch s1, un controler Openflow și 4
gazde. Voi urmări un server web simplu pe gazda h4 și voi face o solicitare HTTP de la gazda h1. Apoi
voi analiza traseul pachetelor,a ceea ce se întâmplă în această rețea Op enflow pachetele capturate din
wireshark.
Folosesc mininet pentru a emula această rețea. Voi crea topologia mea cu comanda:
sudo mn –tapo=single, 4 . Pe gazda h4, voi lansa un server web phyton simplu pe portul 80. Acest
lucru a r trebui să funcționeze ca un proces de fundal
h4 phyton -m SimpleHTTP Server 80 & .
Așa că voi face o cerere http de la h1 pe serverul web simplu din h4
h1 wget 10.0.0.4 . Trecând la wireshark, oprim această captare.
Să analizăm ce se va întâmpla când vom face cererea HTTP de la h1 la h4. Deoarece este TCP,
începe întotdeauna cu un mesaj de sincronizare. Dacă acesta ar fi un comutator tradițional, pachetul va
fi redirecționat în h4 pe baza știrii unde se află adresa mac a gazdei h4. Însă, acesta este un swi tch
Openflow, s1 va verifica în tabela sa, etichetele de flux local. Deoarece acesta este primul pachet al
fluxului, probabil că nu are o intrare de flux care să se potrivească cu aceast pachet. De obicei, atunci
când nu există fluxuri de potrivire, acțiun ea implicită este de a trimite aceast pachet către controler. S1
va trimite un mesaj Pachet -IN controlerului. Pachet -IN incapsulează mesajul original TCP SYN din
interiorul lui. Acesta ar putea include întregul pachet sau ar putea include doar unele dintre anteturile
pachetului și cu referință unui Buffer -ID. Atunci când se utilizează un Buffer ID, switch -ul stochează
întregul pachet, iar controlorul mai târziu poate instrui switch -ul ce trebuie să facă cu el.
Controlerul poate trimite un mesaj Packet -Out ș i / sau un mesaj de modificare a fluxului înapoi la
switch. Un mesaj Packet -OUT este o instrucțiune de la controler către switch cu ce să facă cu acest pachet
specific. Poate conține un pachet încapsulat complet sau ar putea face referire la un Buffere – ID al
pachetului pe care îl stochează switch -ul.

54

Figura 5.2.1 . Pachet -IN/OUT

În mod alternativ, controlerul poate trimite și un mesaj de modificare a fluxului. Acest mesaj
indică switch -ului să instaleze o nouă intrare a fluxului în tabelele sale de flux . Înregistrările de flux
permit switch -ului să știe ce să facă atunci când viitoare pachete similare au ajuns la el.
Un mesaj de modificare de flux poate conține urmatoarea acțiune : orice solicitare TCP de pe
portul 80 de la IP -ul și MAC -ul lui h1 la IP -ul si MAC -ul lui h4, să fie trimise de pe portul 4. De
asemenea poate conține si un Buffer -ID care va spune switch -ului sa elibereze primul pachet stocat, cu
numărul 250 ca în figura5.14 și să aplice aceeași acțiune Acest exemplu prezintă doar o acțiune, da r
multe altele sunt posibile: schimbarea multiplelor anteturi, precum IP, MAC și porturi TCP,
“inundarea” tuturor pachetelor, se poate seta switch -ul sa funcționeze în modul lui normal, non –
Openflow
Un alt detaliu pe care îl conține acest tip de mesaj este “timpul de exprirare”. Aici avem un
„idle timeout” de 20, care elimină intrarea de flux după 20 de secunde, dacă nu sunt cereri cunoscute
TCP și un “hard timeout” de 60 , care elimina intrarea de flux dupa 60 de secunde indiferent de situație.
Prioritatea este foarte importanta, deoarece intrarile fluxului sunt sortate după aceasta.

55

Figura 5.2.2 Acțiunea de a redirecționa pacchetul pe portul 4

Cererea de SYN pe portul 80, ajunge la h4, iar h4 raspunde cu un mesaj de tipul SYN/ACK.
Switch -ul nu are nimic legat de acest tip de mesaj, decat cel de SYN de la h1 la h4. Așa ca switch -ul
incapsulează mesajul intr -un Pachet -IN cu Buffer -ID = 251 și îl trimite la controler . SDN controler
trimite un Pachet -OUT pentru a spune switch -ului ce să facă cu el, dar posibi l să trimită și un mesaj de
modificare de flux pentru viitoarele pachete asemănătoare.
În acest moment totul este stocat în switch, iar comunicarea dintre cele 2 gazde nu mai trebuie să
treacă prin controler, deoarece există intrări și ieșiri de flux (ACK, cerere HTTP, răaspuns HTTP) care
vor spune ce se va întampla cu un pachet.

56

Figura 5.2.3 Pachete capturate în Wireshark

Comenzile rulate mai sus au creat transferul de pachete de mai sus. Mesajul de tip Pachet -IN
trimis de switch către controler. Se observa un Buffer -ID=271ca referință al pachetului. Mai jos avem
câteva câmpuri de la pachetul original, precum MAC -ul sursă și destinație, IP -ul sursă (10.0.0.1) și
destinație (10.0.0.4), dar și Portul sursă și destinație (80) a protocolului TCP.
Destinația trimite apoi un mesaj de SYN ACK înapoi către switch. Câmpul OpenFlow -> reson:
OFPR_NO_MATCH (0) indică inexistența unui flux cunoscut. Acesta urmeaza a fi salvat abia acum în
tabelă.

57

Figur a 5.2.4. Mesajul SYN ACK

Figura 5.2.5. Mesajul de modificare OpenFlow

58
Acest mesaj de modificarea flow -ului este foarte specific. Se observa MAC -ul, IP -ul sursă și
destinație și chiar porturile TCP. Prezența portului sursă TCP este o potrivire ceea ce înseamnă că acest
mesaj va funcționa doar pentru acast a sesiune specifică. În aceste câmpuri sunt și detalii despre “timpul
de expirare”: idle_timeout 60 și hard_timeout 0, adică nu va fi folosit. Prioritatea minimă, 0, este setată
și mai jos avem un Buffer -ID 272. Acest câmp îi spune switch -ului că are un Bu ffer-ID cu acea valoare
și că acel pachet trebuie să urmeze urmatoarea acțiune descrisă mai jos, în câmpul “of_action_output” .
Poate exista mai multe acțiuni, dar acum avem doar una și anume portul de ieșire să fie 1.

5.3. Implementarea “felierii ”

În acest exercițiu vom tăia o rețea cu o suprafață largă (WAN) în două moduri diferite. WAN -ul
prezentat în figura de mai sus conectează două site -uri. Pentru simplitate, vom avea fiecare site
reprezentat de un singur switch OpenFlow, respectiv s1 și respectiv s4. Site -urile, s1 și s4, au două căi
între ele:

Figura 5.3 .1 Topoloie principală

 cale de lățime de bandă mică prin comutatorul s2
 cale de lățime mare de bandă prin comutatorul s3

59
s1 are două gazde atașate: h1 și h2. s2 are două gazde atașate: h3 și h4.
În primul rând, voi porni topologia pentru acest exercițiu. Voi ieși din orice instanță Mininet care
rulează și voi executa:
$ sudo mn –custom ~/mininet/custom/topo_4sw_4h.py –topo mytopo –link tc –
-controller remote –mac –arp
Fișierul topo_4sw_4 h.py este unul de tip python, iar codul sursă se află la finalul acestei lucrări
(Anexa). Aceasta va crea o rețea în mininet cu topologia WAN. Pentru a menține lucrurile simple, am
stabilit intrări ARP statice pentru gazdele Mininet.
În continuare voi conf igura FlowVisor, deoarece nu a fost rulat pe mașina virtuală. Mai întâi, într –
un terminal nou, generez un configurator de flux:
$ sudo -u flowvisor fvconfig generate /etc/flowvisor/config.json
Am lăsat parola fvadmin goală (apăsând enter). Pornesc Flowviso r pentru a modifica configurația
prin comanda $ sudo /etc/init.d/flowvisor start
Pentru a activa controlorul topologiei FlowVisor se folosește fvctl, care este o utilitate pentru
linia de comandă pentru a gestiona FlowVisor. Argumentul -f indică un fișier cu parolă. Am configurat
instanța FlowVisor să fie fără parolă, deci fișierul de parolă este / dev / null .
$ fvctl -f /dev/null set -config –enable-topo-ctrl
Apoi, restart Flowvisor $ sudo /etc/init.d/flowvisor restart
Când FlowVisor a început, toate com utatoarele OpenFlow pe care le -am creat anterior ar fi trebuit
să se conecteze la el. În continuare, trebuie să ne asigurăm că FlowVisor rulează obținând configurația
sa: $ fvctl -f /dev/null get -config
Enumerați feliile existente folosind următoarea coma ndă: $ fvctl -f /dev/null list -slices
Ne asigurăm că singura felie este felia implicită fvadmin . Produsul ar trebui să arate astfel:
$ fvctl -f /dev/null list -slices
Configured slices:
fvadmin –> enabled
Enumerăm feliile existente folosind următoa rea comandă: $ fvctl -f /dev/null list –
flowspace
Ne asigurăm că nu există spații de flux existente. Produsul ar trebui să arate astfel:
$ fvctl -f /dev/null list -flowspace
Configured Flow entries:
None

60
În continuare ne asigurăm că switch -urile sunt conect ate $ fvctl -f /dev/null list –
datapaths
Este posibil să fie nevoie să așteptați câteva secunde pentru conectarea switch -urilor înainte de a
executa comanda. Dacă toate switch -urile sunt conectate, ar trebui să rezulte o ieșire ca aceasta:
$ fvctl -f /dev/n ull list -datapaths
Connected switches:
1 : 00:00:00:00:00:00:00:01
2 : 00:00:00:00:00:00:00:02
3 : 00:00:00:00:00:00:00:03
4 : 00:00:00:00:00:00:00:04
Următorul pas ar fi să ne asigurăm legăturile sunt active
$ fvctl -f /dev/null list -links

5.3.1 . Partea 1: „Feliere” d e bază – topologie simplă

FlowVisor poate tăia o rețea în mai multe moduri. Aici, vom explora cel mai simplu mod – tăiere
prin porturi de comutare. Un exemplu de caz de utilizare este un furnizor WAN care dorește să -și taie
rețeaua pentru a oferi link -uri dedicate fiecărui locatar. În această parte, vom crea două felii fizice din
WAN -ul nostru, denumindu -le în sus și în jos, așa cum se arată în figura de mai jos.

61

Figura 5.3 .2 „Felierea” de bază

5.3.1.1. Crearea „feliilor ”
Fieca re „felie” va fi gestionată de un controler separat care va controla întregul trafic din felia sa.
Ca exemplu (nu este necesară tastarea acesteia), comenzile pentru a crea o felie ar folosi comanda add –
slice în fvctl: fvctl add -slice [options] <slicename> <controller -url> <admin -email>

URL -ul controlerului are forma tcp: hostname: port. E -mailul de administrare este utilizat în
scopuri administrative, dacă există o problemă cu felia. Puteți afla mai multe despre comandă tastând:
$ fvctl add -slice –h
Acum, com crea o felie numită “upper” care se conectează la un controler care ascultă pe tcp:
localhost: 10001 rulând următoarea comandă:
$ fvctl -f /dev/null add -slice upper tcp:localhost:10001 admin@upperslice
Lăsăm „felia” fără parolă, apăsând enter. La fel v om lăsa și pentru cealaltă. În mod similar, vom
crea o „felie” numită „lower” care va fi conectată la un controler care ascultă pe tcp: localhost: 10002.
$ fvctl -f /dev/null add -slice lower tcp:localhost:10002 admin@lowerslice

62
5.3.1.2. Crearea de spații lor de flux
Flowspaces asociază pachete de un anumit tip din rețea unor felii specifice. Comenzile pentru
crearea de spații de flux (nu este necesară tastarea acesteia) ar folosi comanda add -flowpace:
$ fvctl add -flowspace [options] <flowspace -name> <dpid> <priority> <match> <slice -perm>
 Când un pachet se potrivește cu mai multe spații de flux, FlowVisor îl atribuie spațiului de flux
cu cel mai mare număr de prioritate .
 match descrie un flux sau fluxuri. Astfel de descrieri ale fluxului cuprind un câmp de se rie =
alocări de valori, separate prin virgule.
 slice-perm este o listă separată de virgule de felii care au control asupra unui anumit FlowSpace.
slice-perm are forma "slicename1 = perm [slicename2 = perm […]]". Fiecare felie poate avea trei
tipuri de p ermisiuni pe un spațiu de flux: DELEGARE, CITEȘTE și SCRIRE. Permisiunile sunt
o mască de bit specificată ca un număr întreg, cu DELEGATE = 1, CITEȘTE = 2, SCRIE = 4.

Acum, vom crea un spațiu de flux numit dpid1 -port1 (cu valoare prioritară 1) care mapeaz ă tot traficul
de pe portul 1 al comutatorului s1 la “felia” superioară rulând următoarea comandă:
$ fvctl -f /dev/null add -flowspace dpid1 -port1 1 1 in_port=1 upper=7
Aici am dat felia superioară toate permisiunile: DELEGATE, READ și WRITE. În mod similar ,
vom crea un spațiu de flux numit dpid1 -port3 care mapează tot traficul din portul 3 al comutatorului s1
la felia superioară:
$ fvctl -f /dev/null add -flowspace dpid1 -port3 1 1 in_port=3 upper=7
Putem crea un spațiu de flux pentru tot traficul la un comut ator folosind valoarea potrivită a
oricărui. Folosiți această tehnică pentru a adăuga comutatorul s2 la felia superioară:
$ fvctl -f /dev/null add -flowspace dpid2 2 1 any upper=7
Acum, vom crea spații de flux pentru a adăuga porturile 1 și 3 ale switch s4 la felia superioară:
$ fvctl -f /dev/null add -flowspace dpid4 -port1 4 1 in_port=1 upper=7
$ fvctl -f /dev/null add -flowspace dpid4 -port3 4 1 in_port=3 upper=7
Verificăm dacă spațiile de flux sunt adăugate corect
$ fvctl -f /dev/null list -flowspace
Vom adău ga și “feliile” pentru partea de jos și ne vom asigura că sunt adaugate corect
$ fvctl -f /dev/null add -flowspace dpid1 -port2 1 1 in_port=2 lower=7
$ fvctl -f /dev/null add -flowspace dpid1 -port4 1 1 in_port=4 lower=7
$ fvctl -f /dev/null add -flowspace dpid 3 3 1 any lower=7
$ fvctl -f /dev/null add -flowspace dpid4 -port2 4 1 in_port=2 lower=7

63
$ fvctl -f /dev/null add -flowspace dpid4 -port4 4 1 in_port=4 lower=7
$ fvctl -f /dev/null list -flowspace
Conectăm fiecare “felie” la o altă instanță a aplicației control er FVexercise. Aplicația FVexercise
instalează în mod reactiv rute pe baza adresei MAC de destinație și este furnizată ca executabil.
Deschidem două noi terminale și executăm următoarele:
Terminalul 1: $ cd ~/mininet/beacon -fvexercise -controller1
$ ./beac on
Terminalul 2: $ cd ~/mininet/beacon -fvexercise -controller2
$ ./beacon
Aceasta va lansa două instanțe ale controlorului Beacon FVexercise, ascultând pe porturile 10001
și, respectiv, 10002. După o scurtă întârziere, ambele controlere trebuie să se conec teze. Verificăm dacă
h1 poate face ping h3, dar nu h2 și h4 (și invers). Dar și dacă h2 poate face ping h4, dar nu h1 și h3 (și
invers). În consola Mininet rulează următoarele comenzi.
mininet> h1 ping -c1 h3
mininet> h1 ping -c1 -W1 h2
mininet> h1 ping -c1 -W1 h4

mininet> h2 ping -c1 h4
mininet> h2 ping -c1 -W1 h1
mininet> h2 ping -c1 -W1 h3

64

Figura 5. 3.3 Ping-ul în h4 funcționează, dar nu și celelalte

5.3.1.3. Ștergerea „feliilor“
Vom elimina “feliile” create și ne vom asigura că sunt corect șterse. A r trebui să rămână doar
“felia” implicită fvadmin. De asemenea ne asigurăm că cele 2 controlere sunt oprite
$ fvctl -f /dev/null remove -slice upper
$ fvctl -f /dev/null remove -slice lower

$ fvctl -f /dev/null list -slices
$ fvctl -f /dev/null list -flowspac e

5.3.2. Partea a 2 -a: „Felierea” avansată a spațiilor de flux
Partea anterioară a exercițiului a arătat cum putem tăia o rețea OpenFlow bazată pe topologia
fizică a rețelei. Cu vizibilitatea centralizată și „fără straturi”, putem tăia rețeaua în moduri m ai interesante.
La baza sa, „felierea ” este pur și simplu delegarea controlului fluxurilor în diferite felii. OpenFlow ne
permite să definim fluxurile în moduri flexibile. Acest lucru ne permite să tăiem rețeaua noastră în moduri
mai interesante. Vom explo ra un astfel de mod în această parte a exercițiului.

65
Reveniți la topologia noastră WAN. Avem două căi care leagă cele două site -uri: o cale de lățime
mare de bandă și o cale de lățime de bandă mică. În calitate de administratori ai WAN -ului nostru,
decidem că dorim să acordăm un tratament special traficului video din rețeaua noastră. În special, dorim
să trimitem tot traficul video pe calea cu lățime mare de bandă și să trimitem tot celălalt trafic pe calea
implicită de lățime de bandă mică. În acest fel, c onexiunile noastre Skype nu vor fi afectate de traficul
video și invers. Vom vedea cum putem realiza acest lucru folosind felierea.
Pentru a menține lucrurile simple, vom presupune că tot traficul video merge pe portul TCP 9999.
Vom crea două felii, video și non -video, așa cum se arată mai jos.
“Felia” video controlează traficul pe portul TCP 9999. „Felia” non -video controlează orice
altceva. Rețineți că felia video controlează partea cu lățime mare de bandă a rețelei.

Figura 5.3.4 „Felierea” avansată a spațiilor de flux

5.3.2.1. Crearea „feliilor”
La fel ca partea precedentă, creați două felii numite conectare video și non -video la controlerele
care ascultă la tcp: localhost: 10001 și tcp: localhost: 10002, respectiv:
$ fvctl -f /dev/null add -slice vid eo tcp:localhost:10001 admin@videoslice
$ fvctl -f /dev/null add -slice non -video tcp:localhost:10002 admin@nonvideoslice
La fel ca în exemplul de mai sus vom lăsa parola liberă și ne vom asigura dacă am adaugat corect
“feliile”: $ fvctl -f /dev/null list -slices
Acum ar trebui să vedem atât “felii” video, cât și non -video, pe lângă “felia” implicită fvadmin,
activate.

66
5.3.2.2. Crearea spații lor de flux
Crearea FlowSpace în acest caz este puțin mai implicată, în special la porturile de margine unde
gazdele se conectează la switch -uri, deoarece traficul acolo este împărțit între cele două felii. La porturile
de margine, felia video trebuie să se ocupe de tot traficul cu portul sursă sau de destinație din 9999, iar
felia non -video trebuie să se ocupe de restul. O vom realiza folos ind valori prioritare diferite.
Să începem cu ( switch -ul s1, portul 3) care conectează s1 la h1. Mai întâi, vom crea două spații
de flux cu prioritate înaltă care se potrivesc cu tot traficul cu portul sursă sau destinație de 9999 la ace l
port și atribuiți -l secțiunii video:
$ fvctl -f /dev/null add -flowspace dpid1 -port3-video-src 1 100
in_port=3,dl_type=0x0800,nw_proto=6,tp_src=9999 video=7
$ fvctl -f /dev/null add -flowspace dpid1 -port3-video-dst 1 100
in_port=3,dl_type=0x0800,nw_proto= 6,tp_dst=9999 video=7
Am ales în mod arbitrar o valoare prioritară mare de 100. Apoi, creăm un spațiu de flux cu
prioritate mică, care se potrivește cu tot traficul din portul respectiv și îl alocăm “feliei” non -video:
$ fvctl -f /dev/null add -flowspace dp id1-port3-non-video 1 1 in_port=3
non-video=7
Acest lucru duce la faptul că tot traficul video din (switch s1, port 3) este gestionat de „felia”
video și tot traficul non -video este gestionat de cea non -video. În mod similar, vom crea spații de flux
pentru a separa traficul video și n on-video la (switch s1, port 4), (switch s4, port 3) și (switch s4, port 4 )
$ fvctl -f /dev/null add -flowspace dpid1 -port4-video-src 1 100
in_port=4,dl_type=0x0800,nw_proto=6,tp_src=9999 video=7
$ fvctl -f /dev/null add -flowspace dpid1 -port4-video-dst 1 100
in_port=4,dl_type=0x0800,nw_proto=6,tp_dst=9999 video=7
$ fvctl -f /dev/null add -flowspace dpid1 -port4-non-video 1 1 in_port=4 non –
video=7
$ fvctl -f /dev/null add -flowspace dpid4 -port3-video-src 4 100
in_port=3,dl_type=0x080 0,nw_proto=6,tp_src=9999 video=7
$ fvctl -f /dev/null add -flowspace dpid4 -port3-video-dst 4 100
in_port=3,dl_type=0x0800,nw_proto=6,tp_dst=9999 video=7
$ fvctl -f /dev/null add -flowspace dpid4 -port3-non-video 4 1 in_port=3 non -video=7
$ fvctl -f /dev/ null add -flowspace dpid4 -port4-video-src 4 100
in_port=4,dl_type=0x0800,nw_proto=6,tp_src=9999 video=7

67
$ fvctl -f /dev/null add -flowspace dpid4 -port4-video-dst 4 100
in_port=4,dl_type=0x0800,nw_proto=6,tp_dst=9999 video=7
$ fvctl -f /dev/null add -flowspace dpid4 -port4-non-video 4 1 in_port=4 non -video=7
Acum am rămas doar cu porturile interne. Crearea spațiilor de flux pentru acestea este simplă,
deoarece traficul în fiecare port intern este gestionat exclusiv de o singură felie. Vom crea spații de flux
pentru po rturile interne exact așa cum am făcut partea 1.
Alocăm (switch s1, portul 2) la video:
$ fvctl -f /dev/null add -flowspace dpid1 -port2-video 1 100 in_port=2 video=7
Alocăm (switch s3, toate porturile) la video:
$ fvctl -f /dev/null add -flowspace dpid3-video 3 100 any video=7
Alocăm (switch s4, portul 2) la video:
$ fvctl -f /dev/null add -flowspace dpid4 -port2-video 4 100 in_port=2 video=7
Alocăm (switch s1, portul 1) la non -video:
$ fvctl -f /dev/null add -flowspace dpid1 -port1-non-video 1 1 in_po rt=1 non –
video=7
Alocăm (switch s2, toate porturile) la non -video:
$ fvctl -f /dev/null add -flowspace dpid2 -non-video 2 1 any non -video=7
Alocăm (switch s4, portul 1) la non -video:
$ fvctl -f /dev/null add -flowspace dpid4 -port1-non-video 4 1 in_port=1 non –
video=7
Acum, am terminat cu crearea tuturor spațiilor de flux, ne asigurăm că spațiile de flux au fost
adăugate corect: $ fvctl -f /dev/null list -flowspace
Exact ca în partea 1, vom porni cele 2 controlere în 2 terminale diferite. Următorul lucru vom
verifica dacă am tăiat corect rețeaua noastră. Dacă ne -am tăiat corect rețeaua, un flux video (care rulează
pe portul TCP 9999) ar trebui să treacă peste calea de lățime mare de bandă și să vadă un randament de
10 Mb / s. Un flux non -video (care rulează pe or icare alt port TCP) ar trebui să treacă peste calea lățimii
de bandă scăzută și să vadă un debit de 1 Mb / s. Verificăm conectivitatea în consola Mininet, executând
mininet> pingall .
Pentru a fi mai usor de urmărit, am rulat comanda mininet> h1 ping h4 și am analizat
schimbul de pachete în wireshark. Conform topologiei, pachetul trebuie trimis de la switch -ul 1 pe portul
1, de pe switch -ul 2, portul de iesire este 2, iar de pe switch -ul 4, portul 4. În capturile de mai jos, vom
observa în pachetele de ada ugarre flux, că acest traseu al ping -ului se respectă.

68

Figura 5.3.5. Portul 1 de ieșire de pe switch -ul 1

Figura 5.3 .6 Portul 4 de ieșire de pe switch -ul 4

69
Rețeaua are conectivitate deplină acum, în comparație cu modelul anterior, unde porturile era u
izolate unele de altele. Acum, vom verifica dacă fluxurile video și non -video iau căile corecte. Terminale
deschise pentru gazdele h1 și h3. În consola Mininet rulează: mininet> xterm h1 h3 .
# iperf -s -p 9999
Pornim un flux video rulând următoarea coma ndă în terminalul popped al nodului h3:
# iperf -c 10.0.0.1 -p 9999 -t 10 -i 1
Ar trebui să vedem o cantitate de aproximativ 10 Mb / s. Puteți rula această aceeași comandă în
h4 și obține același rezultat, în timp ce înainte, nu exista conectivitate. Următ oarele terminale deschise
pentru gazdele h2 și h4. În consola Mininet rulează: mininet> xterm h2 h4 . În terminalul pop -up al
„nodului: h2” rulăm: # iperf -s -p 8888 . Pornim un flux non -video rulând următoarea comandă în
terminalul popped al nodului h4: # iperf -c 10.0.0.2 -p 8888 -t 10 -i 1. Ar trebui să vedem
un trafic de 1 Mb/s .

Figura 5.3.7. Limitarea de bandă

70
5.3.2.3. Ștergerea “feliilor”
Oprim ambele controlere și stergem “feliile” create, apoi verificăm dacă s -au sters correct și dacă
spațiile de flux sunt correct eliminate
$ fvctl -f /dev/null remove -slice video
$ fvctl -f /dev/null remove -slice non -video
$ fvctl -f /dev/null list -slices
$ fvctl -f /dev/null list -flowspace

71
Concluzie
SDN este cu adevărat despre operațiuni și ma nagement
Probab il că nu am terminat să exploră m aspectul de management al SDN, ca o nouă generație de
BSS / OSS evoluează în continuare pentru a putea ține pasul cu o rețea mai virtuală / programabilă /
agilă. Vendorii B / OSS tradiționali precum BMC, Amd ocs, CA și alții se luptă împotriva IPsoft, Tail -f
și ServiceNow pe piața Cloud OSS deoarece o evoluție a unui OSS în timp real pentru aceste medii a
început.
Acest mediu ofera, de asemenea, oportunități pentru furnizorii de echipamente tradiționale de reț ea
(de exemplu, Cisco, ALU) să participe mai pe deplin la următoarea generație de OSS / BSS
În cele din urmă, una dintre principalele forțe și motivații ale SDN este legată de optimizarea
operațiunilor. Mai devreme în text, am vorbit despre diviziunea din tre rețea și aplicații. Această analogie
este baza pentru o mare parte din ceea ce SDN iș i propune de rezolvat – sau cel puțin îmbunătățit, atât
pentru utilizatorul rețelei, cât și pentru operatorul rețelei.

Concluzii
Deși suntem încântați de conceptele SDN este ușor sa exageră m cu concluzii pripite. În acest
scop, cre d că există încă multe cercetări și eforturi grele de făcut în domenii precum depanarea
(suprapunerile sunt mai dificile decât acoperirile de depanare, deoarece redirecționarea este “concert ul”
tuturor operațiunilor de curgere și avem nevoie de un set de instrumente potențial nou), securitate ,
verificare și politică (o mare parte dintre acestea fiind abordate în mediul academic astăzi și intrând lent
în standarde și în considerarea consorții lor). Multe dintre aceste domenii ne vor aminti de munca grea pe
care am făcut -o cu ani în urmă în zonele operaționale din jurul altor noi tehnologii, cum ar fi MPLS sau
IP pentru a optimiza utilizarea lor pentru rețelele comerciale .

Pe plan economic
Dive rși bloggeri au declarat că următoarea combinație de virtualizare și SDN este, în cel mai bun
caz, o propunere din sumă zero pentru consumator. În cel mai rău caz, este de fapt o propunere negativă.
Experiența personală ne -a arătat că acest lucru este adev ărat în prezent. De fapt, un astfel de studiu arată
o creștere cu 80% a costurilor de gestionare a IT în centrele de date care pot fi atribuite creșterii
virtualizării. Dar acest lucru nu înseamnă că ar trebui să ne oprim aici; este multă muncă de făcut pe ntru

72
a trece de acest punct pe tărâmul în care SDN poate oferi de fapt un câștig sau beneficiu net operatorului
de rețea.
Ceea ce am încercat să realizez în aceasta lucrare este doar un mic exemplu, din ceea ce poate sa
facă aceasta rețea definită software . Chiar și asa consider foarte util și o modalitate de a face viața
oamenilor mai ușoara prin implementarea acestor rețele, dar și echipamente mai performante.

73
Bibliografie
[1] Thomas D. Nadeau & Ken Gray, SDN: Software Defined Networks, O’Reilly, 2013
[2] Casimer DeCusatis, PhD Aparicio Carranza, PhD and Jean Delgado -Caceres, Modeling Defined
Networks using Mininet, Lucrarea nr 133, Ottawa, Canada, 11 Mai 2016
[3] http://mininet.org /walkthrough/ – accesat la data de 22.03.2019
[4] https://en.wikipedia.org/wiki/Software -defined_networking – accesat la data de 22.03.2019
[5 ] https://www.youtube.com/watch?v=l25Ukkmk6Sk&t=544s – accesat la data de 22.03.2019
[6] https://www.virtualbox.org – accesat la data de 22.03.2019
[7] https://github.com/mininet/mininet/wiki/Mininet -VM-Images – accesat la data de 22.03.2019
[8] /https://github.com/opennet workinglab/flowvisor/wiki/Installation -from -Source – accesat la data de
22.03.2019
[9] https://mobaxterm.mobatek.net/download -home -edition.html – accesat la data de 22.03.2019
[10] https://www.sdxcentral.com/networking/sdn/definitions/what -is-openflow/ – accesat la data de
22.03.2019
[11] https://github.com/onstutorial/onstutorial/wiki/Flowvisor -Exercise – accesat la data de 12.05.2019

74

75
Anexa 1

Codul sursă a fișierelor scrise în phyton
Topologie cu 4 switch -uri și 4 gazde

from mininet.topo import To po

class MyTopo( Topo ):
"Simple topology example."

def __init__( self ):
"Create custom topo."

# Initialize topology
Topo.__init__( self )

# Add hosts and switches
h1 = self.addHost( 'h1' )
h2 = self.addHost( 'h2' )
h3 = self.addHost( 'h3' )
h4 = self.addHost( 'h4' )
s1 = self.addSwitch( 's1' )
s2 = self.addSwitch( 's2' )
s3 = self.addSwitch( 's3' )
s4 = self.addSwitch( 's4' )

76

# Add links
self.addLink( h1, s1 )
self.addLink( h2, s1 )
self.addLink( s1, s2 )
self.addLink( s1, s3 )
self.addLink( s4, s2 )
self.addLink( s4, s3 )
self.addLink( s4, h3 )
self.addLink( s4, h4 )

topos = { 'mytopo': ( lambda: MyTopo() ) }