Virtlab:Virtuální spojovací pole/TODO

Z VirtlabWiki

Přejít na: navigace, hledání

Obsah

[editovat]

ASSSK

[editovat]

Problém null modemu

Na portech, ktere podle konfigurace Bazmeku nejsou nijak pripojeny, routery pokrikuji, ze port nabiha a pada. Je to zpusobeno tim nullmodemem - fyzicky je kazdy port diky spojce DTR-DSR, RTS-CTS trvale up, ale router na nem neslysi linkovy protokol. Potrebujeme piny na FPGA obvodu na spinani jeste i tech DSR.

Dle P.Sedlare snad zbyva na FPGA 40 volnych pinu. Navrh reseni (--P.G, 10:38, 21. 8. 2007 (CEST)): Muzeme zrusiy ty loopbackove dratene spojky DTR->DSR, RTS->CTS a na kazdy ze 16 (20?) konektoru (spolecne na piny RTS a DSR) bych privedl pres dalsi MAX jednu pacicku FPGA. Na tu bych poslal aktivni uroven jen tehdy, kdy by byl port s necim podle konfigurace spojeny.

[editovat]

Další možná rozšíření

  • Možnost použití různých taktovacích frekvencí pro různé dvojice propojených portů - HW modul do Tatabazmeku pro generování taktovacích frekvencí (DP)
  • Simulace flappingu WAN linek o zadaných parametrech - rozšíření SW hlavního procesoru (C)
[editovat]

Spojování LAN portů Ethernet - vlastní levný switch s podporou 802.1QinQ

Adam Janosek napsal:

Signamax
065-7840
http://www.signamax.com/index.php?typ=SXE&showid=322
novy firmware http://www.intelek.cz/product.jsp?artno=76107840

Martin Stankuš napsal:

Jak jsem to pochopil, otazka forwardovani QinQ spociva v podpore dostatecne dlouhych ramcu (odtud asi zvlastni MTU hodnota 1552 u chipsetu Realtek, o kterych jsme se bavili). Druha vec je vlastni podpora 802.1p/Q, kdy switch podle prvniho tagu dela QoS / VLANy. Chipsety Realtek podporuji oboji.

Moznosti bych videl asi takhle:

1.) Vypajet ASIC a trafka z nejakeho maleho switche, pridat konfiguracni EEPROMku a ze vseho toho postavit novy switch. Tato moznost mi pripada zbytecne pracna, znamena to kresleni oboustraneho plosnaku a nakonec by to taky nemuselo fungovat.

2.) Upravit nejaky maly SOHO switch. Neni to tak ciste jako vyrobit switch od zakladu, ale rozhodne je to snazsi. Jedna se vlastne o moznost, kterou se uz nejakou dobu zabyvam.

