5 Lut
2016
5 Lut
'16
15:03
W dniu 02/05/2016 o 01:19 PM, Jaroslaw Dziubek pisze: > Nie kasuje tekstu zeby bylo mozna ogarnac calosc ;) > > Dla uzupełnienia: > - Obiekty - netobjects > - Kable - netcables > - Połączenia - netconnects > - Elementy - netobjectelements > > [Friday, 05 February 2016], Ernest napisał(a): > >> W dniu 02/05/2016 o 10:38 AM, Jaroslaw Dziubek pisze: >>> Jak widać na demo jest jakiś zarys paszportyzacji jednak jak zacząłem >>> wprowadzać dane okazało się, że pierwotne założenia mało odpowiadają >>> rzeczywistości (wynika to m.in. z faktu, że sam dopiero startuje ze >>> światłowodowami). >>> >>> Nowa koncepcja: >>> - Obiekty sieciowe >>> - typ: mufa/przełącznica/docelowo również obiekty do obsługi miedzi (np. patchpanel) >>> - obiekt musi byc przypisany do węzła sieciowego >>> - pozostałe dane: producent, model, pojemność (ilość portów) >>> - Kable >>> - medium: światłowód/miedź >>> - typ: dla światłowodu: jednotubowy, wielotubowy, łatwego dostępu, >>> splitter optyczny >>> - węzeł źródłowy >>> - węzeł docelowy >>> - pozostałe dane: producent, model, ilość włókien, długość >>> - Połączenia >>> - rodzaj: stałe (spaw), rozłączalne (wtyk) >>> - rodzaj: simplex/dumplex (spaw to zawsze simplex) >>> - strona1: >>> - wtyk: adapter (FC/ST/SC/LC), konektor (FLAT/PC/UPC/APC) >>> lub >>> - kabel1 (kabel:tuba:włókno), kabel2 (jesli duplex) >>> - strona2: >>> - jesli to spaw - kabel2 >>> - jesli 2 konektor to połączenie jest patchcordem >>> - dane dodatkowe (uwagi, plik z pomiarami) >>> - Elementy obiektów sieciowych: >>> - połączenia (np. kabel lub splitter z dospawanym pigtailem, patchcord) >>> - numer portu (w przypadku mufy - można to wykorzystać do numeru tacki) >>> >>> I teraz dla przełącznicy: >>> 1) przełącznica na start jest pusta >>> 2) podpinamy do węzła z przełącznicą kable - kabel1 i kabel2 >>> 3) robimy połączenie - kabel1+pigtail (np. simplex SC/APC) i >>> kabel2+pigtail (oczywiśnie pojedyncze włókno) >>> 4) konektor #1 dopinamy do portu #1 - widać że coś jest wpięte, ale >>> port jest nadal wolny >>> 5) konektor #2 dopinamy do portu #1 - w tej chwili mamy pełne >>> połączenie >> Zastanawiałem się nad tym jak to można zrobić i idealnie byłoby >> wyszczególnić wszystkie połączenia w przełącznicy na zasadzie: >> definiujemy zainstalowane kable(liniowe, pigtaile, patchcordy) można >> jako wskazania do typu (co załatwi parametry kabla /ilość >> włókien,tub,rodzaj,złączy,etc/) > Kable definiujac w netcables odnosisz do obiektów z netobjects (jako > początek i koniec). Teraz do kabla na końcu dokładasz albo drugi kabel > (spaw w netconects+mufa w netobjects) albo pigtail (definiowany w > netconnects+przełącznica w netobjects) - oczywiście każde włókno to > osobny rekord. > >> następnie robimy połączenia wg schematu >> src(kabel_id, nr_włókna),dst(kabel_id, nr_włókna), id_tacki, typ_złącza, > Ja planuje dołożyć jeszcze nr tuby. Słusznie ;) >> pozycja_na_tacy/nr_portu, id_przełącznicy >> jeżeli id_tacki==0 to połączenie zewnętrzne > Zewnętrzne w jakim sensie? Pomiędzy np przełącznicami (przeł1/p1 <=> przeł2/p2) > >> Czyli na połączenie pomiędzy kablem zewn i portem przełącznicy >> potrzebujemy 2 rekordy >> 1) dla połączenia kabla z pigtailem > To byłoby w tabeli "netconnect" gdzie jednym parametrem bylby > >> 2) dla połaczenia pigtaila z portem przełącznicy > Gotowy pigtail z netconnects wrzucasz do netobjectelements > >> Jest tylko problem jak to w miarę czytelnie przedstawić bo na tabelkach >> ja tego nie widzę ;( > Mniej-wiecej jak powyzej :) > >>> Dla mufy będzie prościej >>> 1) do węzła 2 kable >>> 2) spawamy 2 kable ze sobą i podajemy numer tacki >> W każdym przypadku proponuję przewidzieć możliwość spawania więcej niż >> jednego kabla. > Ze sobą?? Każdy obiekt ma pojemność - liczba portów albo liczba spawów > - oba powinny odnosić się do tabeli netconnect Zgadzam się, ale często spawa się (w mufie lub przełącznicy) klika kabli na siebie (więcej niż 2) > >>> Splitter podpinamy identycznie jak kabel - mamy pigtail na końcu ze złączem >>> i wpinamy w odpowiedni port do przełącznicy (albo spawamy z kablem i >>> do mufy) >>> >>> Każde połączenie docelowo może byc wpięte do urządzenia, którego >>> definicja będzie przerobiona - każde urządzenie będzie miało 3 rodzaje >>> portów: >>> - miedziane - wykorzystywane jak dotychczas >>> - światłowodowe - do którego będzie można wpiąć połączenie >>> światłowodowe definiując pozostałe parametry (WDM, GPON, itp) >>> - radiowe - standardowo p2p, chyba, że będzie zdefiniowany sektor radiowy (wtedy >>> będzie to połączenie p2m) >> Gdzie będą zapisywane rodzaje portów urządzeń i jak to będzie powiązane >> z dotychczasowa definicją urządzenia? >> Druga rzecz to może zrobić otwartą listę typów portów z parametrami (w >> sensie wrzucić to do bazy jako słownik i jeśli ktoś będzie potrzebował >> jakiś nietypowy to sobie dorzuci) > To na razie bardzo luzna koncepcja - będą po prostu 3 typy portów ;) Bardziej chodziło mi o to, żeby nie tworzyć kolumn typ1, typ2, typ3 bo za chwilę okaże się, że trzeba jakiś inny typ portu . Dla mnie przydatne byłoby mieszanie typów w jednym urządzeniu (pewnie większość już zetknęła się ze switchami utp/sfp (24UTP+4SFP)==28; albo bramkami VOIP: 1UTP+2voice==3) > >> Swego czasu kombinowałem ze swoim systemem i miałem to zrobione tak, że >> w momencie dodawania urządzenia definiowałem 2 tabele 1(urządzenia) i >> 2(zadeklarowane porty jako lista wskazań na urządzenie). > Nie ma potrzeby - w tej chwili mam netdevlinks i tam można spokojnie > to wciskac ;) Jeżeli przerabiasz core to chyba nie ma potrzeby mnożyć tabel z połączeniami i zrobić jedną ale za to porządną do połączeń logicznych i fizycznych. W aktualnym LMS boli mnie np niemożność połączenia routera(4porty ethenet) ze switchem(na 4 porty) albo połączenia fizycznych portów na switchach ale w trybie bonding/trunk lub implementacja MSTP w LMS jest nie do zrobienia(kilka kabli pomiędzy 2 urządzeniami). Sieci ewoluują i niestety to co wczoraj wydawało się co najmniej dziwne dziś jest codziennością. Prace z bazami danych za to nauczyły mnie maksymalnie grupować podobne/identyczne elementy. Jak Chilan zauważył ze tabela netobjects jest podobna do nodes. Może ogólnie potraktować sprzęt jako sprzęt bez rozróżnienia na aktywny/pasywny (ew flagą), do niego przypisywać porty, IPki, sieci, klientów, instalacje ;). Tylko to jest tak naprawdę przepisanie całości od nowa i to robota na klika ładnych miesięcy dla kilku osób. > >> Minusem tego była objętość bazy gdzie niezależnie od tego czy port jest >> zajęty to jest w bazie. >> Plusem za to jest łatwość kreowania połączeń bo to tylko wskazanie >> port-port oraz uniwersalność podejścia (kwestia zmiany typu portu i >> możesz podłączyć np telefon no i sprawdzić kompatybilność łączonych portów). > Narzędzia sie później dorobi (chociażby przepinanie na szybko w > przełącznicy czy wrzucanie do bazy np. kompletnego splittera z > wtyczkami :) > >> Widzę tylko problem jak toto zaimplementować we wtyczce LMSa ;( chyba że >> jako osobny moduł a nie wtyczka >>> Czekam na uwagi (zwłaszcza od osób, które mają światłowody i spojrzą >>> od strony praktycznej) >> Jak rozumiem robisz wtyczkę do całościowej obsługi paszportyzacji? > To nie będzie wtyczka - to będzie w core LMS :) I słusznie, tylko w wersji normalnej czy plus ;) > > Jarek > _______________________________________________ > lms mailing list > lms@lists.lms.org.pl > http://lists.lms.org.pl/mailman/listinfo/lms > -- Pozdrawiam Michał Szmigielski /ernesttar/