8 Lut
2016
8 Lut
'16
09:18
[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)
- kabel:
- medium (optyka/miedź)
- rodzaj (dla optyki: jednotubowy, wielotubowy, KLD, splitter)
- 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.
> 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)
> 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.
> Dobrze byłoby też jakoś znaczyć "master port"/uplink w kilku przypadkach
> będzie przydatne (splittery , radio p2mp, ja bardzo chętnie wykorzystałbym
> do określenia ścieżki podłączenia /od klienta końcowego do
> master_routera/ ;P )
Dobry pomysł.
Jarek