HP Distributed Cloud Networking (5) – jak mluví kontroler? (VSC)

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

VSC (kontroler) komunikuje se svými kolegy (VSC v jiných datových centerech) i operátorskou sítí (PE router). Jak to dělá?

VSD je hlavním komunikačním prostředkem s řekněme nesíťovým světem – cloudovými nástroji, automatizačním software nebo s lidmi. VSC je pak zásadní komponentou pro síťovou komunikaci. Jak mluví?

MP-BGP

Rozšířený BGP protokol je přímo v srdci HP DCN řešení a využívá se jednak pro komunikaci mezi jednotlivými VSC (kontrolery), ale také pro integraci (doslova peering) s operátorskou sítí (PE router). Jak už bylo řečeno HP DCN nestojí na nekoordinovaném učení se, ale obsahuje inteligentní control plane (a tím je právě MP-BGP). Tímto protokolem se šíří informace o jednotlivých VM. Řešení je tedy schopné sdělit světu kde se daná VM nachází (například v jakém datovém centru, resp. pod dikcí jakého VSC) a současně držet izolaci jednotlivých tenantů.

HP DCN nabízí jak L2 tak L3 konektivitu, takže mu nestačí postarat se IP adresy (tak jako konkurenční L3 řešení), ale i MAC. V rámci MP-BGP se využívají E-VPN rozšíření pro L2 a L3. VSC tento protokol podporuje a každá VM tak je oznámena všem ostatním VSC (host route), takže dostupnost jednotlivých VM je známá pro celé řešení. Vzhledem k inteligentnímu control plane je možné propojit datová centra mezi sebou přímými VXLAN a dostupnost VM je hlášena BGP protokolem.

Stejný přístup platí pro integraci virtuálního světa s operátorským L3 MPLS/VRF a E-VPN/VPLS prostředím. Pokud PE router podporuje E-VPN, tak se opět použijí tato rozšíření. Pokud tam taková podpora není, dá se použít VPNv4 family (klasická L3 VPN), což obvykle stačí (požadavek na L2 konektivitu uvnitř virtuálního světa je velmi běžný, ale potřeba přímého mapování VM na virtuální L2 sítě typu VPLS/E-VPN zas tak častá být nemusí).

Jaký data-plane při MPLS či E-VPN do PE routeru?

Nejčastější operátorské řešení bude namapovat tenanta do jeho L3 VPN. Tedy provider poskytl VRF distribuovanou přes lokality zákazníka a jeho CE routery komunikují s PE routery operátora. Tak jak si zákazník vyměňuje IP informace o svých pobočkách, tak si jeho VM u providera povídají s PE routerem v datovém centru operátora (tedy virtuální svět, VSC, je defacto mutli-CE routerem pro jednotlivé tenanty). Pro tento případ nejsou MAC informace vůbec využívány. Z pohledu data plane se pro tento provoz sestaví GRE tunel mezi VRS a PE routerem a v něm MPLS. VRS tedy odstřihne L2 informace a přidá MPLS údaje a L3 paket posune do PE coby next hop (a tam už se informace přes MP-BGP propaguje na ostatní PE routery a potažmo se dostává až do CE routerů a pobočky tak mají přímou viditelnost na hostované VM).

Co v případě potřeby přímého napojení na L2 VPN? To je obtížnější. Z pohledu data plane by se jistě dalo použít VPLSoGRE (tedy rozepsáno jako L2oVPLSoMPLSoGRE), ale to naráží na omezení v control plane (VPLS používá klasický neinteligentní MAC learning, což se do řešení moc nehodí). Aktuální verze HP DCN 3.0 R2 funguje na principu zabalování L2 provozu do VXLAN, takže je potřeba mít podporu na straně PE routeru. Tedy rozbalení VXLAN a zařazení například do VPLS (tedy manuální nastavení) nebo podpora mapování VXLAN na E-VPN v rámci MP-BGP signalizace. Pokud PE router tuto funkci nemá, můžete mu L2 provoz naservírovat obyčejnou VLANou, tedy použít jiné zařízení pro rozbalení VXLAN a namapování do VLAN (manuální konfigurace). Jde použáít například prvek HP 5930 (řešení v hardwaru) nebo softwarová gateway pro bare metal server nebo jako VM (HP VRS-G o výkonu cca 5 Gbps jako VM, v pozdějších release 10-20Gb díky podpoře SR-IOV).

Jdu na jih

Směrem dolu, tedy k virtuální nebo fyzické infrastruktuře, používá VSC SDN kontroler jednak protoklu OpenFlow a také OVSDB. OpenFlow je nasazeno pro programování virtuálních routerů/switchů (VRS postavené na vylepšeném OpenvSwitch). Pokud VRS komponenta potřebuje sestavit nové spojení (dvě VM nebo VM mluvící do světa) a nemá patřičný záznam, kontroler situaci vyhodnotí. Prozkoumá svůj RIB (L2 i L3 záznamy) a podle pozice cílové stanice pošle do VRS náležitá pravidla (včetně odeslání paketu do VXLAN nebo MPLSoGRE tunelu pokud je potřeba). Současně jsou také zkontrolována všechna další pravidla jako je ACL, QoS nebo service chaining a výsledné OpenFlow programování tomu odpovídá (takže například dojde k redirect do jiného VXLAN tunelu pro zařazení služby typu IPS). Tímto protokolem se také kontroler dozvídá o existenci nové VM a jejím umístění (VSC potom páruje tuto informaci s globální politikou nastavenou ve VSD).

OpenFlow programuje pravidla v data plane (co kam poslat, jak změnit jakou hlavičku, jak si pohrát s QoS), ale OVSDB je používáno pro konfiguraci klasických konstruktů, tedy tunelů. Tímto způsobem kontroler požádá o sestavení VXLAN tunelu mezi dvěma body s příslušným identifikátorem (VNI) a to včetně podpory pro hardwarovou bránu, jakou je switch HP 5930. VSC inteligentně vytváří tunely mezi fyzickými servery, kde je to potřeba. Pakliže daný tenant (VNI) nemá na fyzickém serveru aktuálně žádnou VM, nebudou se z tohoto serveru vytvářet žádné tunely pro tohoto tenanta (bylo by to zbytečné). Vlastní pravidla co jakým tunelem se posílá už jsou ale v dikci OpenFlow. OVSDB tedy tunely vytváří, OpenFlow využívá.

Jdu na sever

Všechny politiky jsou součástí VSD, které komunikuje s VSC protokolem XMPP. Do této komunikace administrátor nijak nezasahuje, je součástí řešení. Kromě toho má VSC klasické prostředky správy routerů, například CLI, Takto se tedy do VSC připojít například přes SSH a je to způsob, jakým se nastavuje BGP peering na PE router a všechny další potřebné záležitosti.

Series Navigation<< HP Distributed Cloud Networking (4) – jak se plní RIB/FIB? (VSC)HP Distributed Cloud Networking (6) – jak tečou pakety? (VRS) >>
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 *