Integrace distribuované laboratoře počítačových sítí se simulátorem PacketTracer

Z VirtlabWiki

Verze z 07:38, 10. 4. 2009 Gry72 (Diskuse | příspěvky) ← Předchozí porovnání		Verze z 11:01, 17. 4. 2009 Kna054 (Diskuse | příspěvky) (→Otázky) Následující porovnání →
Řádka 2:		Řádka 2:
	* 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 ?		* 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 ?
-	* Pokud chci mezi dvojicí PT client - 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í ?	+	''- 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ží. Pak už se nejspíše odkazují jen na číslo linky na kterou to má přijít. Půjde nejspíše o číslo. Toto ověřím ještě později, prohlédnutím hlavičkových souborů dostupného frameworku.''
	== Základní filosofie návrhu ==		== Základní filosofie návrhu ==

---

Verze z 11:01, 17. 4. 2009

Otázky

• 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ží. Pak už se nejspíše odkazují jen na číslo linky na kterou to má přijít. Půjde nejspíše o číslo. Toto ověřím ještě později, prohlédnutím hlavičkových souborů dostupného frameworku.

Základní filosofie návrhu

• V každé lokalitě bude vedle Tunelovacího serveru (TS) také Packet Tracer Server (PTS), který bude obsluhovat napojení vzdálených Packet Tracerů (PT) na (fyzické) konektory v dané lokalitě
  • možná bude realizován jako modul TS
• Virtlab uvidí přípojná místa v simulované topologii ve vzdáleném PT jako standardní konektory (u nichž pouze bude fyzické jméno ztotožněno s logickým)
  • Jméno konektoru na straně PT bude ve formátu

DEVICE:INTERFACE#NETWORK_CLOUD@PT:identifikace_vzdáleného_PT

• Když tunelovací server zjistí, že má přeposlat data z konektoru do lokality se jménem začínajícím na PT:, předá rámec lokálnímu PTS
  • připomínka: definovali jsme, že PTS obsluhuje PT připojené na konektory v dané lokalitě, takže TS nebude nikdy muset posílat rámce na PTS cizí lokality
• Jednoznačná identifikace fyzického 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)
  • Mohlo by se použít 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 ResID
  • Bude se distribuovat (pro účely ověření spojení příchozího z PT) do PTS všech lokalit, které hostují konektory, kam se může chtít daný PT (v rámci své rezervace) připojit
  • PTS bude mít tabulku, který PT se připojil pod kterým heslem
• Připojování PT na konektory topologie se bude uživatelsky řešit stejně jako vzájemné propojování konektorů (Pavel Burda)
  • liší se pouze v tom, že (logické=fyzické) jméno konektoru na straně PT musí uživatel manuálně zadat
• PTS bude konvertovat logické struktury simulující v protokolu PT předávané rámce na reálné rámce (a zpět), na rozhrané PTS-TS budou předávány realné rámce