HP Distributed Cloud Networking (6) – jak tečou pakety? (VRS)

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

Co se děje s pakety v HP DCN řešení?

Interní provoz

Co se tedy stane, když chce jedna VM komunikovat s jinou? Dejme tomu, že jde o VM ve stejné subnetu. Pošle tedy ARP dotaz, ten se ale nedostane nikam dál, protože VRS ho zastaví a po konzultaci s VSC kontrolerem rovnou pošle odpověď (control plane udržuje ARP informace pro celou působnost VSC). VM tedy odešle paket na příslušnou MAC adresu, ale vSwitch (OVS) takové pravidlo nemá (klasicky řečeno nenašel to ve FIB). Pošle tedy informaci do VSC, který prozkoumá svou RIB tabulku (tedy zjistí na kterém vPortu je příjemce) a také politiky (ACL, QoS, service chaining). vSwitch nastaví patřičným způsobem a tento první paket v rámci flow odešle sám do cílové VM. Následující pakety už rozhodnutí kontroleru nepotřebují, VRS to zvládne sám.

A co když jde o provoz mezi subnety? To vůbec nevadí, VSC obsahuje kompletní RIB včetně L3 a zejména mapování tenant pravidel na VRF. Pokud tedy paket procházet má, VSC i v tomto případě nastaví FIB záznam ve VRS (vSwitch), který následně další pakety už řeší sám (tedy včetně potřebného přehazování hlaviček – stává se tedy routerem a to plně distribuovaným). Provoz je tedy routován přímo u zdroje, podobně, jako to dělá DVR v rámci HP VCN (OpenStack Neutron).

A jak se řeší situace, kdy je příjemce na jiném fyzickém serveru, tedy jiném vSwitch? To je čas nasadit overlay, konrétně VXLAN. Tento typ tunelu má mnoho výhod. Balí pakety včetně L2 (tedy lze použít i pro switching provoz uvnitř subnetu), používá náhodný UDP port (dobře kompatibilní s LACP/ECMP/TRILL technologiemi v underlay…na rozdíl od GRE nebo NVGRE) a má podporu i hardwarových bran v prvcích jako je HP 5930 (například pro připojení bare metal serverů, DPI platforem a dalších systémů). Každý provoz mezi fyzickými servery je zabalen do VXLAN tunelu včetně označení tenanta. Tímto způsobem je možné izolovat provoz aniž by bylo nutné zasahovat do fyzické infrastruktury (ta může být třeba i jen zcela plochá síť bez VLAN například postavená na TRILL nebo L3 síť s OSPF ECMP).

Externí provoz

VM posílá provoz směřující mimo svůj subnet na svojí výchozí bránu a tou je samozřejmě VRS. Pokud tam takové pravidlo už není, VSC lookup v RIB podle příslušnosti VM v doméně/tenant a namapované VRF. Protože jde o externí provoz, tak next hop bude mimo virtuální infrastrukturu na PE routeru. Jak se o tom HP DCN dozví? Je to MP-BGP protokolem, který běží mezi VSC a PE routerem. Abychom mohli projít libovolnou infrastrukturou je sestaven GRE tunel mezi VRS a PE routerem a uvnitř je spuštěno MPLS (tedy MPLSoGRE). Celou tuto funkcionalitu zvládne například v případě KVM (Linux hypervisor) VRS přímo v kernelu. Tímto způsobem se nejen VM dostane přes svojí výchozí bránu na PE router (a dál kam je potřeba klasickými postupy), ale navíc zůstane správná příslušnost (tedy mapování virtuálního světa na klasické VRF / L3 VPN technologie). Popsané řešení je tedy L3.

V případě požadavku na propojení operátorské L2 sítě (například VPLS nebo E-VPN) s virtuálním světem nelze použít MPLSoGRE, ale vyžadována je podpora VXLAN na PE routeru. Ten musí být schopen terminovat VXLAN a mapovat na příslušnou E-VPN. Druhou možností je ukončit VXLAN v jiném začízení a naservírovat rozbalený provoz PE routeru (který ho následně zařadí do dalšího zpracování jako E-VPN). K tomu lze použít hardwarovou bránu jako je HP 5930 nebo softwarové řešení nainstalované na fyzickém serveru (v krajním případě VM) – VRS-G (gateway).

A co v případě uzavřených řešení jako je VMware?

Potíž s VMware je v tom, že do kernelu nedostanete vSwitch dle vaší volby, což by byl hlavně OpenvSwitch (open source projekt paradoxně dnes po akvizicích vedený hlavně VMwarem), který je mimochodem důležitou komponentou NSX-MH (byť pro NSX-V a jiná klasická VMware před-Nicira řešení k dispozici není). HP DCN (podobně jako VCN a jiná OpenStack Neutron řešení) tak musí použít fintu – OVS ve formě VM. V řešení tak zůstáva klasický VMware vSwitch, ale každá VM je ve své vlastní VLAN. OVS ve formě VM má interface do tohoto vSwitch na portu, který je tagovaný ve všech VLAN. Tímto způsobem jedy OVS dokáže identifikovat jednotlivé VM (dle VLAN tagu, který je pouze lokálně významný). OVS pak implementuje všechno potřebné a na fyzickou síťovou kartu se dostane přes další klasický vSwitch (nebo SR-IOV).

Series Navigation<< HP Distributed Cloud Networking (5) – jak mluví kontroler? (VSC)HP Distributed Cloud Networking (7) – QoS >>
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 *