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:
- Skopiowanie definicji portów do tabeli przechowującej porty
powiązane > z konkretnym urządzeniem.
- 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)
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.
- kabel:
- medium (optyka/miedź)
- rodzaj (dla optyki: jednotubowy, wielotubowy, KLD, splitter)
dla miedzi też proponuję jakieś parametry np UTP, FTP, skrętka telefoniczna wieloparowa
- 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ść ;)
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)
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...
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 _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
//sorka za powtórki ale dopisuję losowo jak coś mi przyjdzie do głowy//