2015.05.14.

1

Software Defined

Networking

Szabó Flórián Ákos | Majoros Tamás

- SDN definíciója- Control és Data plane szétválasztása- Az SDN alapú hálózati architektúra bemutatása- Hogyan volt eddig?- Miért szükséges a változás? - Hogyan lesz ezután (SDN-nel)?- Az SDN előnyei- Az OpenFlow protokoll rövid bemutatása- SDN Controller-ek rövid bemutatása- Egy már létező SDN implementáció: Google B4- Gyakorlati példák

- Mininet példa- L2-es tanuló Switch- Elosztott L2-es Tűzfal- Application Load Balancer

Tartalom

2015.05.14.

2

Az SDN-ről dióhéjban

Egy újfajta hálózati architektúra, amely olyan eszközökből áll,

amelyek gyártófüggetlen módon programozhatóak, s ezáltal

az eszközök vezérlése (Control plane) és a tényleges

forgalomtovábbítás (Data Plane) szétválasztódik.

Ez gyakorlatilag azt jelenti, hogy a gyártó csak a vasat adja el

és az azon futó szoftver, amely a hálózat vezérléséért felel,

nyíltan programozható, vezérelhető és ami nagyon fontos,

hogy ezáltal automatizálhatóvá válik!

Az SDN-ről dióhéjban

Koncepció: az SDN legyen dinamikus, menedzselhető,

költséghatékony, alkalmazkodjon a mai alkalmazások

dinamikus természetéhez és nagy sávszélesség-igényéhez.

Szétválasztja a hálózat vezérlő és továbbító funkcióit,

lehetővé teszi, hogy a hálózati vezérlő közvetlenül

programozható legyen és a mögöttes infrastruktúrát

különválasszuk az alkalmazásoktól és a hálózati

szolgáltatásoktól

2015.05.14.

3

•Agilis: a szétválasztás lehetővé teszi a hálózati adminisztrátor

számára, hogy a hálózati konfigurációt a folyamatosan változó

igények kielégítése érdekében dinamikusan módosítsa

•Központilag menedzselhető: az „agy”, a hálózat intelligenciája

a kontrollerekben van centralizálva, globális képet látnak a

hálózatról

•Nyílt szabványokon alapuló és gyártófüggetlen:

egyszerűsödik a hálózat kialakítása és működtetése, mert több

különböző gyártóspecifikus eszköz és protokoll helyett az SDN

kontrollerek irányítják a hálózatot

Az SDN-ről dióhéjban

Information Control Messages

•Control/Management plane:Döntéshozás a forgalomtovábbítás módjáról

•Data/Forwarding plane:A Control Plane által meghatározott instrukciók szerint az eszközön áthaladó forgalom

továbbítása

•A Control plane és Data plane közti kommunikációt az OpenFlow protokoll biztosítja

Hogyan lehet ezt elérni?

Control plane

Data plane

►SDN: a gyártó nem

telepíti fel az eszközökre

egyesével a saját zárt

szoftverét, hanem

implementálja az

OpenFlow protokollt,

aminek segítségével az

eszköz menedzselhető

lesz távolról egy ún.

Controller segítségével.

2015.05.14.

4

