Re: [lms] Paszportyzacja światłowodów w LMS - etap 2

[Monday, 08 February 2016], Ernest napisał(a):

> 
> W dniu 02/08/2016 o 09:18 AM, Jaroslaw Dziubek pisze:
> > [Sunday, 07 February 2016], ernest napisał(a):
> >
> >> On Sun, 7 Feb 2016 11:47:06 +0100 Jaroslaw Dziubek <yaro@perfect.net.pl> wrote
> >>
> >>> [Sunday, 07 February 2016], ernest napisał(a):
> >>>
> >>>> On Sun, 7 Feb 2016 09:35:22 +0100 Jaroslaw Dziubek <yaro@perfect.net.pl>
> >>>> wrote
> >>>>> [Saturday, 06 February 2016], Tomasz Chiliński napisał(a):
> >>>>>
> >>>>>>>>> Chodziło mi o dodawanie
> >> urządzenia(switch/przełącznica/splitter)
> >>>> jeśli
> >>>>>>>>> miałbyś gdzieś zdefiniowane jaką ma konfigurację to jeden
> >> klik i
> >>>> masz
> >>>>>>>>> wszystkie możliwe porty dostępne do połączeń.
> >>>>>>>>> Nie musisz za każdym razem definiować na nowo że (Switch xxx ==
> >>>>>>>>> 12*e10/100+2*SFP+5*e1giga)
> >>>>>>>> Spoko - takie gotowe schematy mogą być, ale IMHO nic nie zastąpi
> >>>>>>>> elastyczności rozwiązania które zaproponowałem (można przecież
> >>>> zrobić
> >>>>>>>> jak pisałem automat do dodawania konkretnego zestawu portów dla
> >>>>>>>> standardowych urządzeń).
> >>>>>>> No można to zrobić tak jak jest teraz w netdevices
> >> (producent/model)
> >>>>>>> możesz
> >>>>>>> wpisać ale możesz też wybrać ze słownika
> >>>>>> Moim zdaniem zdecydowanie pełna definicja portów urządzenia powinna
> >>>>>> trafić
> >>>>>> jako rekordy w tabeli powiązanej z modelami urządzeń, bo to
> >> naturalne.
> >>>>>> Tworzenie nowego urządzenia i wybranie modelu powodowałoby jedno z
> >>>>>> dwóch:
> >>>>>> 1) Skopiowanie definicji portów do tabeli przechowującej porty
> >>>>> powiązane > z konkretnym urządzeniem.
> >>>>>> 2) Urządzenie na podstawie przypisanego modelu miałoby dostęp do
> >>>>>> informacji
> >>>>>> o posiadanych przeze nie portach (bez kopiowania definicji portów do
> >>>>>> urządzenia).
> >>>>>> Przy tym rozwiązaniu trzeba rozważyć czy będzie można edytować
> >>>> definicje
> >>>>>> portów
> >>>>>> modelu w przypadku, gdy ma już jakieś reprezentacje w postaci
> >> urządzeń.
> >>>>> Nie do końca łapie Twoją propozycję: netelements + netports
> >> (definicja
> >>>>> pojedynczego portu) x ilosc portow w urzadzeniu?
> >>>>> Wtedy połączenie byłoby między id_port1 a id_port2?
> >>>> Można tak czyli w netports mialbys od razu wszystkie zadeklarowane porty
> >>>> (opcja którą proponuję od początku) i wtedy połączenia to relacja
> >>>> portid-portid lub w netports tylko deklaracja że typ portu x ilość i
> >> wtedy
> >>>> właściwa deklaracja portu następowałaby dopiero w chwili dodawania
> >>>> połączenia
> >>> Jesli porty mialyby byc definiowane od razu to baza bylaby dosc duza -
> >>> przelacznica 144 porty to od reki 144 rekordy ;)
> >> tylko od ręki masz info do czego jest podłączony każdy port zaś sama
> >> ilość rekordów przy dobrze zrobionych indexach to jest nic.
> >> Co miesiąc obrabiam tabelę z ~100M rekordów i wyciągam z niej dane w kilka
> >> sekund dość specyficznym zapytaniem złożonym chyba z 7 joinów i kilku
> >> warunków a tutaj będzie co najwyżej dwa złączenia i rekordów tyle co
> >> portów globalnie (przy 100switchy 24p będziesz miał 2400 rekordów co nie
> >> jest zabójcze jakoś myślę, że spokojnie do 100k-200k rekordów będzie
> >> można pracować swobodnie).
> >>
> >>> Pytanie jak robimy netconnections. W tej chwili mamy netlinks ktore ma
> >>> id_urzadzenia1, id_urzadzenia2 + numery portów w tych urzadzeniach +
> >>> opis medium i predkosci.
> >> Przy połączeniu id_port-id_port zostaje do połączenia dołożyć:
> >> link_type, link_tech, link_speed, długość(przydatne np na serwerowni i
> >> opcjonalnie: id_kabel, tuba, włókno.
> >> Można też pierwsze 3 parametry połączenia przypisać do definicji portu.
> >>> Wydaje sie, ze trzebaby to podzielic na 2 rodzaje: fizyczne i logiczne
> >>> (wtedy identycznie z netelements robimy 2 widoki).
> >>>
> >>> Połączenie fizyczne łączyłoby (w przypadku światłowodów):
> >>> - port w przełącznicy/urządzeniu z portem w przełącznicy/urządzeniu
> >> (czyli
> >>> patchcord). - port w przełącznicy/urządzeniu z kablem (czyli pigtail)
> >>> - kabel z kablem (czyli spaw)
> >>> W przypadku miedzi:
> >>> - port w urządzeniu/patchpanelu z portem w urządzeniu/patchpanelu
> >> (patchcord)
> >>> - kabel z portem w urządzeniu/patchpanelu
> >>> - kabel z kablem (beczka?)
> >>>
> >>> Logiczne (to na przyszłość):
> >>> - miedziane i radiowe p2p - porty w 2 urządzeniach
> >>> - radiowe m2p - port w urządzeniu w sektorem radiowym
> >>>
> >>> Opis połączenia (zakładam, że każdy port będzie osobnym rekordem)
> >>> - id_kabel1+tuba1+włókno1
> >>> - id_kabel2+tuba2+włókno2
> >>> - id_konektor1 (można brać z bazy typów konektorów albo ze słownika) +
> >>> id_port1 - id_konektor2 + id_port2 (j.w.)
> >>> - opis + plik z pomiarami spawu
> >>> Przykłady (co niewymienione jest null):
> >>> - id_kabel1+id_kabel2+id_port1 not null - spaw
> >>> - id_kabel1+id_konektor2+id_port2 not null - kabel1+pigtail w port2
> >>> - konektor1+port1+konektor2+port2 not null - patchcord między port1 i port2
> >>> - id_kabel1+id_kabel2+id_konektor1+id_port1 - wtyk duplex w port1
> >>>
> >> To chyba jeszcze bardziej uprościłoby sprawę potraktowanie kabla jako
> >> urządzenia z ilością portów.
> >> Czyli miałbyś tabele:
> >> --netelements ze znacznikami aktywny/pasywny,
> >> grupa(kabelFO/kabelCU/kabelUTP/taca/przełącznica/mufa/swictch/kowerter/bramkaVOIP/),
> >> długość(w przypadku grupy kable), lokalizacja końcówek(może być
> >> ustawiona jedna)
> > Hmm.. Ja bym to widział tak:
> > - aktywny/pasywny
> > - grupa:
> >    - aktywny - w zasadzie każde urządzenie powinno być trakowane tak
> >      samo - jako zestaw portów
> >    - pasywny - tutaj tak samo - kwestia jak rozwiązać sprawę tacek na
> >      spawy, ale to tylko byc może kwestia ograniczenia sie do
> >      pojemności tacki i numeru (wystarczy informacja, ze spaw jest na
> >      2. tacce)
> Jeśli potraktujesz mufę i przełącznicę tak samo to nie ma większego 
> problemu, tyle że przełącznica to tak naprawdę mufa(tacki ze spawami) + 
> porty rozłączalne czyli trzeba by potraktować przełącznicę jak 2 
> urządzenia i robić spaw kabel-kabel lub kabel-pigtail(port) i wychodzi 
> na to, że przełącznicę trzeba potraktować tak: pojemność tacek + porty 
> na froncie
> albo
> jako blackbox i (nie przejmując się tackami) zestawiać połączenia 
> kabel_a <=> kabel_b z opcjonalnym wskazaniem na nr portu
> /coś jakby przełącznicę postawić obok zestawu połączeń/ tylko wtedy 
> problemem są porty w przełącznicy, które są obsadzone z jednej 
> strony(pospawane)
> ( nie przejmować się inwentaryzacją spawów co w działającej sieci ze 
> sporą ilością przeróbek jest bardzo utrudnione)
Ja u siebie wychodze z zalozenia, ze lepiej pomeczyc sie raz przy
dodawaniu/zmianach niz potem spedzic kilka(nascie) minut na szukaniu
"skad ten kabel przychodzi i gdzie idzie". Samego spawu pewnie nie da
sie oznaczyć, ale już spokojnie kabel wchodzący do przełącznicy
ometkowac i później w LMS szukać tylko etykiety (masz nazwe kabla,
numer/kolor tuby i numer/kolor włókna)

> Jeszcze jeden pomysł (wydaje mi się, że najlepszy).
> Gdyby tak przy łączeniach dopuścić relację wiele->jednego (jeżeli 
> "port==port przełącznicy" to dla pełnego połączenia musi mieć 2 
> wskazania w netlinks /takie porty przelotowe "dwustronne"/) to miałoby 
> zastosowanie tylko w przełącznicach i patch panelach. Łatwo wtedy 
> złapać, że port jest pospawany ale niepodłączony.
Problem generalnie nie jest w tym co i gdzie wrzucic, ale jak
zapanować nad tym co masz wolne - przełącznica czy mufa ma swoja
pojemnosc i moze sie okazac, ze bedziesz chcial cos pospawac a nie
masz juz miejsca na tackach.

Ja widze 2 opcje przy przełącznicach:
- porty i tacki definiowane osobno
- tacki definiowane jako wolne miejsca na spawy PONAD ilosc portow 

Mysle, ze tacke mozna spokojnie zdefiniowac jako port o pojemnosci np.
12 połączeń (wtedy widać ile spawów jest zajęte) a pole komutacyjne
jako port o pojemności 2 (czyli 2 wtyki w adapterze). Wtedy dałoby się
to ogarnąć (dodatkowo port w urządeniu miałby pojemność 1 - jedna
wtyczka). Samo netlinks mogłowy wtedy wskazywac tyle razy ile miałby
pojemności port (warto pewnie oznaczać przy portach
przełącznicy/patchpanelu czy wtyczka "wchodzi" od tylu czy przodu)

Czyli:
- port definiujemy jako SC/APC
- do niego wpinamy netlinks:
  - kabel1+id_port oraz jako 2. rekord kabel2+id_port (wtedy port jest zajety i mamy pelne polaczenie)
  - kabel1+id_port - mamy port gotowy do podlaczenia czegos
  - id_port1+id_port2 - patchcord między portami

Nadal pozostaje pytanie o netlinks. Ja bym się trzymał mojego pomysłu,
ze mozemy miec:
- 2* kabel
- 2* port
Co nam umozliwi zdefiniowanie wszystkich mozliwosci - od spawu (wtedy
id_port oznacza tacke spawow) po patchcord (kable ustawione na null)


 
> >    - kabel:
> >      - medium (optyka/miedź)
> >      - rodzaj (dla optyki: jednotubowy, wielotubowy, KLD, splitter)
> dla miedzi też proponuję jakieś parametry np UTP, FTP, skrętka 
> telefoniczna wieloparowa
Jasne - na miedzi sie nie skupiam bo to generalnie bedzie duzo
prostsze do opisania (tutaj bedzie tez np. koncentryk)

> >      - długość (dla splittera - podział x:y)
> > - lokalizacja (węzeł) - w przypadku kabla to 2 lokalizacje
> >
> > Z tym, że parametry w osobnych tabelach: netelemactive,
> > netelempassive, netelemcable
> >
> >> --netelemports: id, id_netelements, nr_tuby/wiązki, nr_włókna/pary,
> >> typ_złącza(ze słownika)
> > Do tego etykieta_portu.
> >
> > Problem bedzie wtedy będziesz chciał spiąć 2 kable ze sobą w
> > przełącznicy na porcie (powiedzmy 5) - jeden kabel normalnie oznaczysz
> > na porcie, ale drugiego nie będzie jak wpiąć bo port już będzie
> > zapięty. Gdybyś wpiął go do innego portu w przełącznicy - to OK
> > zepniesz patchcordem z netlinks, ale bezpośrednio się nie da.
> >> --netlinks: netelemports_id, netelemports_id,
> >> link_type(rozłączne/nierozłączne), opcjonalnie(link_speed, link_tech,
> >> length)
> > Pytanie najważniejsze: jak chcemy oznaczać połączenia logiczne w
> > stoѕunku do fizycznych. Teoretycznie można przyjąć, że mając
> > połączenie fizyczne między portem A urzadzenia 1 a portem B
> > urządzeniam 2 to wybieramy najniższe z możliwych połączeń
> > (przykładowo łączysz port 1000BaseTX z portem 100BaseTX to połączenie
> > będzie 100Mbit/s FD, a np. przy połączeniu radiowym między 802.11a a
> > 802.11ac MIMO 2x2 - jedynie 54Mbit/s) i raczej nie powinno to być
> > oznaczane w netlinks bo później wychodzą jakies bzdury.
> Nie do końca. Wiadomo, że wybierając połączenie 
> 802.11ac(klient)->802.11a(stacja) będziesz miał 54Mbps ale w drugą 
> stronę (przy p2mp) do urządzenia 802.11ac możesz podpiąć 802.11ac/n/a i 
> to w zależności od tego jakie będziesz miał parametry sygnału możesz 
> ograniczyć prędkość ;)
W przypadku radia nigdy nie osiągniesz pełnej przepustowości, ale
zakładając że masz 2 końce (nawet przy p2mp) to bierzesz prędkość
wolniejszego końca (klient ac wpięty do nadajnika an nadal będzie
działał jako an :)

