5 Lut
2016
5 Lut
'16
22:12
W dniu 05.02.2016 21:03, Jaroslaw Dziubek napisał(a): > [Friday, 05 February 2016], ernest napisał(a): > >> On Fri, 5 Feb 2016 19:07:19 +0100 Jaroslaw Dziubek >> <yaro@perfect.net.pl> wrote >> >> > [Friday, 05 February 2016], Ernest napisał(a): >> > >> > > >> > > 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) >> > Nie ma znaczenia czy patchcordem krosujesz w jednej przełącznicy czy >> > między 2-oma - zawsze musi być zdefiniowany patchcord łączący 2 porty. >> Właśnie o to mi chodziło ;) >> > >> > > > >> > > >> 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) >> > Możesz to wyjaśnić (jak już pisałem - pierwsze poważne spawania przede >> > mną) - co rozumiesz pod pojęciem "spawanie kilku kabli na siebie" >> Czasem jest konieczne pospawanie np 3kabli w jednej przełącznicy z >> czego z >> dwóch część włókien wylatuje na porty a część jest spawana "na wprost" >> np 1 tuba kabla 1 na 1 tube z drugiego, a 2 tuba z pierwszego na 1 >> tubę >> trzeciego i losowe włókna z każdego kabla na porty przełącznicy. >> Zauważ,że standardowa przełącznica 19" ma 4 mocowania na kabel. > Chodzi Ci o to, że spawasz 2 włókna na stałe bez wyjścia na port z > przodu? Teoretycznie to funkcjonalność mufy - myślałem o zrobieniu > mufo-przełącznicy i wychodzi, że trzeba będzie to uwzględnić. > >> > > >>> 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 . >> > Ja bym to widział raczej jako wydzielona tabela: netports gdzie byłoby >> > oprocz odniesienia do urządzenia - ilość i rodzaj portu definiowany z >> > jakiejś biblioteki >> Właśnie o tym pisałem poniżej (to o moich kombinacjach) ;) tyle, że >> nie ma >> wtedy potrzeby opisywać ilości portów, bo z założenia wszystkie >> możliwe >> porty byłyby już wpisane do tabeli, Wystarczy wtedy policzyć ilość >> wpisów >> z danego typu i/lub urządzenia > Niekoniecznie - same porty będą opisywane: typ_portu,ilość. Zajętość > będziesz brał z netconnects (netlinks czy czegos w tym rodzaju) Porty urządzeń, tak jak już pisałem, najlepiej żeby były kopiowane z modelu urządzenia - dzięki temu od razu po dodaniu nowego urządzenia będzie obecny standardowy dla danego modelu zestaw portów, a porty w takim wydaniu nie powinny mieć numerów tylko etykiety tekstowe, bo każdy producent może inaczej je nazywać. >> > > 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. >> > Generalnie dlatego jest ta dyskusja (poprzednio nikt się nie >> > zainteresował) >> Uprzednio ?? >> Poprzednio była dyskusja TYLKO o paszportyzacji szkła, a teraz to się >> robi w >> zasadzie pełna paszportyzacja połączeń (wszystkich rodzajów) i sprzętu >> ;) > Założenie takie było od początku, ale jak już wspomniałem - dopiero > ogarniam te kuwete ;) > >> > > 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). >> > W przypadku światłowodów to dość częste - wtyki i kable dupleksowe ;) >> > >> > > 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. >> > Mam podejrzenie graniczące z pewnością, że oboje mówicie o netnodes a >> > nie o nodes :) >> Bardziej o tabelę netdevices. >> Niestety poza podglądnięciem Twojego dema nie miałem możliwości >> pozaglądać do środka (jestem poza LMS+), ale osobiści byłbym za tym >> żeby >> jakiekolwiek urządzenia wrzucić do jednej tabeli i do tych urządzeń >> przypisywać inne rzeczy > Nie jest w LMS+ - tu masz moje repo: > https://github.com/jarecky/lms/tree/FO > >> wg zasady Wiele do jednego a same urządzenia na tej samej zasadzie >> przypisywać do rekordów w netnodes. > No. Wlasnie nodes to adresy urzadzen/komputery, netnodes to wezly :) > >> > > 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 ;). >> > Prędzej netdevices bym połączył z netobjects - jak pisałem netnodes to >> > węzeł a w nim mogą być i urządzenia aktywne i pasywne. Nie można >> > ograniczyć węzła (netnodes) do jednego urządzenia. >> > >> > Zakładając połączenie netobjects i netdevices: >> > - dodajemy pole "pasywne/aktywne" >> > - pole "ports" pozostaje i oznacza na razie po prostu dla pasywnych >> > pojemność tacek na spawy (dla muf) albo ilość poł na adaptery (dla >> > przełącznic) >> Myślę, że mogłoby to tak funkcjonować tylko jest małe ale. >> Nie masz możliwości mieszania typów portów a w netdevices masz też >> urządzenia aktywne (do tego z różnymi portami/mediami/) > Zostawmy na razie mediam w urządzeniach - to jest temat na pozniej. > W tej chwili zalezy mi na ogarnieciu tematu pasywnych swiatlowodow w > kontekscie LMS (a w perspektywie tez pasywow miedzianych). > >> > - jeśli założymy, że urządzenie musi być w węźle (co jest dość >> > ryzykowane bo sam uzywam netdevices do wrzucania urządzeń >> > klienckiech do których dopiero podpinam komputery klientó) możnaby >> > wywalić wszelkie pola odnośnie lokalizacji. >> Przy takim założeniu trzebaby dołożyć kolumnę w netnodes (klient_id >> lub >> po prostu flagę że to węzeł kliencki) wtedy netnodes robiłoby za listę >> nazwijmy to instalacji, do takiego węzła wrzucasz sprzęt, do sprzętu >> przypisujesz IP(niekoniecznie jedno), telefon, VLAN, etc > Hmmmm... węzeł kliencki... Ma to sens - dociagamy tam światłowod (a > wiec kabel), montujemy przełącznicę (1,2-portowa) i urzadzenia (ONT, > itp). Można wykorzystać albo konkretny typ węzła albo wręcz skopiować > rozwiązanie z nodes - jeśli customerid==0 to jest to węzeł sieciowy, > jeśli >0 - wezęł kliencki konkretnego klienta. > >> > - opcjonalnie można wogóle zrobić nową tabele "locations" w której >> > będziemy wrzucać kompletne dane lokalizacyjne (adres, teryt i GPS) i >> > dopiero do tych rekordów dawać odnośniki wszędzie. >> > >> to załatwiłby Ci poprzedni schemat > Racja - wtedy każde urządzeniu musi być przypisane do węzła - albo > sieciowego albo klienckiego. > >> > > Tylko to jest tak naprawdę przepisanie całości od nowa i to robota na >> > > klika ładnych miesięcy dla kilku osób. >> > Generalnie i tak chce troche przebudować LMS :) >> To nie jest troche ;) > Hihi - to dopiero początek :) > >> > > >> 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 ;) >> > Normalnej - była zrzutka, ale nie doceniłem rozległości tematu ;) >> No niestety temat jest baaaardzo rozległy, można go podzielić na >> mniejsze >> części i podzielić między sobą > Pomoc się zawsze przyda (mam na głowie 2 inne projekty + odpalenie > GPON z TV + bieżąca działalność) :) Z mojej strony możesz liczyć na dofinansowanie prac. -- Pozdrawiam Tomasz Chiliński, Chilan