3.) Viceportove switch ASICy Realtek (16 a vice portu) podporuji vec zvanou RRCP (= Realtek Remote Configuration Protocol). Jedna se o silne proprietarni moznost konfigurace ASICu pomoci raw ethernet ramcu s ethertypem 0x8899. Existuje projekt OpenRRCP, ktery implementuje protokol RRCP ( http://openrrcp.org.ru/ ). HW uprava takoveho switche pro podporu velkych ramcu je stale nutna, ale neni (vetsinou) nutne dobastlovat EEPROM a hlavne je mozne nastaveni switche menit.

Jako nejdostupnejsi kandidat se zda D-Link DES-1016D ( http://www.alfacomp.cz/php/product.php?eid=1051400870UM0UHBBD , 1220 Kc). Problem trochu je, ze clovek nikdy nevi, co maji D-Linky uvnitr, dokud je neotevre. Model sice muze odpovidat, HW revize leccos napovi, ale uvnitr pak muze byt uplne jiny ASIC. V takovem pripade by podpora RRCP nemusela jit zapnout, ale aspon by melo byt mozne aplikovat variantu "2.)", tedy udelat z nej sice "dumb" switch, s podporou MTU 1552 resp. statickou definici VLANu a podobne.


...

Out-of-box toho neumi vic, nez bezny SOHO switch za par stovek; ale pomoci RRCP (=spec. eth ramcu) se rada veci, ktere obvykle umi az drazsi switche, da pozapinat a ulozit do EEPROM (btw na webu OpenRRCP se tvrdi, ze do EEPROM nelze ukladat nastaveni VLANu, coz se mi zda dost divne, chce to vyzkouset).

...

Krome toho, EEPROMka v tom switchi taky nemusi byt pripajena (podpora RRCP je trochu neoficialni, jak se zda... kde neni RRCP, neni potreba EEPROMka v vyrobce usetri). Je to magie, to chce proste ten switch videt otevreny. Bohuzel to taky znamena, ze nez se switch rozebere, tak nelze nic slibit. Uvnitr treba muze byt chip Broadcom, ke kteremu je nemozne ziskat dokumentaci (tohle je ale extremni pripad).

...

Pri nakupu je treba dat pozor na revizi switche (je to napsane vzadu na krabici). V pripade nezname revize se neda nic moc delat, snad jen risknout to a koupit. Co potrebujeme:

D-Link DES-1016D rev. D1, D2 --nebrat rev. C2

D-Link DES-1024D rev. C1, C3 --nebrat rev. B1

Take pozor, nebrat DES-1016(24)R+; vubec nevim, co jsou zac.


[editovat]

Unifikovaná tunelovací architektura

DP V.Bortlíka

  • Vyladit syntakticke drobnosti v konfig souborech (jneno lokality z /etc/sitename apod.]
  • (volitelná) možnost definice časové omezenosti každého nakonfigurovaného spoje (čas automatického rozpojení a odstranění z Redirect Table)
  • Implementovat možnost registrovat Observery k Redirect Table - těm bude vždy dáno vědět, když do konfigurace přibyde nebo ubyde nějaký spoj (včetně automatického odstranění od vypršení času platnosti spoje). Metoda Observer::changed(Observable* O, Aspect a) - aspect bude obsahovat redir XXX,XXX nebo noredir XXX,XXX
    • RedirectTable bude dědit z Observable (Observable má metodu registerObserver(Observer* o)
    • Z TrunkPortu zdědíme PSTrunkPort, který bude navíc obsahovat submodul PortSetteru (reimplementace z Perlu do C++), který bude přes SNMP nahazovat/shazovat aktuálně použité porty na C3550. Do konfigurace modulu se musí ke každému VLAN přidat i info o portu 3550, který se má shodit/nahodit a IP adresa managementu příslušné C3550 - viz současný spoje.conf. Submodul PortSetteru bude observerem RedirectTable a reagovat, když přibyde/ubyde spoj s Ethernetem v jeho lokalitě.
    • Implementace modulu Tatabazmeku (dokud nebudou S-E převodníky) - prázdký modul, který nebude odnikud přebírat žádné rámce, ale pouze bude observerem RedirectTable a při změně pošle příslušný příkaz na Tatabazmek s řídící konzolou na daném sériovém portu. Předpokládejme i možnost více bazmeků, takže konfigurace tohoto modulu by měla obsahovat info, na kterém fyzickém portu kterého bazmeku (a připojeného konzolou ke kterému lokálnímu sériovému portu) je který sériový interface lokálních routerů. Předpokládá se, že nikdo nebude zatím chtít propojit sériovou linku mezi lokalitami.
  • V budoucnu rozšířit třídu Port o možnost registrace objektu, který bude inspektovat a případně měnit nebo zahazovat některé rámce. Bude se to např. hodit pro vyřešení problému CDP duplex mismatch při transansparentnim presnosu CDP ramcu mezi zarizenimi, ktere jsou ve skutecnosti spojeny pres VLMUX.
    • Možná spojit s možnosti registrace objektu pro odposlech provozu (sonda).
[editovat]

Přechod na novou architekturu

  • Doimplementovat časovou omezenost spojů (rozmyslet, zda "od teď do určeného času nebo explicitně uvádět od-do)
  • Dopsat modul obsluhy Bazmeku a obsluhu Portsetteru modelem Observer-Observable
  • Provést výkonnostní testy implementace tunelovacího serveru. Možná částečná optimalizace kódu (vyhledávání v Map, použití objektovéh typu string apod.)
    • Na flood ping 0% ztratovost, iperf 30Mbps (trunk rozhrani k prvkum a rozhrani k Internetu sdileno na jendom NIC).
  • Zlikvidovat konfigurační servery
  • Vyrobit konfigurace pro nové tunservery v produkčním prostředí, nasadit nové tunservery
  • upravit activate.sh a generovadlo konfigurací - z globální mapy propojení spustit Vaškův aktivátor s uploadem relevantních částí popisu topologie do tunserverů lokalit (odstranění nalévání do Bazmeků a Portsetterů)
  • deactivate.sh zmizí (bude se dělat lokálně).
    • v prvni fazi pouzit i deaktivacni skript
  • Vyrobit modul ASSSK (observer redirect table), ktery pri zmene propojeni portu obsluhovaneho ASSSK posle spravny prikaz (connect/no connect) do spravneho ASSSK
    • Pri inicializaci posle do vsech ASSSK reset
[editovat]

Integrace uživatelského PC do laboratorní topologie s použitím VPN

[editovat]

Uživatelský pohled

  • V (logické) topologii budou definována Remote PC - nemapují se
  • Každý uživatel, který má úlohu rezervován (tj. včetně "kolegů") se může připojit jako některé z Remote PC
    • zobrazí se sada tlačítek "Connect as Remote PC[i]"
    • musí se ohlídat konflikty, aby se v jedné chvíli nepřipojilo více uživatelů jako jedno Remote PC
  • Omezení: Uživatelské PC se smí připojit do topologie v jedné chvíli nejvýše jako jedno Remote PC (nebudeme podporovat PC se dvěmi virtuálními NIC)
  • Fyzické jméno Remote PC se odvodí z logického (z logické topologie) přidáním suffixu lokality, do níž vede tunel
    • Ke kterému Tunserveru se remote PC bude vlastně připojovat ? Asi je to jedno, nejlépe tedy do domovské lokality uživatele.
[editovat]

VPN klient

  • VPN klient na klientské straně bude podporovat split tunelling
    • po připojení v OS vznikne nové virtuální síťové rozhraní, které bude uživatel konfigurovat pro vstup do laboratorní topologie
    • fyzické síťové rozhraní bude použito i pro pokračování v přístupu na řídící server Virtlabu a konzolový server
  • Parametry pro spuštění VPN klienta budou předány z tlačítek "Connect as PC[i]"
    • IP adresa VPN gateway lokality, kde příslušný prvek je
    • Identifikace Remote PC (+ jeho rozhraní), jako které se chce uživatel připojit - patrně formou attributu certifikátu, kterým se bude uživatel autentizovat - použití technologie One-Time Password (OTP) vyvinuté v Edinetu
    • ResID - předá se také v atributu certifikátu VPN serveru, aby se z nej dala napr. odvodit doba konce rezervace a tedy naplánovat nucené odpojení VPN klienta
  • Použití OpenVPN klienta (SSL VPN/TCP) a technologie jeho spouštění přes Java Webstart vyvinuté v rámci Edinetu,
    • Paralelně možno vyvíjet řešení s přímou integrací do Vaškova spojovacího pole úpravou existujícího opensource WebVPN klienta SSLExplorer (Applet SSL-Expl-Agent), nove Adito - nahrazení šifrovacího mechanismu našim enkapsulačním mechanismem
      • Spouštěl by se se stejnými parametry předanými z tlačítka jako OpenVPN klient
[editovat]

Serverová strana

  • Bude doimplementován modul VPNPort do Vaškova tunserveru
    • bude mít konfigurační tabulku se záznamy "RemotePC[i]:eth0,TunTap[n]"
    • bude přehazovat rámce mezi jádrem tunserveru a příslušným TunTap rozhraními, na kterých bude také poslouchat příchozí provoz
  • Na PC s Vaškovým Tunserverem poběží i OpenVPN server vybavený skripty spouštěnými při připojení klienta (z Edinetu-psal Adam)
    • Skripty zajistí autentizaci ověřením certifikátu a platnosti ResID, doplnění řádku s příslušným tuntap do konfigurační tabulky VPNPortu, naplánují v CRONu odpojení a odstranění z konfigurační tabulky VPNPortu při vypršení timeslotu rezervace

Alternativně můžeme bridgeovat tuntap rozhraní s vlan rozhraními a využit existujícího modulu TrunkPort (kterému bychom ale za runtime museli umět měnit tabulku připojení devices na VLAN (po promyšlení se jeví nevýhodné)

Pokud by L2 tunely na OpenVPN server neuměly vytvářet TUNTAP rozhraní, museli bychom řešit pomocí MAC adresy klienta + vymyslet omezení vzájemného bridgingu mezi klienty (aby např. mezi nimi neprocházely broadcasty).Dynamické tuntapy nevznikají. Rozumné řešení: Spouštět instance OpenVPN z Inetd.

[editovat]

Integrace modulu virtuálního rozbočovače

  • Nový typ prvku (virtuální hub)
    • nemapuje se (resp. mapuje se sám na sebe a jména rozhraní se do mapování přenesou)
  • Modul VirtualHubPort do TunServeru
    • Příjem rámce od TunServeru (odjinud nic přijímat nebude)
      • akceptuje rámce pro rozhraní port* (porty virtuálních hubů budeme označovat portN)
      • zjistí z RedirectTable, které další interfaces má cílový virtuální hub (mimo toho, odkud rámec přišel)
        • Nová metoda RedirectTable pro zjištšní všech záznamů, vyhovující regulárnímu výrazu (zde: jméno virtualhubu na levé či pravé straně spoje)
      • na zjištěné interfacy zařízení napojené na některý port daného virtuálního hubu rámec rozduplikuje (pošle TunServeru ke zpracování)
[editovat]

Držení (Ethernet) rozhraní UP

V některých případech se může (např. z důvodu šetření XEN instancí) hodit držet rozhraní síťového prvku (typicky routeru) UP a přitom na něj nic reálně nenapojovat. Můžeme to realizovat tak, že povolíme spojit kterékoli rozhraní s rozhraním NULL. Když tunserver bude mít poslat odněkud příchozí rámec na NULL, jednoduše jej zahodí, z NULL rozhraní nic chodit nebude. Jinak se ale spoj mezi reálným rozhraním a NULL rozhraním bude chovat normálně, tedy pokud půjde o Ethernet, bude pomocí PortSetteru po dobu platnosti spojení povolovat port VLMUXu, kam je reálné rozhraní připojeno, čímž se dosáhne stavu UP.

[editovat]

Přepsání Portsetteru do C

Integrovat Portsetter (momentálně realizovaný jako Bash script) v C pomocí SNMP knihovny.

[editovat]

Problém s fragmentací

  • Osetrit problem fragmentace obalujicich UDP datagramu mezi tunservery vzdalenych lokalit pri velkem MTU prenasenych ramcua moznost prehazeni paketu na virtualni p2p lince, v pripade ze by nam tuto sluzbu neposkytl IPSec tunel mezi lokalitami
[editovat]

S-E převodníky

Implementovat i podporu asynch režimu + simulátor modemu (AT příkazy) na druhé straně

Citováno z „http://infra2.cs.vsb.cz/vl-wiki/index.php/Virtlab:Virtu%C3%A1ln%C3%AD_spojovac%C3%AD_pole/TODO“
Osobní nástroje