Virtlab:Virtuální spojovací pole/TODO
Z VirtlabWiki
| Verze z 11:03, 23. 6. 2008 Jan644 (Diskuse | příspěvky) (novy firmware na signamax - →Spojování LAN portů Ethernet - vlastní levný switch s podporou 802.1QinQ) ← Předchozí porovnání |
Verze z 11:04, 23. 6. 2008 Jan644 (Diskuse | příspěvky) (→Spojování LAN portů Ethernet - vlastní levný switch s podporou 802.1QinQ) Následující porovnání → |
||
| Řádka 18: | Řádka 18: | ||
| : 065-7840 | : 065-7840 | ||
| : http://www.signamax.com/index.php?typ=SXE&showid=322 | : http://www.signamax.com/index.php?typ=SXE&showid=322 | ||
| - | ; novy firmware http://www.intelek.cz/product.jsp?artno=76107840 | + | : novy firmware http://www.intelek.cz/product.jsp?artno=76107840 |
| Martin Stankuš napsal: | Martin Stankuš napsal: | ||
Verze z 11:04, 23. 6. 2008
Obsah |
ASSSK
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.
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)
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.
Unifikovaná tunelovací architektura
- 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).
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.)
- 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ě).
Integrace uživatelského PC do laboratorní topologie s použitím VPN
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)
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) - 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
- 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) - nahrazení šifrovacího mechanismu našim enkapsulačním mechanismem
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
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).
