Propojení systému Virtlab s cizími systémy

Z VirtlabWiki

Interfacing s cizími systémy

Zde diskutujeme integraci s cizími systémy, které nemají charakter množiny volně dostupných a na požádání vzájemně kombinovatelných prvků, dostupných přes společné (vnější) rozhraní našeho standardního tunelovacího a konzolového serveru, mazatelné mazacím serverem a individuálně rezervovatelné našim rezervačním serverem (všechny zmíněné servery v instalovány v cizí lokalitě a dále napojeny, popř. vnitřně upraveny podle potřeb daného cizího systému).

Pro řízení na logické úrovni můžeme použít (do cizích lokalit implementovat) SOAP API řídících serverů lokalit

Typy/charakter systémů, které můžeme potenciálně chtít integrovat

• Systém s neměnnou topologií složený složený z více samostatných síťových prvků
  • může být plně izolovaný nebo mít definována síťová rozhraní, jimiž se bude propojovat s dalšími částmi distribuované laboratorní topologie (chovat se jako enkapsulovaná entita s několika rozhraními)
• Rezervoár samostatných zařízení, které jsou k dispozici s definovanou konfigurací v definovaných časech
  • mimo tyto časy si je případně vlastník používá k čemu chce
• ... co ještě ?

Definovat zacházení s typy rozhraní (L2 rámců), o nichž nemáme zatím potuchy (umíme jen interface typu Ethernet a Serial)

• Mapovací alg. zatím chápe jako propojitelné rozhraní "stejného typu" (máme Serial a Ethernet). Tunelovací servery kompatibilitu neřeši, pošlou rámec tam, kam jsou nakonfigurovány. Tím se mohou na rozhraní při nevhodné konfiguraci dostávat i nesprávné typy rámců (což nevadí).
• Možná "vyčistit" definici typu rozhraní ne na Ethernet/Serial, ale podle typu rámce - linkového protokolu, OSI RM L2 (L1 rozhraní neřešit, je enkapsulována za tunelovacím serverem)
  • Při tom vzít v úvahu Serial porty na způsob Cisco směrovačů, které umí několik typů rámců - rozhraní tedy definovat výčtem L2 protokolů, které umí

Implementace proxy tunserveru na hranici cizího systému, který se bude jevit jako standardní lokalita. Proxy tunserver bude směrem do Internetu (k ostatním lokalitám Virtlabu) používat standardní Virtlabovou UDP enkapsulaci, pro směr do cizího systému jeho vlastní,

Příklad integrace pro systém s fixní topologií:

Zavedeme speciální typ prvku, který bude obalovat celou cizí topologii s interfacy, která topologie poskytuje ven. V konfiguraci definujeme, že tento prvek je 1x k dispozici v lokalitě cizího systému. S tímto prvkem pak budeme v logických topologiích normálně pracovat a mapovat jej na tuto jedinou jeho instanci. Toto neřeší problém přístupu na konzoly jednotlivých prvků cizí topologie (kompozitní prvek by měl jen jednu konzoli jako každý jiný prvek). Šlo by řešit proxy konzolovým serverem, který by po přihlášení dovolil výběr konzoly konkrétního prvku (menu + rozvětvení).

Přemosťováni datového provozu mezi laboratorní síti a cizími sítěmi

• Implementace VPN serveru jako modulu Tunserveru.
• Od připojovaných L2 VPN tunelů dynamicky vznikají pseudokonektory, ty může uživatel již standadními prostředky propojovat s jinými konektory
  • VPN připojení budou uživatelé směřovat na VPN server své domovské lokality
  • Pseudokonektory se budou pojmenovávat podle IP adresy a portu na straně externího systému, ze kterých vede VPN tunel (např. 110.1.2.3#10000@ostrava)

Alternativně by šlo řešit i vlastním (proxy) tunserverem na straně externího systému a přenosem datového provozu již pomocí standardního protokolu mezi tunservery, ale toto řešení by vyžadovalo, aby na straně externího systému (alespoň formálně) existovala lokalita Virtlabu. Do ní by byl příslušný tunserver zařazen (a byl programován z ostatních lokalit)

Konkrétní příklad: Integrace s BGP modulem systému Edinet

• Integrace metodou začlenění externího systému enkapsulovaného jako pseudozařízení DO Virtlabu.
  • Momentálně speciální případ bez síťového provozu k Virtlabu, jen využití CS a RS
  • Existující BGP úlohu nutno rozšířit, aby z enkapsulovaného systému vycházely síťová rozhraní
• Implementace proxy CS, RS (kooperace mezi rezervačními systémy) a TS