Virtlab:Virtuální spojovací pole/TODO
Z VirtlabWiki
← Starší verze | Novější verze →
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
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
- (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
- 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ě).
