Jak ten switch/router funguje (4) – Chassis s packet-based CLOS fabric

Část 4 z celkových 6 v seriálu Jak ten switch/router funguje

Zajímá vás, co se děje uvnitř vašeho switche nebo routeru? Nabízím pohled síťaře, bez hlubšího porozumění elektronice, na síťový hardware. Co se děje v packet-based CLOS fabric chassis?

Dnes se zaměříme na jednodušší typy moderních chassis – tedy postavené na paketovém back-plane, ale CLOS architektuře (ne jen jeden/dva crossbar aka supervisor, ale fabric pole) a využívající jednoduché metody doručování paketů a replikace. V příštím díle se pak pustíme do high-end core switchů využívajících virtuální výstupní fronty (VoQ), masivní buffering, cell-based CLOS a tak podobně.

Příjem paketu na vstupní kartě

Vraťme se na okamžik k našemu prvnímu dílu a to byly kroky zpracování paketu. Prvních několik zůstává beze změn – parsing, L2 lookup, L3 lookup i ACL/QoS jsou stejné. Pak v jednočipovém SoC dochází k frontování a je to snadné, protože odchozí port je na stejném ASIC a paket ve stejné paměti. Tentokrát ale destinace bude na jiné kartě. Využijeme in-flight buffer a snažíme se co nejdříve paket doručit do cílové karty. Pro případ nějaké blokády na fabric je vhodné mít alespoň malé vstupní buffery na čipu.

Modifikace paketu

V jednoduchém SoC jsme v rámci zpracování pracovali s metadaty a tyto zapsali do samotného paketu v rámci jeho odesílání (před ACL na výstupu). V případě našeho paketového chassis ale část těchto metada ztratíme, takže dosavadní modifikace provedeme ihned. Multicastové pakety v tomto kroku modifikovány nejsou.

Odeslání do pole fabric čipů

Použití paketového odesílání má řadu výhod a nevýhod. Mezi zásadní výhody patří cena řešení – systém je z jistého pohledu takovou LANkou v krabici a nevyžaduje tak složité řízení provozu end-to-end mezi kartami (tokeny a podobně). Výhodou jednoduchosti je také relativně nižší latence zejména v oblasti menších paketů. Za nevýhodu lze považovat řadící zpoždění (serialization delay) – fabric čip funguje jako store-and-forward (viz minulý díl) – takže nejprve čekáme na nahrání celého paketu do paměti vstupní karty, když je to hotové, tak do fabric čipu a pak ještě do výstupní karty. Při dlouhých paketech je latence relativně velká. Některá chassis mohou trpět ucpáním v přední řadě (Head of line blocking). Je to, jako když vám na semaforu svítí šipka doprava, ale auto před vámi potřebuje rovně a není tam zvláštní odbočovací pruh. I když doprava je volno, díky autu před vámi nemůžete jet. Tohle se může stát v okamžiku, kdy je odchozí karta hodně zaneprázdněna a paket na vstupní kartě čeká a drží tak za sebou jiné. Navíc mechanismus volby fabric čipu nebývá nijak sofistikovaný – jde například o hash podobnou té v linkové agregaci. No a jak dobře víme, jedna session může být intenzivní a jiná ne, takže distribuce přes fabric není ideální. V různých systémech se používají různé metody, jak vliv těchto efektů snížit. Je to jednak overspeed na fabric (ten tiká rychleji a má větší propustnost, než je potřeba), dále flow control na fabric linkách, inteligentní flow-control na fabric s možností pře-hashovat co kudy poteče a tak podobně. Jak poznáme příště, VoQ (a ideálně cell-based) systémy jsou v tomto ohledu výrazně lepší.

Multicastová replikace v jednodušších (ale moderních) systémech funguje na principu replikace ve vstupní kartě na všechny výstupní karty s příjemci. Tedy pokud jsou příjemci na 3 kartách, bude paket do fabric odeslán třikrát, jednou pro každou kartu a ta zajistí další replikaci na porty.

K paketu je následně přidána krátká interní hlavička, na základě které bude fabric čip posílat dál. Nechceme na fabric dělat složité parsování a tak podobně. Na vstupní kartě je synchronizovaný FIB a MAC table s údaji o výstupním portu ve formátu karta:port a taková hlavička se předřadí paketu. Právě schopnost synchronizovat tabulky a globálně adresovat je důležitá i pro metody virtualizace, jako je HP IRF a jiné podobné. Není to sice úplně totéž, ale v zásadě tyto technologie fungují jako rozmontované chassis.

Výstupní parser

Jakmile je paket doručen na výstupní kartu, provede se jeho velmi rychlé parsování, tedy extrahují se důležité informace z interních i běžných hlaviček (L2, L3, L4, …).

Výstupní lookup

Jde o poslední komponentu, která je ještě odlišná od jednoduchého scénáře SoC (jeden čip). Provede se lookup čistě na základní interní hlavičky, která obsahuje všechny potřebné informace (na jaký port a VLAN poslat, případně zda replikovat a jak). Díky tomu není nutné znova provádět L2/L3 lookup (MAC table, LPM).

Výstupní scheduler

Tímto jsme se ocitli v části systému, která už je stejná jako na začátku našeho seriálu. Výstupní scheduler má za úkol uložit celý paket do bufferu a to buď do privátního pro port/frotu a pokud je zaplněný (a nastavení délky fronty to ještě umožňuje), tak do sdíleného prostoru. Scheduler je rovněž schopen replikovat pakety v případě broadcast/multicast na jednotlivé porty.

Pak už ve zpracování pokračujeme modifikátorem (pokud je třeba provést další změny v paketu), následuje výstupní politika (ACL) a paket nám odchází.

Shrnutí

Dnes jsme si prošli scénář levnějšího typu chassis postaveného na paketovém backplane – podobnou architekturu najdete prakticky u všech výrobců. Výhodou je perfektní výkon, nízká latence a dobrá cena. Architekturu můžete najít i v menších prvcích (1U/2U), pokud je tam potřeba dosáhnout vyšší hustoty portů, než umožňuje jeden ASIC (ale v takových případech se nejčastěji aplikuje pokročilejší metoda s VoQ). Nevýhodou tohoto systému je potenciální HOL blokace (byť jsou metody, jak pravděpodobnost snížit), obtížně predikovatelná latence, potenciálně neefektivní využití fabric (špatné rozhodnutí na který co poslat). Vstupní karta odesílá pakety bez toho, aniž by tušila, jak to dopadne (tedy neví v jakém stavu je odchozí port/fronta) a může se tak stát, že se pakety přenáší přes fabric zbytečně (protože se na konci stejně zahodí). Klíčové jsou v tomto scénáři fyzické buffery na výstupu, kde paket čeká na obsloužení – buffery na vstupu jsou využívané minimálně. Replikace pro multicast probíhá na úrovni kopírování ve vstupní kartě pro výstupní karty a ty pak pro výstupní porty (tohle bude příště jinak, uvidíte). Platí také, že systémy tohoto typu mají spíše malé buffery, které jsou přímo na čipu.

Dramatické cenové výhody a výborný výkon dělají z této architektury velmi oblíbenou volbu pro páteřní sítě v campus, agregační chassis velkých datových center a core menších datových center.

V příštím díle se podíváme na to, jak se to dá dělat opravdu krásně – cell-based fabric s virtuálními výstupními frontami (VoQ).

Series Navigation<< Jak ten switch/router funguje (3) – BufferyJak ten switch/router funguje (5) – Chassis s cell-based CLOS fabric a VoQ >>
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ší [...]
  • 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í [...]
  • 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 [...]

No Comments Yet

Napsat komentář

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