Malá učebnice OpenFlow (6) – porty

Část 6 z celkových 15 v seriálu Malá učebnice OpenFlow

V minulém díle jsme narazili na zvláštní port s názvem NORMAL. OpenFlow porty nejsou jen fyzické … jaké všechny existují?

V dnešním díle se podrobněji seznámíme s OpenFlow porty. Tyto se v rámci programování prvku využijí především na to, abychom nastavili kam chceme nějaké typy paketů posílat. Tak například chceme říct: pokud přijde paket z tohoto fyzického portu, má takovou IP, takový EtherType a TCP port je 80, pak ho pošli na OpenFlow port X. Tím může být samozřejmě skutečný fyzický port, ale i spousta dalších věcí. Dále označení těchto portů získává kontroler v rámci Packet_In události, tedy prvek může kontroleru poslat paket, který odchytil v síti, a k němu přidat informace o portu. Stejně tak kontroler může vygenerovat libovolný paket a do prvku jej vstříknout (Packet_Out) a označit, kterým OpenFlow portem má odejít. Zdá se tedy, že porty jsou opravdu důležité, že?

Fyzické porty

OpenFlow samozřejmě podporuje klasické fyzické porty identifikované číslem (32-bitové ID), které musí být unikátní pro danou instanci (z pohledu OpenFlow je zařízení označováno jako Datapath a může to znamenat celý prvek, ale i jeho virtuální kousek, například jen jednu VLAN, ve které je OpenFlow zapnuté). O portech se udržuje jejich konfigurační stav (administrativně vypnuto, smí pouze přijímat, smí pouze vysílat nebo je administrativně zapnuto), skutečný stav (nahoře, dole nebo blokován), jméno, hardwarová adresa, rychlost a další vlastnosti. Kromě toho OpenFlow podporuje informace o counterech na portech.

Využití v praxi? Pokud například ve VAN SDN kontroleru vypnete jeho hybridní chování (tedy mí sto výchozí posílání na NORMAL je tu CONTROLLER), tak ten vám vypočítá cestu sítí a end-to-end nastaví pravidla na forwarding přes skutečné porty. Nebo v případě OpenFlow v hypervisoru (HP VCN, HP DCN, VMware NSX, …) se nastaví pravidlo na port směřující do VM (ano, i ten je vlastně také virtuální, ale z pohledu OpenFlow jde o skutečný port).

Logické porty

Uveďme si příklad z klasického světa – linkovou agregaci. Jejím smyslem je vzít například dva fyzické porty a udělat z nich jeden logický. Jde především o to, že klasický switch (bridge) řeší broadcast tak, že po jeho přijmutí ho pošle na všechy porty kromě toho, z kterého paket přišel. Tím se ve stromové topologii dostane paket všude a přitom nedojde k jeho nekonečnému posílání. Toto chování tedy musíme u linkové agregace změnit – přijmutí broadcastu jedním členem nesmí znamenat jeho odeslání druhým členem (to je smyčka). Stačí tedy tuto funkci nedělat na fyzických portech vůbec a dívat se na to z pohledu logického portu, kde to pravidlo platí. Kromě toho prvek zajišťuje rozdělení zátěže (odchozí provoz) na členy logického portu (obvykle nějakou hash funkcí z definovaných hlaviček modulo počet členů). A to je ono – to je logický port. Můžete nakonfigurovat linkovou agregaci klasickým způsobem a pro svět SDN bude do kontroleru reportován logický port (například interface Bridge-Aggregation v případě Comware).

Druhým nejčastějším případem logického portu je tunel. Opět platí, že jde do entitu vytvořenou zcela mimo rámec SDN – z příkazové řádky, SNMP protokolem, skrze NETCONF, OVSDB či OF-CONFIG a tak podobně. Může jít o VXLAN, IPoGRE, MACoGRE, MPLS/VPLS LSP, MPLSoGRE a tak podobně. V klasickém světě byste vytvořili třeba GREoIPSec tunel a uvnitř spustili routovací protokol mezi pobočkou a centrálou. Prvek na pobočce by se tak naučil, že destination subnety centrály jsou dosažitelné skrz next hop, který je na druhém konci tunelu – paket tedy pošlou do tunelu. Totéž existuje i ve světě OpenFlow. Pokud to dané zařízení podporuje (například softwarový OpenvSwitch ano), můžete vytvářet pravidla jaký provoz kterým tunelem půjde.

V praxi to běžně uvidíte v HP prvcích s nastavenou linkovou agregací – aplikace jako HP Network Protector a HP Network Optimizer s tím fungují. V SDN v datových centrech se takto řeší pravidla pro odesílání do VXLAN (HP VCN coby Neutron v rámci HP Helion OpenStack) nebo MPLSoGRE (HP DCN).

