Voor OpenFlow gebruik je twee apparaten:
1. Een controller
2. Een OpenFlow Switch
De controller is de control plane voor het netwerk en bepaald hoe verkeer geforward moet
worden, doormiddel van flows. Deze flows maak je op de controller zelf of met een
applicatie die via de zogenaamde "North Bound API" tegen de controller aan praat.
Een flow is een set van pakketten verzonden naar endpoints op basis van IP, TCP UDP/ports
Wow klinkt ingewikkeld! Daarom hier een voorbeeld van een flow in gescheven tekst :-) :
Als verkeer van source adres 1.1.1.1 komt en het naar port 80 wilt dan moet het uit port 5
van switch A. Heel makkelijk dus!
Een flow is dus gewoon een regel waarbij je bepaald verkeer "matcht" en insteld waar het
verkeer naar toe gestuurd moet worden.
Op het moment als je de super mooie flows hebt gemaakt worden deze verstuurd via het
OpenFlow protocol naar de switch(es). Omdat de switches zich South Bound van de
OpenFlow (logisch gezien tenminste :) ) controller begeven wordt er gezegd dat de
communicatie van de controller naar de switch via een zogenaamde "South Bound API"
gebeurd.
Dussss, communicatie van een applicatie waarmee je flows kan maken. (Bijvoorbeeld Cisco
Flow Manger waarmee we in de lessen hebben gewerkt) communiceerd dus via de North
Bound API met de controller via bijvoorbeeld REST. De controller stuurt vervolgens de
switches aan via OpenFlow doormiddel van zijn South Bound API.
Maaar wat doet de de switch vervolgens met de Flows die hij heeft gekregen van de
controller?
Hele goede vraag! (Want ik heb hem natuurlijk zelf gesteld, hihi). De switch zet deze flows in
zijn flow table, en gebruikt deze flows om verkeer te matchen en te bepalen waar een
inkomende packet bijvoorbeeld naar toe gefoward moet worden. Huh, maar is dit dan niet
vergelijkbaar met een MAC adres table? Jazeker, alleen een OpenFlow Flow (haha) kan
verkeer op veel meer vlakken matchen dan alleen het destination MAC. Ook kan een
OpenFlow Switch veel meer dan alleen maar simpelweg verkeer forwarden, het kan
namelijk het verkeer ook droppen en zelfs ook headers van packets aanpassen bijvoorbeeld
het destination IP address of source port(!)
Maar, maar vertel me meer! waar kan een OpenFlow Flow dan allemaal op matchen?
Nouuu op het volgende:
1) Switch input port
2) VLAN-ID
3) VLAN priority
4) Ethernet Source address
5) Ethernetdestination address
6) Ethernet frame type
Samenvatting door Sten van Harten. De plaatjes komen van de slides of uit het boek Software Defined
Networks: A Comprehensie Approach
, 7) Source IP address(es)
8) Destination IP address(es)
9) IP protocol
10) IP Type of Sevice (ToS)
11) TCP/ UDP source ports
12) TCP/ UDP destination ports
Ook bevat een Flow een actie, dus wat er met het verkeer moet gebeuren. De Flow actions
zijn als volgd:
- output:
het packet uit een port sturen, ookwel forwarden genoemd
- drop
het packet weggooien, naar de bitbucket
- enqueue
Het packet naar een bepaalde priority queue sturen van een port, dit gebruik je als je
QoS toepast in je OpenFlow netwerk.
- modify field
Een bepaald veld bewerken, zoals: VLAN-headers, Ethernet source en destination
address, IPv4 address, IPv4 source en destination address, TTL-field enzovoort.
Over de actie output moet ik nog iets meer vertellen, want je kan namelijk iets uit meerdere
verschillende soorten porten sturen! Binnen openflow zijn er namelijk ook speciale
“virtuele” poorten naast de fysieke poorten van de switch. Een OpenFlow switch kent vijf
verschillende virtuele poorten:
1. LOCAL
2. ALL
3. CONTROLLER
4. IN_PORT
5. TABLE
Deze verschillende virtuele poorten kan je zien op dit <sarcasme>superduidelijke, totaal
niet overweldigend plaatje hieronder</sarcasme>:
Samenvatting door Sten van Harten. De plaatjes komen van de slides of uit het boek Software Defined
Networks: A Comprehensie Approach
1. Een controller
2. Een OpenFlow Switch
De controller is de control plane voor het netwerk en bepaald hoe verkeer geforward moet
worden, doormiddel van flows. Deze flows maak je op de controller zelf of met een
applicatie die via de zogenaamde "North Bound API" tegen de controller aan praat.
Een flow is een set van pakketten verzonden naar endpoints op basis van IP, TCP UDP/ports
Wow klinkt ingewikkeld! Daarom hier een voorbeeld van een flow in gescheven tekst :-) :
Als verkeer van source adres 1.1.1.1 komt en het naar port 80 wilt dan moet het uit port 5
van switch A. Heel makkelijk dus!
Een flow is dus gewoon een regel waarbij je bepaald verkeer "matcht" en insteld waar het
verkeer naar toe gestuurd moet worden.
Op het moment als je de super mooie flows hebt gemaakt worden deze verstuurd via het
OpenFlow protocol naar de switch(es). Omdat de switches zich South Bound van de
OpenFlow (logisch gezien tenminste :) ) controller begeven wordt er gezegd dat de
communicatie van de controller naar de switch via een zogenaamde "South Bound API"
gebeurd.
Dussss, communicatie van een applicatie waarmee je flows kan maken. (Bijvoorbeeld Cisco
Flow Manger waarmee we in de lessen hebben gewerkt) communiceerd dus via de North
Bound API met de controller via bijvoorbeeld REST. De controller stuurt vervolgens de
switches aan via OpenFlow doormiddel van zijn South Bound API.
Maaar wat doet de de switch vervolgens met de Flows die hij heeft gekregen van de
controller?
Hele goede vraag! (Want ik heb hem natuurlijk zelf gesteld, hihi). De switch zet deze flows in
zijn flow table, en gebruikt deze flows om verkeer te matchen en te bepalen waar een
inkomende packet bijvoorbeeld naar toe gefoward moet worden. Huh, maar is dit dan niet
vergelijkbaar met een MAC adres table? Jazeker, alleen een OpenFlow Flow (haha) kan
verkeer op veel meer vlakken matchen dan alleen het destination MAC. Ook kan een
OpenFlow Switch veel meer dan alleen maar simpelweg verkeer forwarden, het kan
namelijk het verkeer ook droppen en zelfs ook headers van packets aanpassen bijvoorbeeld
het destination IP address of source port(!)
Maar, maar vertel me meer! waar kan een OpenFlow Flow dan allemaal op matchen?
Nouuu op het volgende:
1) Switch input port
2) VLAN-ID
3) VLAN priority
4) Ethernet Source address
5) Ethernetdestination address
6) Ethernet frame type
Samenvatting door Sten van Harten. De plaatjes komen van de slides of uit het boek Software Defined
Networks: A Comprehensie Approach
, 7) Source IP address(es)
8) Destination IP address(es)
9) IP protocol
10) IP Type of Sevice (ToS)
11) TCP/ UDP source ports
12) TCP/ UDP destination ports
Ook bevat een Flow een actie, dus wat er met het verkeer moet gebeuren. De Flow actions
zijn als volgd:
- output:
het packet uit een port sturen, ookwel forwarden genoemd
- drop
het packet weggooien, naar de bitbucket
- enqueue
Het packet naar een bepaalde priority queue sturen van een port, dit gebruik je als je
QoS toepast in je OpenFlow netwerk.
- modify field
Een bepaald veld bewerken, zoals: VLAN-headers, Ethernet source en destination
address, IPv4 address, IPv4 source en destination address, TTL-field enzovoort.
Over de actie output moet ik nog iets meer vertellen, want je kan namelijk iets uit meerdere
verschillende soorten porten sturen! Binnen openflow zijn er namelijk ook speciale
“virtuele” poorten naast de fysieke poorten van de switch. Een OpenFlow switch kent vijf
verschillende virtuele poorten:
1. LOCAL
2. ALL
3. CONTROLLER
4. IN_PORT
5. TABLE
Deze verschillende virtuele poorten kan je zien op dit <sarcasme>superduidelijke, totaal
niet overweldigend plaatje hieronder</sarcasme>:
Samenvatting door Sten van Harten. De plaatjes komen van de slides of uit het boek Software Defined
Networks: A Comprehensie Approach