> >
> >> Trochę kombinacji byłoby w przypadku połączeń portów z różnymi
> >> złączami np SC-PC<=>SC-APC (to wymagałoby zdefinowania patchcordu w
> >> netelements)
> > A to akurat nie problem - skoro port1 to SC/APC a port2 to LC/PC
> > (ekstremalne wiem) to kabel łączący będzie to spełniał :)
> >
> >> podobnie byłoby z portami SFP (chyba że od razu definiujemy
> >> SFP_UTP, SFP_SC-PC, etc albo mapę wyjątków)
> > SFP i SFP+ to inna bajka - skoro mamy typ_złącza (ze słownika) to nie
> > problem w słowniku (albo nawet w osobnej tabeli) zdefiniować dany typ
> > wkładki (od razu definiując typ gniazda i możliwą predkość - np.
> > wkładka SFP+ firmy xx to duplex LC/APC i prędkość 10Gbit, a wkładka
> > SFP firmy yy to WDM czyli simplex LC/APC i prędkość 1Gbit)
> Tak, tylko to daje dodatkowe urządzenie pt. wkładka SFP (2porty a-SFP, 
> b-SC/PC) i dopiero to łączysz (ale może to i dobrze bo pozwoli na pełną 
> inwentaryzację sprzętu)
Wiesz - pusty port SFP bylby pustym portem SFP (bez opisu gniazda,
predkosci itp) - dopiero włożenie wkładki "wypełnia" opis portu
odpowienimi parametrami.

> >
> >> Przy połączeniach radiowych p2mp proponuję założyć ilość klientów do
> >> podpięcia jako ilość portów.
> > Nie - niech to będzie otwarte - podłączasz wtedy pod port radiosector
> > i masz zasięg, a podłączasz ile chcesz.
> Ale wtedy wywali się pomysł połączeń port-port zresztą każda stacja 
> bazowa ma określoną pojemność optymalną i maksymalną (literatura przy 
> 2.4G podawała 16 /max 32/) to i tak byłyby porty wirtualne.
> Można zdefiniować na jakimś wysokim poziomie np 100,150,200...
Ja mam u siebie porty radiowe ustawione na 41 (40 po radiu, 1 po
lanie), ale IMHO to zly pomysl - wolalbym uniknac taki ograniczeń.
Oczywiscie kazdy moze sobie zalozyc, ze po podlaczeniu 24 klienta na
an nalezy nadajnik "rozbic" na 2, ale to juz wola/chec uzytkownika.
Program nie powinien blokowac tego (mozna conajwyzej zrobic
ostrzezenie - tylko po co? :D ). 


Jarek