Rezervované porty (speciální chování)

Existují rezervovaná čísla portů určená pro zvláštní události. Dvě už známe – porty NORMAL a CONTROLLER. Tímto způsobem můžete říct, které pakety chcete zabalit a odeslat do kontroleru pro další rozhodnutí (Packet_In mechanismus), a naopak které chcete zpracovávat lokálním control plane v prvku (tedy bez SDN). Minule jsme viděli hezký příklad – pokud je paket typu BDDP (SDN-based discovery topologie), odešli na port CONTROLLER, pokud jde o DHCP nebo ARP, pošli na NORMAL i CONTROLLER (tedy zpracuj běžným způsobem, ale odešli kopii do kontroleru) a pro všechno ostatní použij NORMAL. Jaké tedy speciální porty existují?

  • ALL – odešle paket na všechny porty kromě toho, z kterého paket přišel (a krom těch, jejichž administrativní stav je blokovat výstup). Kontroler tento port může využít například v rámci vstřikování BDDP do sítě (Packet_Out, tedy paket generovaný kontrolerem).
  • CONTROLLER – zabal paket a odešli do kontroleru. Pro každé pravidlo je možné určit, zda se paket odešle celý, nebo jen jeho část (například určitá délka v bitech) či dokonce jen hlavičky (v takovém případě je datová část paketu uložena v bufferu síťového prvku a do kontroleru je posláno jeho ID). Kontroler může na základě toho přeprogramovat síť nebo paket vrátit zase zpět třeba s modifikací hlaviček (včetně možnosti na něj odkázat přes buffer ID).
  • TABLE – specialita pouze pro pakety generované kontrolerem (Packet_Out) umožňující říci, ve které tabulce startovat (běžně přijaté pakety jsou vždy zpracovávány od první tabulky)
  • IN_PORT – port, ze kterého paket přišel (používá se u Packet_Out)
  • ANY – specialita pro některé OpenFlow pakety, nepoužívá se jako výstupní port (říká v zásadě „port neznámý“)
  • LOCAL – pošli paket do CPU zařízení, do jeho management plane (dá se použít například pro schopnost přijímání OpenFlow zpráv přímo z OpenFlow samého bez nutnosti použít non-OpenFlow VLAN)
  • NORMAL – zpracuj paket klasickým způsobem (tedy chovej se jako kdyby žádné SDN nebylo)
  • FLOOD – pošli paket na všechny porty (v rámci prvku nebo ve specifikované VLAN) s přihlédnutí ke klasickému pohledu (tedy ne na porty označené jako blokované, typicky Spanning Tree)

Porty LOCAL, NORMAL a FLOOD jsou z pohledu standardu nepovinné.

Dnes to bylo hodně o teorii, příště si zase něco vyzkoušíme v praxi.

Series Navigation<< Malá učebnice OpenFlow (5) – hybridní službyMalá učebnice OpenFlow (7) – ovládání API z Python >>
Similar posts
  • L3 a kontejnery bez overlay: Project ... Část 6 z celkových 6 v seriálu L3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico prakticky (1) – architekturaL3 a kontejnery bez overlay: Project Calico prakticky (2) – rozjezdL3 a kontejnery bez overlay: Project Calico prakticky (3) – BGPL3 a kontejnery bez [...]
  • L3 a kontejnery bez overlay: Project ... Část 5 z celkových 6 v seriálu L3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico prakticky (1) – architekturaL3 a kontejnery bez overlay: Project Calico prakticky (2) – rozjezdL3 a kontejnery bez overlay: Project Calico prakticky (3) – BGPL3 a kontejnery bez [...]
  • HPE Networking na GitHub – skri... Zaměstnanci HPE publikovali zajímavé skripty a celé knihovny jako open source v licenci Apache2, tedy k volnému použití včetně jakýchkoli modifikací. https://github.com/HPENetworking/scriptsonly Obsah se bude jistě dost rozšiřovat… přidejte si záložku [...]
  • L3 a kontejnery bez overlay: Project ... Část 4 z celkových 6 v seriálu L3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico prakticky (1) – architekturaL3 a kontejnery bez overlay: Project Calico prakticky (2) – rozjezdL3 a kontejnery bez overlay: Project Calico prakticky (3) – BGPL3 a kontejnery bez [...]
  • L3 a kontejnery bez overlay: Project ... Část 3 z celkových 6 v seriálu L3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico praktickyL3 a kontejnery bez overlay: Project Calico prakticky (1) – architekturaL3 a kontejnery bez overlay: Project Calico prakticky (2) – rozjezdL3 a kontejnery bez overlay: Project Calico prakticky (3) – BGPL3 a kontejnery bez [...]

No Comments Yet

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *