Z VirtlabWiki
Pokyny k vypracování
- Doplnit do GUI:
- dát k dispozici seznam všech probíhajících rezervací s konektory (ze všech lokalit), na které se uživatel může potenciálně připojit (vyfiltrováno přes ACL). Konektory uživateli zobrazovat podle jejich logického pojmenování v log. topologii. ACL uchovávat asi v databázi (ResID x ConnID x ACL regexp)
- pro dotazy mezi lokalitami využít SOAP API. Lokalita, ze které se iniciovala rezervace, bude umět pro zadané ResID poskytnout aktuální namapování konektorů (s čím jsou spojeny, ať už vedou do vlastní nebo do cizích lokalit) + interval platnosti ResID
- možnost zobrazit si konektory konkrétní topologie vybrané z tohoto seznamu
- možnost zobrazit si mé konektory a přiřadit k nim připojené konektory z jiných paralelně existujících topologií
- online informace uživatelům, kdo a čím se napojil/odpojil na konektory jejich rezervace
- při rezervaci topologie možnost stanovit komu bude dovoleno připojit se na konektory rezervované topologie (asi regulárním výrazem na login jméno, lokalitu, možná již využít nový systém skupin)
- Do vybavení.xml definovat v každé lokalitě několik konektorů s interface typu serial (sint) a Ethernet (eint)
- Vytvořit modul tunelovacího serveru přijímající provoz pro rozhraní cint a sint.
- Použít CLI tunelovacího serveru pro definici (časově omezeného) aktuálního propojení konektorů.
- Možná pouze použítexistující příkaz redir. Rámec putující po cestě
R1:e1@L1 - c1:eint1@L1 - c2:eint2@L2 - R2:e2@L2
- se bude směrovat neustále podle cílového rozhraní do správného modulu tunelovacího serveru příslušné lokality (takže vždy projde dovnitř a ven modulu konektoru pro každý konektor)
- Abychom mohli konektory vzájemně propojovat normální položkou v RedirectTable, zavedeme u každého konektoru pseudointerface iint vedoucí do Internetu. Nebude ve vybaveni.xml, aby na konektory nikdo nenapojoval více než jednu linku. Pokud bude mít provoz z konektoru odejít zase na konektor, doplní tunelovací server jako zdrojový i cílový interface řetězec iint. Modul konektorů v tunelovacím serveru zaregistruje rozhraní iint jako další rozhraní, které umí obsluhovat.
- Další komentáře
- Zvážit možnost implementace konektoru na Internet (parametrizovatelná port-forwardning komponenta s jednou veřejnou adresou ?)
- Zamyslet se nad problémem možných smyček v topologii vzniklé propojením konektorů (asi nevadí, v lokálním případě také řeeeno jen rate limitingem na VLMUXu a přirozeným omezením kapacitou tunelovacího serveru)
- Optimálně by měly být použité fyzické konektory mapovány tak, aby byly ze stejné lokality jako prvek, kam je konektor v log. topologii) napojen. Toto ale bude řešeno v mapovacím algoritmu. Cílem je zajistit, abychom provoz mezi dvěmi prvky v téže lokalitě spojenými konektory neposílali přes fyzické konektor namapovaný do jiné lokality.
