5 Lut
2016
5 Lut
'16
21:03
[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)
> > > 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ść) :)
--
Yaro
IRL: Jarosław Dziubek | "Jabłka mają rumieńce od czasu,
http://yaro.perfect.net.pl/ | kiedy jabłoń usłyszała
IRC:Yaro, ICQ:1340145, GG:1392891 | co rzekła Ewa do Adama."
| Gromez de la Serna