Malá učebnice OpenFlow (15) – tabulky s HP switche Comware

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

Představili jsme si koncept OpenFlow tabulek, pipeline a možnosti software. Dnes se už podíváme na realitu hardware – začneme s HP přepínači s Comware OS.

Merchant silicon

V portfoliu HP se dnes zaměříme na přepínače (nikoli routery – tam je OpenFlow v přípravě a flexibilita pochopitelně výrazně větší) postavené na merchant silicon a operačním systému Comware. Konkrétně bude popis sedět na prakticky všechny prvky s Comware podporující OpenFlow, tedy 5130, 5500 EI, 5500 HI, 5800 (do léta), 5900/5920/5930, 7900, 10500, 11900, 12500 a 12900. Velmi odlišné (pokročilejší) vlastnosti najdete u HP flexibilních čipů ProVision v prvcích 3800/2920/5400/8200 (o tom příště) a úplné nejdál budou v3 moduly (oznámené v příštím týdnu, informace hledejte na netsvet.cz – budete si moci sestavit pipeline jak chcete a přepisovat třeba i IP nebo TCP port přímo v hardware!). O všech těchto dalších možnostech v dalších dílech.

Pipeline

OpenFlow 1.3 umožňuje použítí vícero tabulek a dokáže tak lépe zhodnotit vlastnosti hardware. Začněme tedy naší cestu dvou-tabulkovou pipeline na té druhé – tou je tzv. Extensibility table, tedy TCAM. Jde o hardwarový komponent s úžasnými vlastnostmi – dokáže najít match v jediném taktu (asociativní typ paměti) a podporuje maskování (tedy můžete nastavovat žolíky – například rozsah IP adres, kdy může být posledních 8 bitů jakýchkoli). O hardwarových charakteristikách už jsme na netsvět psali (http://www.netsvet.cz/clanky.html/7_125-jak-ten-switch-router-funguje-2-tohle-neni-pamet-z-notebooku-ze-). Klasické využití TCAM je pro ACL, QoS klasifikaci, uRPF a rezervovaná část s větší kapacitou pro IP routing čili longest prefix match a tak podobně. Nevýhodou TCAM je obludná cena, vysoká spotřeba a nadměrná fyzická velikost (možná se vám spotřeba a velikost nezdá tak zásadní – potíž je, že chcete-li mít levný, ale přitom velmi výkonný prvek, je dobré nasadit SoC, tedy vše integrovat do hlavního čipu – spotřeba a velikost jsou v takovém případě extrémně limitující a použití externích TCAM má velký dopad na cenu, ale i rychlost, tedy hustotu portů na jeden čip…a potažmo drastický dopad na cenu stejně portového řešení v porovnání s SoC). TCAM je tedy zdroj vzácný a relativně malý (poznáte z kapacity ACL). U menších prvků se pohybuje v řádu několika tisícovek.

Kdyby prvek používal jen TCAM, mnoho by toho nezvládl. Pro host routes a ARP stejně jako MAC forwarding používá jiných zdrojů – hardwarově akcelerované SRAM HASH tabulky (u starších modelů to může být ještě BCAM) a tam už jsou kapacity podstatně veselejší zejména v případě MAC záznamů (řádově desítky tisíc). Hash tabulka ovšem neumí maskování, takže podporovány jsou pouze exact match a možnosti reakce na match jsou u tradičních čipů omezené – v zásadě opovídají tomu, co by switch dělal v běžné situaci (merchant ASIC je vyvinut pro switching/routing, ne pro flexibilitu).

IP-MAC table

Comware spojuje zdroje host routes + ARP + MAC forwarding do jedné OpenFlow tabulky s názvem IP-MAC. Do té lze ukládat VLAN a cílovou MAC ve velkých kapacitách (to odpovídá switching tabulce) a můžete specifikovat i destination IP, ale takových záznamů se vejde o dost méně (to odpovídá host routes / ARP). Nelze používat masky, jen exact match. A co se dá v případě match dělat? Modifikovat source i destination MAC, snížit TTL o jedničku, změnit VLAN a specifikovat výstupní port. Jsou vám takové operace povědomé? Reaguji jen na destination MAC a destination IP a modifikuji source a destination MAC? No jasně – to se přece dělá při routingu. Zmíněná omezení vychází z toho, že prvek má tyto zdroje připravené na switching a routing a neumí například modifikovat IP vrstvu v hardware. Poslední možností je zápis metadat (signalizace pro další tabulky) a skok do konkrétní další tabulky (nicméně to je jen jedna jediná možnost – extensibility table).

Extensibility table

TCAM tabulka má podstatně širší možnosti v match paketů – vstupní fyzický nebo logický port, VLAN, srcMAC, dstMAC, 802.1p, EtherType, srcIP, dstIP, DSCP, TCP/UDP porty a tak podobně. Tohle obvykle přesně odpovídá možnostem, které máte při tvorbě ACL nebo QoS politiky. Na match v této tabulce můžete reagovat všemi prostředky, jako v IP-MAC, tedy odesláním na vstupní port, modifikací zdrojové nebo cílové MAC nebo VLAN. Navíc můžete měnit hardwarově i další políčka, konkrétně 802.1p, DSCP a ECN bit. Dále se dají použít i další akce jako je odeslání do kontroleru, zahození paketu, poslání do meter (omezení propustnosti), zařazení do hardwarové fronty (QoS) nebo poslání do group. Této tabulky tedy využijete pro bezpečnostní operace (něco jako ACL v klasickém prvku), pokročilé rozhodování o směrování (něco jako LPM, PBR, TE v tradičním světě), QoS, paketovou replikaci (něco jako multicast nebo mirroring u běžného přístupu) a tak podobně.

Shrnutí – HP Comware prvky

Prvky s podporou OpenFlow 1.3 a Comware OS tedy nabízí fixní pipeline, ale už ne jen jedinou tabulku s TCAM, ale dávají k dispozici i forwardovací IP-MAC tabulku. Dostupné akce odpovídají běžnému chování prvku při swithingu a směrování.

Příště si ukážeme prvky s ProVision v2, tedy 5400, 8200, 2920 a 3800 – uvidíte, že vlastnosti budou ještě bohatší. Pak se podíváme na brzy uvedené v3 moduly a zakusíme unikátní flexibilitu, kde si můžete svojí pipeline sestavit na přání a přepisovat i takové části paketů, které běžný switch neumí a to přímo v ASIC.

Series Navigation<< Malá učebnice OpenFlow (14) – tabulky a OpenFlow pipeline
Similar posts
  • ArubaOS-Switch 16.02: IP SLA i pro Ar... IP SLA Ve světě směrovačů už poměrně dlouho existuje možnost monitorovat dostupnost a kvalitu spojení s využitím L3 protokolů. Můžete například z pobočky v pravidelných intervalech testovat dostupnost brány datového centra nebo klíčového serveru včetně měření doby jeho reakce (round-trip-time). Dá se také namířit dva routery proti sobě tak, že jeden se ptá a druhý [...]
  • OpenSwitch a Ansible automatizace pra... Minule jsme napojili naši virtuální topologii na Ansible a spustili náš první testovací Playbook. Dnes provodeme automatizovanou konfiguraci L3 fabric a otestujeme síť. Příprava konfiguračních podkladů Pro zprovoznění L3 fabric potřebujeme Loopback adresu, IP adresy na jednotlivých spojeních mezi prvky a nastavení BGP (autonomní systémy, peering). V našem Ansible prostředí si vytvoříme jeden YAML soubor, [...]
  • OpenSwitch a Ansible automatizace pra... V minulém díle jsme si rozjeli Lead-Spine OpenSwitch topologii s využitím Dockeru a skript nám vygeneroval také hosts file pro Ansible. Dnes se vyzkoušíme napojení na Ansible 2.1. Příprava Ansible a vašeho VM První co potřebujeme udělat je nainstalovat Ansible minimálně ve verzi 2.1. Postup najdete zde: http://docs.ansible.com/ansible/intro_installation.html Dále vyřešíme nastavení SSH klienta v naší [...]
  • 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 [...]
  • OpenSwitch a Ansible automatizace pra... Na stránkách netsvet.cz i cloudsvet.cz často píšeme o desired state konceptech v ovládání infrastruktury a o automatizaci. V tomto seriálu si ukážeme jak může vypadat moderní práce se sítí postavenou na OpenSwitch projektu, L3 BGP fabricu a Ansible automatizaci. Dnes začneme tím, že si sestavíme virtuální infrastrukturu. Jak získat Leaf-spine topologii několika OpenSwitchů? Pro testování [...]

No Comments Yet

Napsat komentář

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