w zwiazku z ta rewolucja ktora moim zdaniem idzie w dobrym kierunku chce dorzucic jeden temat jesli mamy doczynienia ze sprzetem bezprzewodowym w 98% przypadkow mamy doczynienia z MT strasznie brka mi jednego pola InterfaceName i mozliwosci dopisania klienta do konkretnego interfejsu taka zmiana pozwolila by na precyzyjne generowanie scceslist dla urzadzen nadawczych
Dnia 24 lutego 2012 15:24 Tomasz Chiliński tomasz.chilinski@chilan.com napisał(a):
Witam.
Jeszcze raz przesyłam pod spodem list sprzed 9 dni. Może teraz już większość zaczęła się budzić ze snu zimowego i zauważy, że robota nie zrobi się bez pomysłu na to jak ma to wyglądać ;-) Przedstawiłem zarys pomysłów spodziewając się dyskusji nad tym jak to powinno wyglądać, żeby większość była zadowolona z pracy niekoniecznie ściśle związanej z raportami UKE, a odpowiedzieli jedynie Andrzej i Wojtek ;-)
Pozdrawiam!
W dniu 15.02.2012 18:18, Andrzej Banach napisał(a):
W dniu 2012-02-04 23:33, Andrzej Banach pisze:
A wiec, z uwagi ze sa juz jasne i ostateczne wytyczne co do zakresu raportu jaki wymagac bedzie od nas UKE juz za kilka tygodni, mozna by rozpoczac II etap przerobki lms'a.
Ponizej planowane zmiany i nowe funkcjonalnosci w LMS bardzo wstepnie ustalone z Tomkiem. Prosze o uwagi, zmiany koncepcji itp, gdyz ponizsze jest powoli realizowane.
Jako, że nie ma żadnych uwag (pewnie pojawią się jak będzie bliżej 15-tego marca ;-)) to ja opiszę krótko jak widzę małą rewolucję w samych urządzeniach. Obecnie do urządzenia możemy przypisywać porty (obecnie na sztywno określa się tylko ich liczbę i przy połączeniu typ połączenia). Jak widzę pierwszy etap prac?
- Urządzenia stają się składowiskiem/zbiorem/grupą portów.
- Każdy port posiadać będzie następujące właściwości:
- medium fizyczne (np. koncentryk, skrętka, światłowód SM, światłowód
MM, to samo tylko z WDM, etc.)
- protokół L2 (np. ethernet, DSL, ATM, Frame Relay, inne...)
- etykieta systemowa (chodzi o możliwość wpisania dla portu informacji
systemowej, które potem można byłoby użyć np. do wiązania maców z portami, etc.; numer portu nie wystarczy - warto mieć np. informację zapisaną o identyfikatorze powiedzmy dla cisco to mogłoby być Fa0/3, Gi1/2, etc.)
- pole memo z dodatkowymi, dowolnymi informacjami o porcie np. jakiś
komentarz własny.
Myślałem, żeby jeszcze wprowadzić dodatkową warstwę pośrednią pomiędzy urządzeniami a portami zwaną roboczo modułami - moduł byłby grupą portów i można byłoby od razu grupami portów dołączać porty do urządzenia, ale z drugiej strony może to być zbędne gmatwanie schematu bazy danych, a w sumie jak ktoś "zaprojektuje" wzorcowy model danego urządzenia z przypisanymi portami to potem funkcja klonowania urządzeń pozwoli rozmnożyć cudownie kolejne egzemplarze danego urządzenia.
Ostatecznie na tym etapie mielibyśmy urządzenia z przypisanymi zbiorami portów.
Moim zdaniem nie warto ani urządzeniom, ani przygotowywanym w następnym etapie węzłom przypisywać informacji o warstwie, bo to urzędnicza bzdura. Warstwę będzie można ustalić automatycznie na podstawie tego jakie urządzenia są wpięte do portów urządzenia, np. czy tylko komputery, czy tylko urządzenia czy jedno i drugie.
Już teraz dodam, że przepływność połączenia widzę jako przypisywaną do połączenia, a nie do portu (to logiczne).
Co o tym myślicie? Jak to się ma do codziennej pracy związanej z zarządzaniem Waszymi sieciami?