HP Distributed Cloud Networking (4) – jak se plní RIB/FIB? (VSC)

Část 4 z celkových 7 v seriálu HP Distributed Cloud Networking

Klasické sítě spoléhají v L2 na dynamické učení se a broadcast komunikaci. HP DCN nahrazuje ARP a DHCP provoz inteligentním control plane. Jak se tedy plní RIB a FIB?

Jak se plní RIB/FIB a řešení bez učení

Existující sítě potřebují ke svému životu broadcast provoz zejména kvůli dvěma protokolům – DHCP a ARP. Pokud klient nemá žádnou IP adresu a neví ani koho by se zeptal, nezbývá mu, nežli poslat do sítě broadcast (všesměrovou) zprávu. DHCP server (nebo DHCP relay) mu odpoví a zbytek komunikace už je unicast. Pokud stanice potřebuje cokoli poslat, musí správně vyplnit nejen IP adresu, ale i MAC hlavičky. Aplikace a uživatelé obvykle dobře znají IP adresy (nebo DNS jména, která lze bez broadcastu konvertovat na IP adresu zasláním správného dotazu), ale MAC vrstvu ne. Pokud jde o provoz v rámci subnetu, potřebuje stanice zjistit jaká MAC se skrývá za cílovou IP adresou. A mimo subnet je nutné kontaktovat výchozí bránu, ale o té máme obvykle k dispozici jen informaci o IP adrese (například z DHCP router option). V obou případech hledáme MAC adresu a použijeme ARP protokol, broadcastový provoz, kdy voláme do světa: „Kdo má tuhle IP?“ a její majitel (už unicastem) odpovídá.

Ve virtuálním světě datového centra jsme ale schopni informace získávat i jinak. IP adresa VM se dá obvykle vyřešit přímo politikou (v zásadě DHCP rezervací) a polohu VM známe těsně před spuštěním (VRS pro ni vytváří vPort do kterého směřuje vNIC, tedy virtuální síťovka VM). Totéž platí pro MAC adresu. Na rozdíl od běžné sítě, která je plně distribuovaná (a tedy nemá centrální informace o ARP), virtuální síť datového centra využívá SDN principů a tohle všechno ví. Na rozdíl od jednoduššího HP Virtual Cloud Networking (Helion OpenStack Neutron) a Helion CloudSystem, které stojí na klasických metodách (ARP broadcast apod.), má HP DCN přímo v control plane potřebná řešení pro ARP, DHCP a unknown unicast. ARP i DHCP odpovědi jsou generovány přímo ve VRS (s tím, že kdo k jaké VM jaká patří IP je do VRS distribuováno z VSC), takže do sítě se dotazy nedotávají. Unknown unicast provoz prakticky neexistuje, protože údaje v rámci jednoho VSC (kontroleru) jsou distribuovány všem VRS agentům ve formě L2 a L3 FIB (OpenFlow protokolem dle potřeby) a informace mezi VSC (datová centra, sály, pobočky) a také mezi virtuální sítí a operátorským světem (PE router) jsou synchronizována tradičním MP-BGP (L3 VPN/VRF a pro L2 informace E-VPN).

Propojení datových center

To je velmi důležitá zpráva ze dvou důvodů – větší efektivita uvnitř DC a možnost bez obav natáhnout řešení přes víc datových center. Proč ta efektivita? Pokud nasadíme overlay tunely (trubka vytvořená mezi dvěma IP uzly, tedy mezi fyzickými servery) pro každého tenanta, jak vyřešit broadcast a unknown unicast? Jsou v zásadě jen tři možnosti. Buď budeme replikovat pakety (kopírovat do všech potřebných tunelů typu bod-bod) v jednom centrálním uzlu (to je případ VMware NSX-MH) – obtížné z pohledu vysoké dostupnosti, škálovatelnosti a problematické řešení v kombinaci s hardwarovou akcelerací VXLAN v přepínačích. Druhá možnost (jak to dělá HP VCN, DCN i HP 5930) je head-end replikace, tedy ten uzel, který paket odesílá, zajistí jeho naklonování do všech tunelů – dobrá škálovatelnost a interoperabilita, ale samozřejmě každý broadcast síť zatěžuje (nevhodné mezi datovými centry). Třetí možnost je konvertovat kombinaci tenant+broadcast na per-tenant multicast (něco podobného se například používá v MPLS L3 VPN pod názvem Rosen draft). To se sice krásně efektivní, ale právě jsme vyměnili omezenou škálovatelnost VLAN (důvod pro VXLAN) za ještě omezenější kapacity multicastů (prvek s 4K VLAN je běžná a levná záležitost, ale prvek s 4K mutlicast group vůbec ne). S HP DCN je tedy o starost méně. A z toho vychází i onen druhý důvod. Na úrovni control-plane dochází k inteligentní synchronizaci stavů, nestojíme na principu náhodného učení. Proto s DCN můžete natáhnout bez obav VXLAN mezi datovými centry. Něco, co bych v řešení typu HP VCN nebo VMware NSX zatím nedoporučoval (respektive pouze v kombinaci s jiným inteligentním control plane mezi datovými centry jako je HP EVI nebo Cisco OTV … ostatně Cisco ACI to tak používá).

Series Navigation<< HP Distributed Cloud Networking (3) – politiky a ovládání řešení (VSD)HP Distributed Cloud Networking (5) – jak mluví kontroler? (VSC) >>
Similar posts
  • Moderní 10G v datovém centru s novou ... HPE tento týden oznámilo evoluční vývoj portfolia v oblasti data center 1U prvků s 10G/40G/100G technologií, konkrétně novou řadu 5940. Co je nového? Hardwarové vlastnosti Prvky přichází s novou generací 10/40/100 čipů, které umožnily mít nově prvky se 100G uplinky (a to hned šesti) a také přináší podporou nových vlastností jako je směrování VXLAN (předchozí [...]
  • OpenSwitch a Ansible automatizace pra... Posledně jsme si nastavili naší virtuální OpenSwitch leaf-spine topologii a vybudovali jsme BGP L3 fabric. Dnes si ukážeme více z životního cyklu s použitím Ansible – otestování sítě, vrácení odchylek do požadovaného stavu sítě a rolování změn. Jste líní číst? Mrkněte na video: Playbook pro testování sítě Ansible můžete použít i pro testování, že síť [...]
  • 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 [...]

No Comments Yet

Napsat komentář

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