8 Lut
2016
8 Lut
'16
10:41
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) 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// -- Pozdrawiam Michał Szmigielski /ernesttar/