Integrace distribuované laboratoře počítačových sítí se simulátorem PacketTracer
Z VirtlabWiki
Obsah |
[editovat]
Otázky
[editovat]
Nezodpovězené
[editovat]
Zodpovězené
- Existuje nějaká možnost automatizovaného předání parametrů do PacketTraceru (parametry spojení na PT server, které se má navázat) ? Možná aspoň možnost specifikace parametrů při spouštění PT ?
- Zatím jsem takovou možnost neobjevil.
- Pokud chci mezi dvojicí PT klient - PT server vést více simulovaných spojení mezi různými prvky topologií simulovaných na serveru a na klientu, všechny budou sdílet jedno společné TCP spojení ? V předávaných datových strukturách reprezentujících simulovaný provoz je vždy určeno rozhraní prvku ze kterého rámec letí a do kterého letí ? V textové formě zahrnující vždy jméno obláčku, jméno prvku a jméno rozhraní ?
- Ano pokud bude více simulovaných spojení jdoucí přes jeden MU (Multiuser) obláček, tak vše chodí přes jedno reálné TCP spojení. To rozhraní je podle mě ve zprávách předáváno, ale nikoliv textově. Na začátku si poví jaké linky mají a jakým prvkům náleží. Poté už se vše posílá jen pomocí těchto čísel linky.
- Potřebujeme v předávaných datových strukturách reprezentujících simulovaný provoz i jméno obláčku, nebo stačí jméno prvku a jméno rozhraní ?
- Podle mě to nebude potřeba. Jméno obláčku je důležité jen pro navázání spojení. Spíše by nebylo špatné zahrnout linku po které to má jít. Záleží však jestli něco takového budeme podporovat. Nebo se spokojíme s jednou linkou na spojení.
- Musí být PacketTracer Bridge stavový (kvůli spárovávání dotazů a odpovědí) ?
- Rozhodně nemusí PTB potřebuje pouze překládat rámce a odeslat je pořadí není pro něj v současné verzi potřebné.
- Funkce PT bridge na WAN portech (generování/čtení rámců HDLC, PPP, FrameRelay, ...)
- vše funguje v podstatě stejně jako na ethernetových portech. Nejprve je textově vytvořena hlavička rámce, kde je zapsáno co rámec obsahuje a pak jsou data rámce, které jsou přibližně stejné jako u reálných rámců.
[editovat]
Terminologie a zkratky
- PT - Packet Tracer
- PTS - Packet Tracer Server
- PTB - Packet Tracer Bridge
- TS - Tunelovací server
- Pseudokonektor - logický koncept - konektor připojený k (simulovanému) rozhraní na vzdálené straně
- vzniká dynamicky, v konfiguraci systému není definován
[editovat]
Daná fakta na straně PT
- Uživatel může v PT vytvořit několik multiuser obláčků (dále jen "obláčků")
- Do Virtlabu tedy z jednoho PT může vést více spojení
- Do každého obláčku může uživatel napojit více interfaces od více prvků (nebo i více interfaces od stejného prvku)
- konce linek z Virtlabu do PT je na straně PT je nutné obecně identifikovat jménem obláčku, prvku a jeho interface
- ale prvky mají per-PT jednoznačná jména, takže jméno obláčku možná nebude nutné, pokud není třeba v předávaných strukturách popisujících předávaný simulovaný provoz
- konce linek z Virtlabu do PT je na straně PT je nutné obecně identifikovat jménem obláčku, prvku a jeho interface
[editovat]
Požadavky na návrh
- Jednomu uživateli dovolíme připojení i více nezávislých PT
- Kompatibilita s filosofií a uživatelským GUI konektorů ve Virtlabu (Pavel Burda)
- Uživatel nejprve připojí svůj PT, tím dočasně vzniknou (pseudo)konektory reprezentující jednotlivá rozhraní připojená do obláčků
- Další propojování s konektory Virtlabu již standardním mechanismem propojování konektorů
- vzájemné propojování pseudokonektorů (PT-PT) patrně zakážeme, ať z Virtlabu nemáme PT hub
[editovat]
Funkce komponent řešení
[editovat]
Packet Tracer Server (PTS)
- Autentizuje příchozí žádosti o navázání spojení od vzdálených PT pomocí one-time passwords (OTP)
- OTP generuje řídící WWW aplikace Virtlabu a předává je PTS (asi přes databázi)
- Poskytuje seznam pseudokonektorů z připojených obláčků vzdálených PT (seznam exportovaných rozhraní simulovaných síťových prvků napojených do obláčků ve vzdálených PT
- Bude automaticky notifikovat řídící WWW aplikaci, když uživatel odpojí obláček vzdáleného PT (rozpojí se TCP spojení)
- zpracování patrně převod na obsluhu události manuálního rozpojení příslušných konektorů z GUI uživatetelem
[editovat]
Packet Tracer Bridge (PTB)
- Obousměrně převádí mezi strukturami popisujícími simulovaný provoz v PT a reálnými rámci/pakety/datagramy-segmenty
- Dle možností vyjít z existujícího prototypu od vývojového týmu PT, zavést modulární způsob pro postupné dodefinovávání nových protokolů
[editovat]
Základní filosofie návrhu
[editovat]
Způsob zapojování vzdálených PT do topologie ve Virtlabu z hlediska uživatele
Bude využit systém konektorů: z hlediska GUI uživatele Virtlabu půjde o připojování některého z konektorů jeho právě aktivní topologie ve Virtlabu s některým (pseudo)konektorem v topologii simulované v některém právě připojeném PT.
- Spoje od rozhraní simulovaných síťových prvků z PT (pseudokonektory) se budou napojovat na některý z konektorů některé právě aktivní topologie ve Virtlabu
- Virtlab uvidí přípojná místa v simulované topologii ve vzdáleném PT (interfaces síťových prvků připojených k některému "obláčku") jako (pseudo)konektory (u nichž bude jméno fyzicky namapovaného "prvku" ztotožněno s logickým
- možná do logického jména pouze nemusíme zahrnout některé části fyzického, nejspíše asi lokalitu
- GUI pro připojování PT může vypadat tak, že požádáme o vygenerování OTP pro připojení a zadefinujeme regulární výraz určující, kdo se smí na nově vzniklý pseudokonektor připojit. Mimo OTP bude uživateli vypsána i IP adresa PT serveru domovské lokality, kterou musí uživatel vzdáleného PT zadat při připojování.
[editovat]
Filosofie připojování PT k lokalitám Virtlabu
- Vzdálené PT se budou připojovat vždy na PTS své domovské lokality.
- Ta bude zbytku systému prezentovat právě aktivní pseudokonektory z připojených PT jako normální konektory, které pak uživatelé mohou chtít dále propojovat bez ohledu na fakt, že jde o pseudokonektor z PT
- tím mj. dosáhneme rozumné zátěže PT bridge každé lokality (každý PTB bude pracovat pro "své" uživatele).
- protože všechna logická propojení rozhraní prvků v PT na konektory prvků Virtlabu mohou takto jít jedním TCP spojením, nebude muset uživatel manuálně navazovat více spojení, pokud by chtěl různé prvky své topologie v PT připojit na prvky Virtlabu, které jsou v různých lokalitách (výhodné i za cenu trojúhelníkového směrování provozu na nedomovské lokality)
- Také tím zachováme princip transparence distribuovaného charakteru laboratorní topologie (fyzické umístění prvků rezervované topologie před uživatelem skryto)
[editovat]
Technická realizace obsluhy vzdálených PT
[editovat]
Jednoznačná identifikace vzdáleného PT
- IP adresa:port se nehodí, jsou dynamické a port se určí až když se skutečně z PT navazuje spojení na PTS. Uživatel může mít navíc PT na jiném počítači, než odkud má otevřeno WWW rozhraní Virtlabu
- může případně mít i lokální strukturu vzájemně provázaných PT
- Použijeme jednorázově generované heslo (OTP) vytvářené řídící WWW aplikací a sdělované uživateli v okamžiku, kdy chce připojit svůj PT do topologie
- výhodné by mohlo být do něj zabudovat UID přihlášeného uživatele, i kvůli prezentaci jména konektoru uživatelům. Pak i nějaké i pořadové číslo (možná čas připojení), kdyby chtěl jeden uživatel současně připojit více PT
[editovat]
Začlenění pseudokonektorů do TS
- Jméno pseudokonektoru z PT bude v tunelovacím serveru ve formátu
<DEVICE>@<SITE>:$PT$<PTOTP>#<INTERFACE>, kde
- $PT$ je identifikátor implikující zpracovávatelský modul v tunserveru (modul konektorů) a určující , že jde o (pseudo)konektor v Packet Traceru
- Modul konektorů bude mimo rozhraní EINT, SINT a IINT obsluhovat i rozhraní začínající na $PT$
- PTOTP (Packet Tracer One-Time Password) bude sloužit jako identifikace konkrétního vzdáleného PT, resp. jednoho jeho připojení v případě více obláčků
- bude jednoznačné OTP vygenerováno z řidící aplikace Virtlabu a zobrazeno uživateli v GUI Virtlabu, uživatel se tímto heslem manuálně připojí ze svého PT
- Všechna spojení pod jedním PTOTP povedou do stejného PT (byť přes jiné obláčky), v rámci něj jsou všechny síťové prvky dostupné přes tato spojení pojmenovány jednoznačně (zajistí konkrétní vzdálený PT)
- DEVICE a INTERFACE určuje rozhraní konkrétního prvku simulovaného v PT
- pokud to bude protokol přenosu zpráv vyžadovat, budeme muset do obecného formátu jména konektoru přidat ještě jméno obláčku, kam je INTERFACE prvku DEVICE připojeno; jinak budeme spoléhat na jednoznačnost jmen prvků v rámci instance PT
- SITE určuje, který TS provoz z/na konektory daného PT obsluhuje z hlediska zbytku Spojovače (samozřejmě prostřednictvím PTB a PTS)
- Bude to vždy TS domovské lokality uživatele, které svůj PT připojil.
- Tato domovská lokalita (její systém obsluhy konektorů) také zajistí, aby se konektory všech právě připojených PT nabízeny v odpovědích na SOAP dotazy ostatních lokalit na dostupné aktivní konektory (vč. "dotazů" lokality sama na sebe)
- zeptá se na akuální seznam připojených pseudokonektorů PTS
- $PT$ je identifikátor implikující zpracovávatelský modul v tunserveru (modul konektorů) a určující , že jde o (pseudo)konektor v Packet Traceru
- V každé lokalitě bude Packet Tracer Server (PTS), který bude obsluhovat napojení vzdálených PT uživatelů dané lokality
- bude přijímat spojení od PT, z nich extrahovat informaci o rozhraních připojených v obláčcích a vytvářet příslušné pseudokonektory
- ze spojení z PT bude číst popis simulovaného provozu a přeposílat jej na PTB (s označením od koho pro koho)
- z PTB přebírat popis simulovaného provozu (s označením od koho pro koho) a přeposílat jej do spojení k příslušnému PT bridge
- bude mít tabulku <socket_handle,OTP>
- možná bude realizován jako modul TS
- V každé lokalitě bude Packet Tracer Bridge (PTB), který bude konvertovat struktury popisující simulovaný provoz z/do vzdáleného PT na reálné rámce/pakety/segmenty-datagramy s příslušným obsahem a zasílat/přebírat je do/z lokálního TS (ten je bude forwardovat dále k laboratorním prvkům místní lokality nebo do některé vzdálené lokality)
- Může být součástí (modulem) PTS
- PTB může být výpočetně dosti zatížená komponenta. Možná by se vyplatilo mít možnost PTS+PTB fyzicky oddělit od TS na jiný stroj, v TS mít jen "lightweight" kód obsluhující konektory ze vzdálených PT přeposíláním na PTB a mezi TS a PTB si vzájemně předávat už enkapsulované rámce (UDP) ve formátu TS.
- (Pseudo)konektory na straně vzdáleného PT budou "patřit" do domovské lokality uživatele, který si napojení svého PT do laboratorní topologie vyžádal - tam (na dobu připojení PT) "vzniknou" - tj. budou se na dotaz prezentovat jako logické konektory "pseudorezervované pseudotopologie" která v dané lokalitě právě "pseudoexistuje"
- Provoz mezi nimi a prvky domácí i cizích lokalit půjde přes PTS, PTB a TS domovské lokality
- Pseudokonektory jsou zcela mimo mapovací algoritmus, vznikají a zanikají nikoli na začátku/konci rezervace, ale při připojování/odpojování PT. Proto se také nijak nemapují na (fyzické) konektory definované ve vybavení lokalit
- V TS se rozšíří modul konektorů, aby provoz určený na rozhraní prvku v PT (pseudokonektor), tj. na rozhraní s názvem začínajícím $PT$PTOTP$, předával buďto na PTB místní lokality. Podobně bude tento rozšířený modul přebírat provoz od lokálního PTB.
[editovat]
Ke zvážení
- Mělo by smysl udělat PTB běžící lokálně spolu s PT na vzdáleném stroji každého uživatele ? - ZATIM NERESIT
- Reálný provoz by enkapsuloval do UDP a posílal přímo TS (buďto přímo na lokalitu, kam vede příslušný spoj, nebo na TS domovské lokality, který by dále forwardoval provoz do cizích lokalit)
- Distribuovala by se spotřeba výpočetního výkonu
- Portabilní implementace v Javě nebo zvláštní binárka pro Linux/Win
- K tomu asi i lokální proxy PTS (ten by se napojoval na PTS domovské lokality)
[editovat]