(kép forrása: http://www.commscope.com/Blog/SDN--The-Problem-Solver/)

Hogyan volt eddig?

Hálózatok építésénél nem csak azt kellett figyelembe venni, hogy milyen

igényeket kell tudnia kiszolgálni a megvett eszközöknek, hanem azt is

hogy melyik gyártótól lehet megvenni és mennyiért? Cisco, Juniper, Hp,

Dell, Nortel, Motorola, stb. …

A vásárláskor eldől hogy melyik gyártó szoftveréhez láncolja magát a

vevő. Ez nem szerencsés, mert a gyártó aki az eszközt előállítja nem

feltétlenül képes a legjobb szoftvert is megírni rá, ami lassítja az

innovációt és drágítja az eszközöket.

Mivel a Control Plane minden egyes eszközön elosztott módon szerepel,

az eszközök komplexek, azokat leggyakrabban egyesével, parancssoros

eléréssel kell konfigurálni. Egy adatközpontban például egy-egy új policy

bevezetésekor akár több száz eszközt kell újrakonfigurálni amely lassú

és magában hordozza az emberi hiba lehetőségét.

2015.05.14.

5

•A változás szükségességét tekintve több forrást megjelölhető:

•Végfelhasználók számának rohamos növekedése

•Szerver virtualizáció, felhő alapú szolgáltatások terjedése

•Big data alkalmazások sávszélesség igényeink kielégítése

A legtöbb hálózat hierarchikus felépítésű (Core, Distribution és

Access layer), amely a kliens-szerver alapú forgalom dominanciája

esetén még viszonylag jól működött, viszont ez a fajta felépítés

manapság egyre gyakrabban nem megfelelő a

vállalatok/felhasználók dinamikus számítási és adattárolási

igényeinek

Nem utolsó sorban a hálózatok akkora méreteket kezdenek ölteni,

amit „kézzel” (értsd: automatizáció nélkül) egyre nehezebb kezelni

Miért van szükség változásra?

Az eszközök nyilván nem fognak egyik napról a másikra

lecserélődni, vagy megtanulni SDN (OpenFlow) nyelven „beszélni”,

ez a váltás fokozatosan fog végbemenni.

Először a hibrid eszközök fognak megjelenni, amelyek még

tartalmazzák a jelenlegi tradicionális Control plane funkciókat,

valamint opcionálisan képesek lesznek egy SDN vezérlőtől

fogadni utasításokat.

Idővel viszont meg fognak jelenni azok az eszközök amelyek már

kizárólag az SDN controllertől fogják kapni az instrukciókat.

Ezeknek az eszközöknek a konfigurációja már nem egyesével

hanem központilag a kontrolleren keresztül fog történni

automatizmus és emberi felügyelet mentén

Hogyan lesz az SDN-nel?

2015.05.14.

6

Az SDN előnyei: Erőforrás gazdálkodás

A tradicionális hálózatok esetében, az OSI modell 7. rétegében

futó alkalmazásoknak nincs rálátása hogy az őket kiszolgáló

hálózaton hogyan alakul az éppen elérhető szabad kapacitás, ami

miatt általánossá vált a hálózatok túlterheltsége.

Ezzel szemben, egy SDN környezetben, az OSI modell 7.

rétegében futo alkalmazás kapcsolatba tud lépni az SDN

Controllerrel, azzal közölni tudja a hálózaton forgalmazni kívánt

becsült adatmennyiségét és a Controller figyelembe véve fel tudja

„konfigurálni” a hálózati eszközöket a forgalmi igény megfelelő

kielégítésére.

Az SDN előnyei: Automatizáció

Az SDN architektúra és megfelelő absztrakció felhasználásával olyan

szoftver-csomagok fejlesztése válik lehetővé, amelyek segítségével a

fizikai hálózati infrastruktúra képes az azt igénybe vevő

alkalmazások/userek igényeihez alkalmazkodni és nem pedig

fordítva.

Northbound API: az SDN Controller által egy API (pl REST), amelyen

keresztül a hálózat vezérelhetővé válik az alkalmazások számára.

Southbound API: ezalatt tipikusan az OpenFlow protokollt értjük,

amellyel az SDN Controller képes vezérelni az eszközöket.

Elképzelhető hogy bizonyos fejlesztők SDN Controller-jei az OpenFlow protokoll

mellett egy saját maguk által kifejlesztett protokollt is alkalmaznak (ami viszont már

ellent mond a gyártófüggetlenség elvének).

2015.05.14.

7

Northbound vs Southbound API

Kép forrása: http://deliveryimages.acm.org/10.1145/2510000/2500473/figs/uf2.jpg

Az SDN előnyei: Multivendor környezet

központi vezérlése

Egy OpenFlow protokollt használó SDN Controller képes akármelyik

gyártó eszközét vezérelni, mindameddig az eszközben implementálva

van / támogatott az OpenFlow protokoll megfelelő verziója. Ahelyett

hogy az eszközöket gyártónként külön csoportokban kezelnék, az

SDN architektúrán alapuló hálózatot egy központi Controller

segítségével lehet menedzselni, amelynek köszönhetően

egyszerűsödik sok munkafolyamat.

Fontos megjegyezni, hogy az SDN nem egyenlő az OpenFlow

protokollal. Maga az OpenFlow csak egy lehetséges mód az SDN

architektúra bevezetésére, emellett gyártóspecifikus megoldások is

elképzelhetőek a jövőben, amely viszont már ellent mondana a

gyártófüggetlenség követelményével!

2015.05.14.

8

Az SDN előnyei: Megbízhatóság,

biztonság

Az SDN-nek köszönhetően lehetőség van magasszintű konfigurációs

sémák és policy-k definiálására, amelyet a Controller fog lefordítani a

fizikai hálózat függvényében és érvényesíteni az OpenFlow protokoll

segítségével.

Mivel az SDN Controllernek teljes rálátása és irányítása van a

hálózat fölött a szükséges ACL, forgalmi, QoS és biztonsági

megszorítások érvényesítése lényegesen egyszerűbb feladat, mint a

tradícionális hálózatok esetében.

Nagyvállalatok esetében ez komoly operációs költségcsökkenést,

dinamikusabb hálózatot, kevesebb hibás konfigurációt és konzisztens

biztonsági előírásokat eredményezhet, amely komoly motiváció

lehet az SDN bevezetésére.

Az SDN előnyei: Egyszerűbb hardver

Az SDN koncepciójából adódóan talán ez az ami legnyilvánvalóbb amikor az SDN

előnyeiről van szó. Azzal, hogy az eddig minden eszközön megtalálható Control

Plane-t leválasztjuk és csak a forgalom továbbításával foglalkozó Data Plane marad

az eszközben, az eszközök komplexitása nagyban csökken, aminek közvetlen

következménye az árcsökkenés, amely nagyvállalati szinten komoly

megtakarításokat eredményezhet. Nem mellesleg, az eszközök áramfogyasztása

is csökkenni fog, mert nem kell többet a Controle Plane szoftvert futtatnia.

Hozzá kell tenni, hogy az árcsökkenésben az is közrejátszik, hogy az eddig az

eszközök árának jelentős részét képező gyártói szoftver licenszre nincs ezentúl

szükség, mert nem tartalmaz az eszköz ilyen szoftvert

A tradicionális hálózatok esetében, a forgalom irányításával kapcsolatos

intelligencia elosztott módon van jelen, minden eszközben, amelynek

következtében meglehetősen komplexszé válnak, ezzel szemben Egy SDN

környezetben a forgalomirányításért felelős intelligencia központosított egy

logikailag centralizált SDN Controller-en.

2015.05.14.

9

Az OpenFlow protokollról

TLS/SSL

csatorna

Kommunikációs protokoll, amely arra szolgál hogy a Controller és

az OpenFlow képes hálózati eszköz egymással kommunikálni

tudjon (Control messages)

v 1.0 a legelső használható verzió, kezdetleges funkciók

v 1.5 a jelenlegi legújabb verzió, folyamatos fejlesztés alatt

Ahogyan azt az eredeti OpenFlow specifikáció is említi, maga az

OpenFlow nem követeli meg az IP protokoll használatát,

egyedüli követelmény hogy a hardverben implementált flow tábla

képes legyen egyezés keresésére a csomag fejrész mezőiben

(http://archive.openflow.org/documents/openflow-wp-latest.pdf)

(Open Networking Foundation - opennetworking.org)

Az OpenFlow protokoll

2015.05.14.

10

(Kép forrása: http://www.cisco.com/web/solutions/trends/open_network_environment/docs/cisco_one_webcastan_introduction_to_openflowfebruary142013.pdf

Az OpenFlow protokoll evolúciója

1.0: 1 flow tábla, 12 csomag fejrész alapján illeszt, aktívan már nem fejlesztik

1.1: több flow tábla, VLAN és MPLS támogatás, virtuális port, inkompatibilis az 1.0-val

1.2: bitmaszkolás, csomag újraírás, IPv6 támogatás, multi-Controller opció hozzáadása

1.3: Provider Backbone Bridge (PBB) támogatás

1.4: alap TCP port 6653, Optikai portok támogatása, Flow monitorozás

Header Fields Counters Actions

Header fields: 12 különböző protokollmező alpaján lehet egyezéseket keresni:

src/dst-MAC, src/dst-IP address, src/dst-TCP/UDP port number, IN_PORT,

VLAN ID, VLAN priority, TOS, IP protocol, Eth_TYPE

Ha egy flow tábla bejegyzés adott Header Field-je üres, akkor az azt jelenti hogy

mindenre csomagra illeszkedik.

Counters: minden alkalommal amikor egy csomag illeszkedik egy adott flow

tábla bejegyzésre és aszerint továbbítódik az adott bejegyzés számlálója

inkrementálásra kerül.

Actions: meghatározza, hogy ha egy csomag illeszkedi az adott Flow tábla

bejegyzésre, akkor mi a teendő a csomaggal, példa:

OpenFlow 1.0 – Flow tábla

2015.05.14.

11

Az OpenFlow 1.1-es verziójának megjelenésével az eszközök mostmár képesek

több flow táblát kezelni az eddig egy darab helyett

Létrehozták a pipelineing-ot, amelynek következtében utasítások sorozatát

lehet végre hajtani minden egyes csomagob (Action set segítségével). Példák:

TTL csökkentése, új header csatolása a csomaghoz.

Az Action set akkor kerül végrehajtásra, amikor a csomag végighaladt a

pipelineon.

OpenFlow 1.1 – Pipeline processing

Az OpenFlow 1.0-ás verziója még nem támogatta az IPv6-ot, ami

elég nagy negatívuma azoknak az eszközöknek, amelyeket a gyártók

ezzel a verzióval adtak ki.

2011 decemberében megjelent az OpenFlow 1.2-es verziója amely

már támogatja az alábbi IPv6-os protokollmezőket felhasználó flow

tábla bejegyzéseket:

•IPv6 forrás és cél cím

•Protokoll szám

•Forgalmi osztály (Traffic Class)

•ICMPv6 type & code

•Neighbour Discovery fejléc mezők

•IPv6 Flow címkék

Az OpenFlow 1.3-as specifikációba beépítették az IPv6 Extension

Header fejlécmezők támogatását is

OpenFlow (1.2) és IPv6

2015.05.14.

12

Az OpenFlow protokoll folyamatos fejlesztés alatt áll, legújabb verziója az 1.5-ös,

valamint már a következő, 2.0-ás verzió is kidolgozás alatt áll

Az 1.4-es verzió legfontosabb újításai:

•Header fields: 13 kötelező és további opcionális fejlécmezők (pl: IP DSCP, IP ECN,

SCTP protokoll, ICMPv4/6, ARP, MPLS, PBB

•Bundles: segítségével a Controller több műveletet egy csoportba (bundle-be) tud

szervezni és ezeket vagy egytől egyig sikeresen végighajtja vagy egyiket sem

(atomi tranzakció)

•Optikai portok támogatása, aminek a segítségével lehetővé válik az FCoE (Fiber

Channel over Ethernet) használata.

•Flow táblák szinkronizálása (több Controllere is lehet egy eszköznek)

•Meter tables: per-flow számlálók, QoS implementálásához fontos

•Lehetősége van az OpenFlow switcheknek értesítő üzenetet küldenie a Controller

számára ha valamilyen válrozás történt (CLI-n konfigolták, etc)

•Az alapértelmezett portot átdefiniálja: TCP 6653-ra

OpenFlow 1.4 és tovább

Match Fields Priority Counters Instructions Timeouts Cookies

Az 1.4-es OpenFlow specifikáció az alábbi portokat definiálja:

Standard port: ki és bemenő forgalom továbbítására alkalmas portok, amelyek

számlálókkal rendelkeznek és csoportosíthatók. Pl: fizikai, logikai és a LOCAL port.

Fizikai port: egy eszköz hardveresen jelen lévő portja, amely megfeleltethető a

switcheken egy ki/bemenő forgalmat kezelő portoknak.

Logikai port: magasabb szintű absztrakt portok, amelyek nem feleltethetők meg

direktben fizikai portoknak. Pl: link-aggregációs portok, tunnel interfészek, loopback.

Előre lefoglalt portok: az OpenFlow specifikáció által meghatározott általános célt

szolgáló portok, például: ALL, CONTROLLER, TABLE, IN_PORT, LOCAL,

NORMAL, FLOOD

A NORMAL és a FLOOD portok csak OpenFlow-Hibrid eszközökön érhetők el!

OpenFlow 1.4 - Portok

2015.05.14.

13

Olyan szoftvercsomag, amely egy szerveren futva képes a hozzá

kapcsolt OpenFlow protokollt használó hálózati eszközöket

vezérelni.

A kezdetleges Controller-ek még csak egyszerű hálózati funkciók

programozására adnak lehetősége, azonban egyes cégek már

komplett hálózati operációs rendszereket fejlesztenek amelyek

bonyolult megoldásokat képesek implementálni az eszközökön.

Az egyszerűbb Controller-eket különböző programnyelveken lehet

programozni: POX(Python), NOX(C++), Beacon(Java),

Ryu(Python), Floodlight(Java)

SDN / OpenFlow Controller

A Controller szoftver, viselkedése szerint, két fajta lehet:•Proaktív a Controller akkor, ha az előzetes információk alapján a

Flow tábla bejegyzéseket előre legenerálja és beilleszti a megfelelő

eszközök Flow táblájába

•Reaktív a Controller akkor, ha nem illeszt be előre flow

bejegyzéseket az eszközök Flow táblájába. Ekkor, ha olyan csomag

érkezik egy OpenFlow switch-hez, amely nem illeszkedik egyetlen

Flow tábla bejegyzésre sem (mert üres), a switch letárolja a

memóriájában a csomagot, a fejlécét pedig elküldi egy üzenetben a

Controller-nek, amely a fejléc információk szerint eldönti hogy milyen

flow bejegyzést kell készíteni a csomag megfelelő továbbításáért és

ezt visszajuttatja a switch-hez, valamint arra utasítja a switch-et hogy

a letárolt eredeti csomagot küldje ki a szabály szerint.

Proaktív vs Reaktív Operációs mód

2015.05.14.

14

A Controller-ekkel szemben támasztott legfőbb elvárások:

•A hálózat állapotának nyilvántartása és vezérlése (Database)

•Magasszintű modell ami a hálózati eszközök közötti kapcsolatokat

leképezi, szabályokat deklarál

•REST API ami a Controller által nyújtott szolgáltatásokat elérhetővé

teszi az alkalmazások számára (Northbound API)

•Biztonságos TSL/SSL csatorna fenntartása minden egyes eszközzel

•Eszköz, topológia, szolgáltatás felderítő és útvonalválasztó modul

SDN/OpenFlow Controller-ek

Kezdetleges OpenFlow Controller-ek

NOX:

•Open source, Nicira networks fejlesztette ki

•C++ nyelven programozható, ezért gyors, hatékony (alacsony szintű hozzáférés)

•Hátránya hogy nehézkes a használata, erős programozási háttér kell hozzá

•Csak az OpenFlow 1.0-ás verziót támogatja

•Modulokat tartalmaz topológia felderítésre, metódusokat lehet regisztrálni bizonyos

eseményekhez.

•Egyetemi fejlesztők/kutatók körében volt elsősorban népszerű

POX:

•Open source, Nicira networks fejlesztette ki

•Célja egy fejlesztő/felhasználóbarát Controller létrehozása volt, ez részben sikerült

is, köszönhetően a Python programozási nyelvnek.

•Csak az OpenFlow 1.0-ás verzióját támogatja

•Újrafelhasználható modulok definiálására van lehetőség

2015.05.14.

15

Beacon:•Open source, David Erickson a kifejlesztője, célja kutatási projektek támogatása

•A Java programozási nyelvet használja, több platformon is képes futni

•Moduláris felépítésű, amelyek futás közben cserélhetőek. Jó pár előre megírt és

igen hasznos modult tartalmaz.

•Képes több-magos processzorokon párhuzamosításra, ezért jobb a teljesítménye

•Beépített webes felhasználói felülettel rendelkezik, ami nagy előrelépés volt.

Floodlight:•Open Source, Big Switch Networks által fejlesztett, 2012-ben,

•A Beacon Controller továbbfejlesztett változata.

•Ugyancsak Java alapokon, fontos előrelépés hogy REST API-n keresztül szinte

minden része vezérelhető, így elérhető az alkalmazások számára.

•Webes felhasználói felületet is tartalmaz

Kezdetleges OpenFlow Controller-ek

•Linux Foundation által koordinált, komoly gyártói háttértámogatást

élvez: Cisco, Juniper, IBM

•Ugyancsak a Java programozási nyelvet használja, ezért szinte

mindenhol képes futni

•Dinamikusan betölthető modulokat tartalmaz elődjeihez hasonlóan

•Ugyancsak REST API-n keresztül vezérelhető az alkalmazások által

•Tartalmaz egy Service Abstraction Layer-t, amely ún. pluginok által

képes különböző (Southbound) protokollok kezelésére (OpenFlow

1.0, 1.3, YANG, DOCSIS, PacketCable) és intelligens döntések

meghozatalára (mikor melyiket kell használni)

Egy fejlettebb OpenFlow Controller: OpenDayLight

2015.05.14.

16

Packet Flow

Software Defined Wide Area Network - Backbone

Egy valós példa: Google B4

2015.05.14.

17

A WAN kapcsolatokról általánosan elmondható, hogy drágák, ezért ha egy cég

előfizet egy szolgáltatónál X sávszélességre, akkor az a legszerencsésebb, ha ezt

amennyire csak lehet ki is használja.

A Google Adatközpontjait összekötő WAN linkek, az OpenFlow bevezetése előtti

átlagos kihasználtság 30-50%-os volt. Az OpenFlow bevezetáse után közel 100%-os

lett, aminek következtében jelentős anyagi megtakarításokat értek el (kevesebb

bérelt vonal szükséges).

A Google DC-k közötti WAN linkeken haladó forgalom 3 típusba sorolható:

-Hozzáférés felhasználói adatokhoz (kis % de nagy prioritás, kis latency)

-Távoli adattárházakban tárolt fájlok elérése (közepes %, prioritás, latency)

-Nagyméretű backup műveletek (nagy %, nagy latency tűrés, kis prioritás).

A fentiek figyelembe vételével, és annak tudatában hogy a Google teljesen saját

maga tud rendelkezni a DC-i között folyó forgalom szabályozásával, egy olyan

OpenFlow implementációval álltak elő, amely közel 100%-os kihasználtságot tud

elérni a WAN kapcsolatokon, amely jelentős költségmegtakarítást jelent.

Egy valós példa: Google B4

Hogyan néz ki mindez a

gyakorlatban?

2015.05.14.

18

Mininet

•Virtuális hálózati emulátor, nagyon jól használható egyéni fejlesztésre, oktatásra és

kutatásra egyaránt.

•Egy Mininet virtuális hálózat elemei:

•munkaállomások (host-ok)

•switchek

•controller(ek)

•a fentieket összekötő virtuális kapcsolatok (linkek)

•A munkaállomások standard Linux-ot futtatnak, a switchek pedig képesek az

OpenFlow protokoll használatára, amely az SDN-nel kapcsolatos kutatásokban

nagyon népszerűvé tette a Mininet-et.

•A beépített CLI interfész segítségével a felépített virtuális hálózat valós időben

menedzselhető

•A virtuális topológia felépítésére kétféle mód létezik:

•Beépített, paraméterezhető terminál paranccsal előre meghatározott (fa …)

•Vagy a Python API-n keresztül, tetszőleges topológia

•Forrás: www.mininet.org

Hogyan működik a Mininet

•Processz alapú virtualizáció segítségével tud számos (~4096) virtuális

hosztot és controllert futtatni egyetlen OS kernelen belül.

•Linux namespaces, kernel 2.2.26, segítségével különálló processzek saját

hálózati interfésszel, routing és ARP táblákkal rendelkeznek,

•A switchek és a host-ok virtuális ethernet interfészeken keresztül

kapcsolódnak

•A Mininet előnyei:•Gyors - Másodpercek alatt felépül egy virtuális hálózat

•Skálázható - Nagy méreteket tud szimulálni egyetlen PC, laptop…

•Olcsó hardveren is 2 Gbps-os sávszélesség elérésére is képes

•Könnyen telepíthető

•Olcsó és állandóan rendelkezésre áll

•Gyorsan újrakonfigurálható és újraindítható

•Valós, módosítatlan kódot futtat

•Könnyen csatlakoztatható fizikai hálózatokhoz

•Interaktív felületet biztosít (CLI)

•Wireshark segítségével könnyen nyomon követhető a virtuális forgalom

2015.05.14.

19

•A Mininetet legegyszerűbben úgy lehet elkezdeni használni, hogy a

www.mininet.org oldalról egy mindent tartalmazó Virtuális Gépet (VM)

le kell tölteni és elindítani, ami előre telepítve tartalmaz mindent

•A $-al kezdődő parancsokat a Mininet VM-en belüli terminálban kell

kiadni, míg a ’mininet>’ kezdetű parancsokat a Mininet CLI-ben.

•Az alap terminál parancs, a ’$ sudo mn’, egy két host-ból, egy

switchből és egy referencia Controllerből álló virtuális hálózatot hoz

létre.

•A ’$ sudo mn’ parancs kiadása után azonban lehetőség van különböző

parancssori argumentumokkal személyre szabni a virtuális hálózatot:

•--controller ref VAGY --controller=remote,ip=127.0.0.1,port=6633

•--mac

•--topo tree,depth=2,fanout=3

•--topo mytopo --custom ~/mininet/custom/mininet-topologia.py

Mininet gyorstalpaló

Mininet Python API

net = Mininet()

h1 = net.addHost( 'h1' )

h2 = net.addHost( 'h2' )

s1 = net.addSwitch( 's1' )

c0 = net.addController( 'c0' )

net.addLink( h1, s1 )

net.addLink( h2, s1 )

net.start()

CLI( net )

Ennek a módszernek is létezik többféle variánsa, attól függően hogy milyen

szinten van megvalósítva a Mininet topológia felépítése. Az alábbi 2

kódrészlet egy alacsony szintű és egy magas szintű módszer a topológia

felépítésére.

class SingleSwitchTopo(Topo):

"Single switch connected to n hosts."

def __init__(self, n=2, **opts):

Topo.__init__(self, **opts)

switch = self.addSwitch('s1')

for h in range(n):

# Each host gets 50%/n of system CPU

host = self.addHost('h%s' % (h + 1), cpu=.5/n)

# 10 Mbps, 5ms delay, 10% loss, 1000 packet queue

self.addLink(host, switch)

net = Mininet( topo=SingleSwitchTopo( 2 ) )

net.start()

CLI( net )

2015.05.14.

20

Mininet CLI parancsok

A Mininet CLI-be való belépés után az alábbi hasznos parancsok

állnak a rendelkezésre:•dump: csomópontonként részletesen kilistázza az interfészeket, IP címeket, PID-et, stb

•pingall: végigfut minden egyes csomóponton és meg ping-el minden egyes másik

csomópontot. Hasznos a csomópontok közötti általános hálózati kapcsolat

ellenőrzésére.

•iperf: két csomópont között elérhető sávszélesség tesztelésére

•dpctl: OpenFlow switch-ek flow táblájának manuális kezelése/lekérdezése

•link <host_A> <host_B> up/down: csomópontok közötti interfészek fel/le kapcsolása.

•xterm <host>: xterm ablak nyitása adott csomópontra.

•nodes: kilistázza a virtuális topológia elemeit

•net: kilistázza a topológia elemei között létező kapcsolatokat.

•<host_név> <parancs>: ezzel a formátummal tetszőleges host-on tetszőleges parancs

futtatható. Példa: ’h1 ifconfig -a’

Mininet Fa topológia (1)

2015.05.14.

21

Mininet Fa topológia (2)

Fa struktúrájú topológiát legegyszerűbben az alábi

$ sudo mn –topo tree,fanout=3,depth=3

paranccsal lehet létrehozni, azonban ekkor nincs lehetőség a core,

distribution és access linkek paramétereinek beállítására.

A következő példa egy ilyen Mininet hálózat felépítését ismerteti.

coreLink = {'bw':50, 'delay':'5ms'}

distrLink = {'bw':30, 'delay':'10ms'}

accessLink = {'bw':10, 'delay':'15ms'}

A topológia többi elemét pedig 3 darab egymásba ágyazott for ciklus

segítségével hozzáadjuk a self.addSwitch() és a self.addHost() függvények

segítségével. Ezen elemek összekötése a self.addLink() függvénnyel

történik, amely 3 paramétert fogad:

self.addLink(’mit’, ’mivel’, **coreLink | **distrLink | **accessLink)

Első példa: Layer 2-es Learning witch (reaktív)

2015.05.14.

22

Első példa: Layer 2-es Learning witch (reaktív)

Mi is egy Layer 2-es switch alap működési elve? Megtanulja a MAC címeket amiket lát és

ebből egy táblázatot épít amely alapján forgalmazza a csomagokat. Ha ebben nem talál

valamit akkor FLOOD-ol.

A POX Controller könyvtárában a Mininet VM-en erre két példa is található, az egyszerűbb az

l2_pairs.py néven található meg.

A megvalósítás lényege, hogy (switch, MAC cím) párokat képez le egy portszámra, amiket

eltárol.

Ha az OpenFlow switch olyan csomagot kap, amelyhez nincs Flow bejegyzése akkor ezt

elküldi a Controller-nek amely a következő logika alapján kezeli azt:

1.Megtanulja a portot a forrás MAC alapján

2.Megpróbálja megállapítani a cél port-ot a táblázata alapján

1.Ha sikertelen, akkor FLOOD-olja a csomagot.

2.Ha sikeres akkor kiküld a switch-nek két FLOW bejegyzést, amely az oda-vissza

forgalmat fogja engedélyezni a két MAC cím között. Valamint a FLOW bejegyzések

kiküldése mellett utasítja a switch-et hogy az eredeti bufferelt csomagot is küldje ki.

Második példa: Elosztott L2-es Tűzfal

2015.05.14.

23

•A fenti L2-es Switch példa kiegészítve egy új funkcióval. A Controller-nek egy

csv fileban meg tudjuk adni, hogy mely MAC címek nem kommunikálhatnak

egymással, létrehozva ezzel egy elosztott tűzfalat.

•Működése annyiban tér el, hogy a Controller a firewall-policies.csv fileból

beolvassa a MAC-eket és a flow táblába beírja az ezeket tiltó bejegyzéseket,

mindezt PROAKTÍVAN

•Ezután ha a mininet parancssorban egy pingall-t kiadunk akkor látható lesz,

hogy a le nem tiltott MAC-ek tudják egymás pingelni, a letiltottak pedig nem.

•A megírt Controller topológia független, mivel minden OpenFlow eszközre

beírja a megfelelő flow bejegyzéseket, viszont pontosan emiatt nem a lehető

legoptimálisabb, mert nem csak azokon a switch-eken tiltja le a MAC címeket,

amelyekhez ténylegesen csatlakoznak.

Második példa: Elosztott L2-es Tűzfal

Második példa: Elosztott L2-es Tűzfal

•A letiltáshoz egyszerűen olyan flow bejegyzést illeszt be, ahol az action=” ”

rész üresen marad, ezáltal eldobásra kerül minden arra illeszkedő csomag.

•A CSV formátuma:

id,forras_MAC,cel_MAC

1,00:00:00:00:00:01,00:00:00:00:00:08

2,00:00:00:00:00:02,00:00:00:00:00:07

A tűzfal modul működése:

1.CSV beolvasása induláskor egy tömbbe (SRC,DST) párokként

2.Amikor egy OpenFlow switch csatlakozik a Controller-re lefut a

_handle_ConnectionUP event, amelynek keretében proaktívan kiküldi az

eszközre a megadott MAC címeket blokkoló flow bejegyzéseket.

2015.05.14.

24

Második példa: Elosztott L2-es Tűzfal

Harmadik példa: Application Level Load Sharing

2015.05.14.

25

2015.05.14.

26

Köszönöm a figyelmet!

Kérdések?

2015.05.14.

27

Források, linkek

Coursera – SDN kurzus: https://www.coursera.org/course/sdn1

ONF: https://www.opennetworking.org/

Mininet: http://mininet.org/walkthrough/

Google B4 paper: http://cseweb.ucsd.edu/~vahdat/papers/b4-sigcomm13.pdf