https://wiki.cusu.edu.ua/api.php?action=feedcontributions&feedformat=atom&user=Aleksey 2026-04-11T16:49:10Z Внесок користувача MediaWiki 1.23.2 https://wiki.cusu.edu.ua/index.php/%D0%9C%D0%95%D0%A2%D0%9E%D0%94%D0%98_%D0%9A%D0%9E%D0%9C%D0%A3%D0%A2%D0%90%D0%A6%D0%86%D0%87 2012-01-04T16:15:28Z

<p>Aleksey: </p> <hr /> <div>'''Методи комутації''' <br /> Будь-які мережі зв'язку підтримують деякий спосіб комутації своїх абонентів між собою. Цими абонентами можуть бути віддалені комп'ютери, локальні мережі, факс-апарати або просто співрозмовники, що спілкуються за допомогою телефонних апаратів. Практично неможливо надати кожній парі взаємодіючих абонентів свою власну фізичну лінію зв'язку, яка не комутується, і якою вони могли б монопольно &quot;володіти&quot; протягом тривалого часу. Тому в будь-якій мережі завжди застосовується який-небудь спосіб комутації абонентів, що забезпечує приступність наявних фізичних каналів одночасно для декількох сеансів зв'язку між абонентами мережі. На мал. 1 показана типова структура мережі з комутацією абонентів. <br /> <br /> [[Файл:MDK.jpg]]<br /> <br /> <br /> <br /> Мал.1. Загальна структура мережі з комутацією абонентів. <br /> <br /> <br /> Абоненти з'єднуються з комутаторами індивідуальними лініями зв'язку, кожна з який використовується в будь-який момент часу тільки одним, закріпленим за цією лінією абонентом. Між комутаторами лінії зв'язку розділяються декількома абонентами, тобто використовуються спільно. <br /> <br /> Існують три принципово різні схеми комутації абонентів у мережах: комутація каналів (circuit switching), комутація пакетів (packet switching) і комутація повідомлень (message switching). Зовні всі ці схеми відповідають приведеній на мал. 1 структурі мережі, однак можливості і властивості їх різні. Мережі з комутацією каналів мають більш багату історію, вони ведуть своє походження від перших телефонних мереж. Мережі з комутацією пакетів порівняно молоді, вони з'явилися наприкінці 60-х років як результат експериментів з першими глобальними комп'ютерними мережами. Мережі з комутацією повідомлень послужили прототипом сучасних мереж з комутацією пакетів і сьогодні вони в чистому виді практично не існують. <br /> <br /> Кожна з цих схем має свої переваги і недоліки, але за прогнозами багатьох фахівців майбутнє належить технології комутації пакетів, як більш гнучкої й універсальний. <br /> <br /> Як мережі з комутацією пакетів, так і мережі з комутацією каналів можна поділити на два класи по іншій ознаці — на мережі з динамічною комутацією і мережі з постійною комутацією. <br /> <br /> В першому випадку мережа дозволяє встановлювати з'єднання з ініціативи користувача мережі. Комутація виконується на час сеансу зв'язку, а потім (знову ж з ініціативи одного з взаємодіючих користувачів) зв'язок розривається. У загальному випадку будь-який користувач мережі може з'єднатися з будь-яким іншим користувачем мережі. Звичайно період з'єднання між парою користувачів при динамічній комутації складає від декількох секунд до декількох годин і завершується при виконанні визначеної роботи — передачі файлу, перегляду сторінки чи тексту зображення і т.п. <br /> <br /> В другому випадку мережа не надає користувачу можливість виконати динамічну комутацію з іншим довільним користувачем мережі. Замість цього мережа дозволяє парі користувачів замовити з'єднання на тривалий період часу. З'єднання встановлюється не користувачами, а персоналом, що обслуговує мережу. Час, на яке встановлюється постійна комутація, виміряється звичайно декількома місяцями (роками). Режим постійної комутації в мережах з комутацією каналів часто називається сервісом виділених (dedicated) чи орендованих (leased) каналів. <br /> <br /> Прикладами мереж, що підтримують режим динамічної комутації, є телефонні мережі загального користування, локальні мережі, мережі TCP/IP. <br /> <br /> Найбільш популярними мережами, що працюють у режимі постійної комутації, сьогодні є мережі технології SDH, на основі яких будуються виділені канали зв'язку з пропускною здатністю в декілька гігабіт у секунду. Деякі типи мереж підтримують обидва режими роботи. Наприклад, мережі Х.25 і ATM можуть надавати користувачу можливість динамічно зв'язатися з будь-яким іншим користувачем мережі й у той же час відправляти дані по постійному з'єднанню одному цілком визначеному абоненту. <br /> <br /> <br /> '''Методи комутацiї i розподiл каналiв.'''<br /> <br /> == Комутацiя каналiв ==<br /> <br /> Комутацiя каналiв (circuit (line) switching) - це спосiб органiзацiї прямого зв'язку мiж двома чи декiлькома абонентами для обмiну iнформацiєю в реальному часi. Установлення з'єднання при комутацiї каналiв здiйснюється шляхом набору номера абонентом, що викликає.<br /> <br /> '''Мережа з комутацією каналів''' — вид телекомунікаційної мережі, у якій між двома вузлами мережі повинне бути встановлене з'єднання (канал), перш ніж вони почнуть будь-який обмін інформацією. Це з'єднання протягом усього сеансу обміну інформацією може використовуватися тільки вказаними двома вузлами. Після завершення обміну з'єднання має бути відповідним чином розірване.<br /> '''Приклади'''<br /> Типовим прикладом є ранні телефонні мережі. Абонент мав попросити оператора з'єднати його з іншим абонентом, під'єднаним до того ж комутатора або іншого комутатора через лінію зв'язку (і іншого оператора). В будь-якому разі кінцевим результатом було фізичне електричне з'єднання між телефонними апаратами абонентів протягом усієї розмови. Провідник, задіяний для з'єднання, не міг бути використаний для передачі інших розмов у цей час, навіть якщо абоненти насправді не розмовляли і в лінії була тиша.<br /> Пізніше стало можливим ущільнення однієї фізичної лінії для утворення в ній декількох каналів. Незважаючи на це, один канал ущільненої лінії так само міг використовуватися лише однією парою абонентів.<br /> '''Переваги'''<br /> • Висока стабільність параметрів каналу у часі.<br /> • Відсутність необхідності у передачі службової інформації після встановлення з'єднання.<br /> • Комутація каналів може використовуватися як у аналогових, так і у цифрових мережах зв'язку, на відміну від комутації пакетів, яка можлива тільки у цифрових мережах.<br /> '''Недоліки'''<br /> • Комутація каналів вважається недостатньо ефективним способом комутації, тому що канальна ємність частково витрачається на підтримання з'єднань, що встановлені, але (в даний момент) не використовуються.<br /> '''Альтернатива'''<br /> Комутація каналів принципово відрізняється від комутації пакетів, при якій дані, що передаються (нарпиклад, оцифрований звук або дані з комп'ютерної мережі) розділяються на окремі пакети, які окремо передаються через мережу загального користування.<br /> <br /> == Комутацiя пакетiв ==<br /> <br /> Комутацiя пакетiв (packet switching) - це спосiб органiзацiї зв'язку мiж двома кiнцевими пунктами за допомогою логiчних (вiртуальних) каналiв без установлення прямого зв'язку, передача даних здiйснюється за допомогою пакетiв. Вiртуальнi канали можуть бути двох видiв: що некомутуються i що комутуються. Вiртуальнi канали, що некомутуються, органiзуються вручну (кросуванням) на заданий перiод часу. Вiртуальнi канали, що комутуються, органiзуються на кожен виклик. У вiртуальному каналi на кожен виклик установлюється визначений маршрут, i всi пакети даного виклику проходять по ньому через мережу.<br /> <br /> Першими з'явилися мережі комутації каналів, коли користувачі безпосередньо з'єднувалися між собою. Через вузли мережі за допомогою кабелю створюється транзитний канал, по якому передається інформація. Цей канал утворюється на початку сеансу, є фіксованим протягом усієї передачі і роз'єднується після її закінчення, тобто пряме сполучення каналів однієї з груп мережі залишається незмінним протягом усього сеансу. Така технологія реалізації передачі інформації є досить зручною, але має низький коефіцієнт використання каналів, високу вартість передачі даних, значні витрати часу на очікування інших клієнтів. <br /> <br /> При комутації повідомлень інформація передається порціями (повідомленнями). Пряме сполучення не встановлюється, а передача повідомлення починається після звільнення першого каналу і так далі, доки повідомлення не дійде до адресата. Кожний сервер здійснює приймання інформації, її складання, перевірку, маршрутизацію та передачу повідомлення. Недоліками комутації повідомлень є низька швидкість передачі даних і неможливість діалогу між клієнтами, хоча вартість передачі зменшується.<br /> Зі створенням модемів електронно-обчислювальна машина (ЕОМ) і термінали можуть здійснювати обмін інформацією через телефонні лінії. Проте, телефонні системи не пристосовані для передачі великих обсягів даних. У цьому середовищі через перебої зв'язку втрата інформації може мати серйозні наслідки для ЕОМ. Крім того, телефонні мережі не задовольняють вимоги щодо надійності, цілісності та швидкодії. Однак, вони дешеві й дуже поширені. Тому зараз найпоширенішим способом підключення до мережі є передача інформації по телефонних лініях за допомогою модемів. При цьому модем може сам набрати потрібний телефонний номер і з'єднатися з модемом іншої ЕОМ.<br /> <br /> У результаті розвитку мережевої технології з'явилася концепція комутації пакетів. У вузлах мережі розміщують сервери, здатні забезпечити можливість багатьом терміналам й ЕОМ спільно використовувати загальну комутаційну лінію, що має велику пропускну здатність. Кожне повідомлення поділяється на короткі пакети однакового розміру і фіксованої структури. Пакет — частина повідомлення, що задовольняє певний стандарт. У мережі Інтернет — це стандарти TCP та IP. Протокол TCP розбиває повідомлення на пакети і нумерує їх, щоб при одержанні інформації можна було правильно скласти повідомлення. Мережа передає пакети по черзі за допомогою протоколу IP. Оскільки окремі пакети можуть мандрувати мережею Інтернет різними шляхами, порядок надходження частин (пакетів) може бути порушений. Після одержання всіх пакетів TCP розміщує їх у певному порядку і складає в єдине ціле.<br /> Крім того, після пересилання пакету кожний вузол (комутаційний сервер) очікує підтвердження того, що пакет отриманий належним чином; інакше відбувається повторна передача. Це дає змогу запобігти ситуації, коли повідомлення доводиться передавати повністю знову і знову через єдину помилку. Унаслідок цього, значно зросла пропускна здатність мереж. Мала довжина пакетів запобігає блокуванню ліній зв'язку, не дає зростати черзі у вузлах комутації. Це забезпечує швидке з'єднання, низький рівень помилок, надійність та ефективність використання мережі.<br /> Модеми прискорюють передачу даних завдяки паралельному виконанню процедур поділу даних на пакети, перевірці помилок і повторній передачі, процедури стиснення даних.<br /> <br /> Концепція комутації пакетів ґрунтується на адресації. До кожної одержаної порції інформації протокол IPдодає службову інформацію, яка містить адреси відправника й одержувача інформації. <br /> Термінал визначає мережеву адресу, звертаючись до вузла з вимогою встановити зв'язок з ЕОМ за цією адресою. Зв'язок термінала з вузлом мережі здійснюється викликом через місцеву телефонну мережу. Мережевому вузлу відомо, які зв'язки доступні завдяки каталогу в пам'яті. Завдяки цьому, мережеві вузли створюють можливість передачі даних із проміжним накопиченням. Ця технологія дала змогу мережі функціонувати при повних і «м'яких» відмовах (шуми, зайнятість) на окремих ділянках.<br /> Проблема маршрутизації, при передачі пакета, вирішується програмно-апаратними засобами. Найпоширенішими методами є фіксована маршрутизація і маршрутизація методом найкоротшої черги. Фіксована маршрутизація припускає наявність таблиці маршрутів, у якій закріплюється маршрут від одного клієнта до іншого, що забезпечує простоту реалізації, але, водночас, і нерівномірне завантаження мережі. У методі найкоротшої черги використовуються кілька таблиць, у яких канали розставлено за пріоритетами. Пріоритет є функція оберненою відстані до адресата. Передача починається з першого вільного каналу з вищим пріоритетом. За використання цього методу мінімальною є затримка передачі пакета.<br /> <br /> Комутація пакетів реалізувала принципи адаптивності та динамічності. Мережа вибирає оптимальний маршрут щоразу, коли потрібно переслати інформацію. Маршрути інформації можуть змінюватися від пакета до пакета, від вузла до вузла, навіть посеред повідомлення, адаптуючись до відмов, шумів і зайнятості каналів. Коли умови нормалізуються, лінії відновлюються, мережа без втручання людини адаптується до нових умов. Отже, у мережі з комутацією пакетів показники тривалості та доступності практично є абсолютними.<br /> <br /> <br /> [[Віртуальні канали у мережах з комутацією пакетів]]<br /> <br /> <br /> == Комутацiя повiдомлень ==<br /> <br /> Комутацiя повiдомлень (message switching) побудована за принципом повного переприйому повiдомлень у вузлi комутацiї й обов'язкового дотримання форматiв повiдомлень. Процес маршрутизацiї повiдомлення, пошуку i з'єднання ланцюгiв, власне, i є комутацiєю повiдомлень. Особливiстю комутацiї повiдомлень є те, що нi вiдправник, нi одержувач повiдомлення особистої участi в процесi передачi не приймають. Передача повiдомлень вiдбувається за етапами. Вони передаються з кiнцевого вузла вiдправника в сумiжний переприйомний вузол, де обробляються i передаються далi на iнший такий же вузол зв'язку. Цей цикл переприйому повторюється доти, поки передане повiдомлення не досягне кiнцевого пункту.<br /> <br /> == Комутацiя вiртуальних каналiв ==<br /> <br /> Комутацiя вiртуальних каналiв (virtual switching) являє собою вид комутацiї, що сполучить достоїнства комутацiї пакетiв i комутацiї каналiв. З'єднання в основному здiйснюються на транспортному рiвнi моделi взаємодiї вiдкритих систем ([[OSI]]), а користувач звiльняється вiд необхiдностi контролювати послiдовнiсть проходження iнформацiї з мережi. <br /> <br /> == Порівняння способів комутації ==<br /> [[Постійна і динамічна комутація]]<br /> <br /> [[Пропускна здатність мереж з комутацією пакетів]]<br /> <br /> == Тимчасова комутацiя ==<br /> <br /> Метод тимчасової комутацiї (time-division switching) - це комутацiя каналiв з тимчасовим мультиплексуванням, заснована на розподiлу даних рiзних каналiв, що комутируються, по тимчасових iнтервалах усерединi кадру. Тимчасовий комутатор побудований на основi буферної пам'ятi, запис виробляється в її елементи послiдовним опитуванням входiв, а комутацiя здiйснюється завдяки зчитуванню даних на виходi з потрiбних елементiв пам'ятi. <br /> <br /> == Тимчасовий подiл каналiв (ТПК) ==<br /> <br /> В основу ТПК покладений принцип почергової передачi в груповому трактi кодованих дискретних вiдлiкiв кожного каналу за допомогою комутатора, що називається мультиплексором. Спочатку передається кодова послiдовнiсть першого каналу, потiм iншого каналу i т.д., до останнього каналу, пiсля чого процес перiодично повторюється. <br /> Короткий промiжок часу, вiдведений для передачi кодової послiдовностi iндивiдуального каналу, називається тимчасовим слотом (Time Slot - TS), так що мультиплексний сигнал представляється у виглядi послiдовностей TS, що чергуються. ТПК вимагає синхронiзацiї передавального i приймального устаткування. <br /> <br /> == Частотний подiл каналiв (ЧПК) ==<br /> <br /> При ЧПК увесь спектр частотного дiапазону, який використовує система передачi, розбивається на деяке число частотних смуг, у яких здiйснюється передача вихiдних iнформацiйних сигналiв. Окремi смуги частот називаються каналами; апаратура, що здiйснює розбивку на смуги частот окремих каналiв, - апаратурою каналоутворення (ущiльнення), чи мультиплексором. Перенос спектрiв сигналiв в область частот, вiдведену для передачi групового сигналу, здiйснюється за допомогою модуляцiї гармонiйної несущої. При цьому може використовуватися будь-який вид модуляцiї аналогових сигналiв. На приймальнiй сторонi груповий сигнал роздiляється за допомогою частотних смугових фiльтрiв на окремi спектри, що вiдповiдають iндивiдуальним каналам, i демодулюється. Канальнi демодулятори перетворять спектри сигналiв у спектри повiдомлень, призначенi для одержувачiв. <br /> <br /> == Спектральний подiл каналiв (СПК) ==<br /> <br /> СПК (WDW - Wavelength Division Multiplexing) як рiзновид ЧПК використовується для передачi безлiчi незалежних iнформацiйних потокiв одним волоконо-оптичним трактом. Допускаються передачi аналогових i цифрових сигналiв незалежно вiд протоколiв i швидкостей передачi. Кожен потiк передається на своїй довжинi хвилi в межах вiкна прозоростi волоконного свiтоводу. Звичайно це вiкно 1550 нм. Передача забезпечується шляхом мультиплексування окремих несущих частот з iнформацiйними сигналами i наступним демультиплексуванням переданого сигналу на окремi потоки. Принцип СПК застосовується в апаратурi волоконно-оптичних систем передач. <br /> <br /> == Частотно-тимчасовий подiл каналiв (ЧТПК) ==<br /> <br /> ЧТПК полягає в тому, що спочатку смуга частот, призначена для передачi аналогових сигналiв (наприклад, смуга каналу ТЧ) розбивається на декiлька пiдполос, а потiм у кожнiй з них виробляється подiл каналiв по тимчасовому принципу (ТПК). В iндивiдуальних цифрових каналах, сформованих таким чином, може використовуватися будь-який вид модуляцiї дискретних сигналiв (IКМ, ДIКМ), а для модуляцiї групових сигналiв у кожнiй з пiдполос - будь-який вид модуляцiї аналогових сигналiв (AM, ЧМ, ФМ i iн.). Принцип ЧТПК використовується в телеграфній каналоутворюючий апаратурi. <br /> <br /> == Кодовий подiл каналiв (КПК) ==<br /> При КПК кожному iндивiдуальному каналу призначається своя характерна ключова ознака (код). Такою ознакою може бути номер приймача одержувача iнформацiї. Потiм iндивiдуальнi канали поєднуються в передавачi в груповий сигнал, що передається по каналу зв'язку. Кожному iндивiдуальному каналу видiляється одна і та ж сама широка смуга частот, так що пiд час передачi канали накладаються один на одного, але оскiльки їх коди вiдрiзняються, вони можуть бути легко видiленi на прийомнiй сторонi. Принцип КПК реалiзований у системах сотового радiозв'язку, що використовують технологiю багатостанцiонного доступу CDMA.<br /> <br /> <br /> == Комутація каналів на основі частотного мультиплексування ==<br /> <br /> Техніка частотного мультиплексування каналів (FDM) була розроблена для телефонних мереж, але застосовується вона і для інших видів мереж, наприклад мереж кабельного телебачення. Розглянемо особливості цього виду мультиплексування на прикладі телефонної мережі.<br /> <br /> Мовні сигнали мають спектр шириною приблизно в 10 000 Гц, однак основні гармоніки укладаються в діапазон від 300 до 3400 Гц. Тому для якісної передачі мови досить утворити між двома співрозмовниками канал зі смугою пропущення в 3100 Гц, що і використовується в телефонних мережах для з'єднання двох абонентів. У той же час смуга пропущення кабельних систем з проміжними підсилювачами, що з'єднують телефонні комутатори, між собою, звичайно складає сотні кілогерців, а іноді і сотні мегагерц. Однак безпосередньо передавати сигнали декількох абонентських каналів по широкополосному каналу неможливо, тому що усі вони працюють у тому самому діапазоні частот і сигнали різних абонентів змішаються між собою так, що розділити їх буде неможливо.<br /> <br /> Для поділу абонентських каналів характерна техніка модуляції високочастотного несучого синусоїдального сигналу низькочастотним мовним сигналом '''(мал. 2.26)'''. Ця техніка подібна техніці аналогової модуляції при передачі дискретних сигналів модемами, тільки замість дискретного вихідного сигналу використовуються безупинні сигнали, що породжуються звуковими коливаннями. У результаті спектр модульованого сигналу переноситься в інший діапазон, що симетрично розташовується відносно несучої частоти і має ширину, що приблизно збігається із шириною сигналу, що модулює.&lt;br&gt;<br /> [[Image:ММС.JPG]]<br /> &lt;br&gt;<br /> мал. 2.26.Техніка модуляції високочастотного несучого синусоїдального сигналу низькочастотним мовним сигналом.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/TCP/IP 2011-12-19T14:27:39Z

<p>Aleksey: </p> <hr /> <div>==Вступ (TCP/IP)==<br /> Протоколи мережної взаємодії TCP/IP є результатом еволюційного розвитку протоколів глобальної обчислювальної мережі ARPANET. <br /> Роботи зі створення мережі ARPANET були розпочаті рядом університетів США і фірмою [http://itc.ua/node/16632/ BBN] у 1968 р. У 1971 р. мережа була введена в регулярну експлуатацію і забезпечувала для усіх своїх вузлів три основні послуги: <br /> · інтерактивний вхід користувача на вилучений вузол; <br /> · передача файлів між вузлами мережі; <br /> · електронна пошта. <br /> Усі ці засоби базувалися на транспортних послугах, наданих програмою керування мережі NCP (Network Control Program), що реалізує свій внутрішній набір протоколів. <br /> Накопичений до 1974 р. досвід експлуатації мережі ARPANET виявив багато недоліків протоколів NCP і дозволив визначити основні вимоги до нового набору протоколів, що отримали назву TCP/IP: <br /> · незалежність від середовища передачі повідомлень; <br /> · можливість підключення до мережі ЕОМ будь-якої архітектури; <br /> · єдиний спосіб організації з'єднання між вузлами в мережі; <br /> · стандартизація прикладних протоколів. <br /> Широко використовувана нині версія 4 протоколів TCP/IP була стандартизована в 1981 р. у вигляді документів, названих RFC (Request For Comment). Повний перехід мережі ARPANET на нові протоколи був завершений у 1982 р. Ця мережа зіграла роль &quot;зародка&quot; всесвітньої мережі Internet, побудованої на базі протоколів TCP/IP. <br /> Реалізація протоколів TCP/IP виявилася найбільш вдалою у версіях BSD4.2 і BSD4.3 операційної системи UNIX. Ця реалізація є еталоном (стандартом &quot;de facto&quot;) для всіх наступних. <br /> <br /> ==Основи TCP/IP==<br /> TCP/IP - це засіб для обміну інформацією між комп'ютерами, об'єднаними в мережу. Не має значення, чи складають вони частину однієї і тієї ж мережі або підключені до окремих мереж. Не грає ролі і те, що один з них може бути комп'ютером Cray, а інший Macintosh. TCP/IP - це не залежний від платформи стандарт, що перекидає мости через прірву, що лежить між різнорідними комп'ютерами, операційними системами і мережами. Це протокол, що глобально керує Internet, і значною мірою завдяки мережі TCP/IP завоював свою популярність. <br /> <br /> Розуміння TCP/IP головним чином має на увазі здатність розбиратися в наборах таємничих протоколів, що використовуються головними комп'ютерами TCP/IP для обміну інформацією. <br /> '''''TCP/IP''''' – це абревіатура терміна Transmission Control Protocol/Internet Protocol (Протокол керування передачею/Протокол Internet). У термінології обчислювальних мереж ''протокол'' – це заздалегідь погоджений стандарт, що дозволяє двом комп'ютерам обмінюватися даними. Фактично TCP/IP не один протокол, а декілька. Саме тому ви часто чуєте, як його називають набором, або комплектом протоколів, серед яких TCP і IP - два основних. <br /> <br /> Програмне забезпечення для TCP/IP, на комп'ютері, являє собою специфічну для даної платформи реалізацію TCP, IP і інших членів сімейства TCP/IP. Звичайно в ньому також маються такі високорівневі прикладні програми, як FTP (File Transfer Protocol, Протокол передачі файлів), що дають можливість через командний рядок керувати обміном файлами по мережі. <br /> <br /> Причина, по якій TCP/IP настільки важливий сьогодні, полягає в тому, що він дозволяє самостійним мережам підключатися до Internet або поєднуватися для створення часток інтрамереж. Обчислювальні мережі, що складають інтрамережу, фізично підключаються через пристрої, що називаються маршрутизаторами або IP-маршрутизаторами. '''[[Маршрутизатор]]''' - це комп'ютер, що передає пакети даних з однієї мережі в іншу. В інтрамережі, що працює на основі TCP/IP, інформація передається у виді дискретних блоків, що називаються IP-пакетами (IP packets) або IP-дейтаграмами (IP datagrams). Завдяки програмному забезпеченню TCP/IP усі комп'ютери, підключені до обчислювальної мережі, стають &quot;близькими родичами&quot;. Власне кажучи воно ховає маршрутизатори і базову архітектуру мереж і робить так, що все це виглядає як одна велика мережа. Точно так само, як підключення до мережі Ethernet розпізнаються по 48-розрядних ідентифікаторах Ethernet, підключення до інтрамережі ідентифікуються 32-розрядними IP-адресами, що ми виражаємо у формі десяткових чисел, розділених крапками (наприклад, 128.10.2.3). Узявши IP-адресу вилученого комп'ютера, комп'ютер в інтрамережі або в Internet може відправити дані на нього, начебто вони складають частину однієї і тієї ж фізичної мережі. <br /> <br /> TCP/IP дає рішення проблеми обміну даними між двома комп'ютерами, підключеними до одній і тієї ж інтрамережі, але приналежним різним фізичним мережам. Рішення складається з декількох частин, причому кожен член сімейства протоколів TCP/IP вносить свою лепту в загальну справу.<br /> <br /> ==Структура стеку TCP/IP==<br /> &lt;center&gt;[[Image:777.PNG]]&lt;/center&gt;<br /> <br /> [[ARP]]. (Address Resolution Protocol, протокол визначення адрес): протокол для визначення фізичної адреси інтерфейсу. Ця адреса необхідна для формування заголовка пакета канального рівня (кадру). Пакети ARP протоколу не доповнюються IP-заголовком міжмережного рівня, а одразу пакуються в кадри (пакети канального рівня), бо вони циркулюють тільки в межах однієї мережі.<br /> <br /> [[ATM]] ( Asynchronous Transfer Mode ) – нова універсальна технологія побудови каналів зв’язку для глобальних і локальних мереж, що забезпечує гарантовану якість і терміновість передавання даних. За цією технологією створюють нові швидкісні магістральні мережі для передавання даних в Україні. Високі ціни на обладнання стримують процес розширення застосування технології ATM . <br /> <br /> [[DNS]] ( Domain Name System ) – доменна система імен, яка призначена для перетворення символьних імен мережних ресурсів у цифрові адреси серверів, де розміщено ці ресурси. <br /> <br /> Ethernet – найбільш розповсюджена технологія побудови каналів зв’язку у локальних мережах. <br /> <br /> Frame Relay – найбільш розповсюджена технологія побудови каналів зв’язку для глобальних мереж. <br /> <br /> [[FTP]] (File Transfer Protocol, протокол передачі файлів): дозволяє передавати файли з одного комп'ютера на іншій з використанням TCP-з'єднань. У схожому, але менш розповсюдженому протоколі передачі файлів - Trivial File Transfer Protocol (TFTP) - для пересилання файлів застосовується UDP, а не TCP. <br /> <br /> [[HTTP]] ( Hypertext Transfer Protocol ) – протокол для передавання Web -сторінок (гіпертексту). <br /> <br /> [[ICMP]] (Internet Control Message Protocol, протокол керуючих повідомлень Internet): дозволяє IP-маршрутизаторам посилати повідомлення про помилки і керуючу інформацію іншим IP-маршрутизаторам і головним комп'ютерам мережі. ICMP-повідомлення &quot;подорожують&quot; у вигляді полів даних IP-дейтаграм і обов'язково повинні реалізовуватися у всіх варіантах IP. <br /> <br /> [[IGMP]] (Internet Group Management Protocol, протокол керування групами Internet): дозволяє [[IP-дейтаграмам]] поширюватися в циркулярному режимі (multicast) серед комп'ютерів, що належать до відповідних груп. <br /> <br /> [[IP]] (Internet Protocol, протокол Internet): низькорівневий протокол, що направляє пакети даних по окремих мережах, зв'язаних разом за допомогою маршрутизаторів для формування Internet або інтрамережі. Дані &quot;подорожують&quot; у формі пакетів, називаних IP-дейтаграмами. <br /> <br /> [[Протокол ІРv6]]<br /> <br /> [[PPP]] ( Point - to - Point Protocol ) – протокол, що широко застосовують для побудови каналу зв’язку між двома віддаленими вузлами, що з’єднані між собою фізичною лінією зв’язку. <br /> <br /> [[RARP]] (Reverse Address Resolution Protocol, протокол зворотного перетворення адрес): перетворить фізичні мережні адреси в IP-адреси. <br /> <br /> [[SMTP]] (Simple Mail Transfer Protocol, простий протокол обміну електронною поштою): визначає формат повідомлень, що SMTP-клієнт, що працює на одному комп'ютері, може використовувати для пересилання електронної пошти на SMTP-сервер, запущений на іншому комп'ютері. <br /> <br /> [[TCP]] (Transmission Control Protocol, протокол керування передачею): протокол орієнтований на роботу з підключеннями і передає дані у вигляді потоків байтів. Дані пересилаються пакетами - TCP-сегментами, - які складаються з заголовків TCP і даних. TCP - &quot;надійний&quot; протокол, тому що в ньому використовуються контрольні суми для перевірки цілісності даних і відправлення підтверджень, щоб гарантувати, що передані дані прийняті без перекручувань. <br /> <br /> [[UDP]] (User Datagram Protocol, протокол користувацьких дейтаграм): протокол, що не залежить від підключень, що передає дані пакетами, називаними UDP-дейтаграмами. UDP - &quot;ненадійний&quot; протокол, оскільки відправник не одержує інформацію, що показує, чи була в дійсності прийнята [[дейтаграма]]. <br /> <br /> [[SNMP]] (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури TCP/IP.<br /> <br /> ==Рівні протоколів TCP/IP==<br /> Найнижчий (&lt;b&gt;&lt;I&gt;рівень IV&lt;/I&gt;&lt;/b&gt;) відповідає фізичному і канальному рівням моделі OSI. Цей рівень у протоколах TCP/IP не регламентується, але підтримує всі популярні стандарти фізичного і канального рівня: для локальних мереж це Ethernet, Token Ring, FDDI, Fast Ethernet, 100VG-AnyLAN, для глобальних мереж - протоколи з'єднань &quot;крапка-крапка&quot; SLIP і PPP, протоколи територіальних мереж з комутацією пакетів X.25, frame relay. Розроблена також спеціальна специфікація, що визначає використання технології ATM як транспорт канального рівня. Звичайно з появою нової технології локальних або глобальних мереж вона швидко включається в стек TCP/IP за рахунок розробки відповідного [[RFC]], що визначає метод інкапсуляції пакетів IP у її кадри. <br /> <br /> Наступний рівень (&lt;b&gt;&lt;I&gt;рівень III&lt;/I&gt;&lt;/b&gt;) - це рівень межмережевої взаємодії, що займається передачею пакетів з використанням різних транспортних технологій локальних мереж, територіальних мереж, ліній спеціального зв'язку і т.п. <br /> <br /> Як основний протокол мережного рівня (у термінах моделі OSI) у стеку використовується протокол IP, що споконвічно проектувався як протокол передачі пакетів у складених мережах, що складаються з великої кількості локальних мереж, об'єднаних як локальними, так і глобальними зв'язками. Тому протокол IP добре працює в мережах зі складною топологією, раціонально використовуючи наявність у них підсистем і ощадливо витрачаючи пропускну здатність низькошвидкісних ліній зв'язку. Протокол IP є дейтаграмним протоколом, тобто він не гарантує доставку пакетів до вузла призначення, але намагається це зробити. <br /> <br /> До рівня міжмережевої взаємодії відносяться і всі протоколи, зв'язані зі складанням і модифікацією таблиць маршрутизації, такі як протоколи збору маршрутної інформації [[RIP]] (Routing Internet Protocol) і OSPF (Open Shortest Path First), а також протокол міжмережевих керуючих повідомлень ICMP (Internet Control Message Protocol). Останній протокол призначений для обміну інформацією про помилки між маршрутизаторами мережі і вузлом - джерелом пакета. За допомогою спеціальних пакетів ICMP повідомляється про неможливість доставки пакета, про перевищення часу життя або тривалості зборки пакета з фрагментів, про аномальні величини параметрів, про зміну маршруту пересилання і типу обслуговування, про стан системи і т.п. <br /> <br /> Наступний рівень (&lt;b&gt;&lt;I&gt;рівень II&lt;/I&gt;&lt;/b&gt;) називається основним. На цьому рівні функціонують протокол керування передачею TCP (Transmission Control Protocol) і протокол дейтаграм користувача UDP (User Datagram Protocol). Протокол TCP забезпечує надійну передачу повідомлень між вилученими прикладними процесами за рахунок утворення віртуальних з'єднань. Протокол UDP забезпечує передачу прикладних пакетів дейтаграмним способом, як і IP, і виконує тільки функції сполучної ланки між мережним протоколом і численними прикладними процесами. <br /> <br /> Верхній рівень (&lt;b&gt;&lt;I&gt;рівень I&lt;/I&gt;&lt;/b&gt;) називається прикладним. За довгі роки використання в мережах різних країн і організацій стік TCP/IP нагромадив велику кількість протоколів і сервісів прикладного рівня. До них відносяться такі широко використовувані протоколи, як протокол копіювання файлів FTP, протокол емуляції термінала telnet, поштовий протокол SMTP, використовуваний в електронній пошті мережі Internet, гіпертекстові сервіси доступу до вилученої інформації, такі як WWW і багато хто інші. <br /> ==Адресація у ІР-мережах==<br /> Міжмережна схема адресації, що застосовується у протоколі ІР, описана у документах RFC 990 i RFC 997. В її основі покладено принцип відокремлення адресації мереж від адресації пристроїв у цих мережах. Така схема полегшує маршрутизацію. При цьому адреси повинні призначатися упорядковано (послідовно), для того, щоб зробити маршрутизацію більш ефективною.<br /> <br /> При застосуванні у мережі стеку протоколів ТСР/ІР порти кінцевих пристроїв отримують унікальні адреси, тобто адресується не сам пристрій у мережі, а визначене з'єднання цього пристрою з мережею. Ця схема приводить до низки неподобств. Одним з них є необхідність заміни адреси пристрою при переміщенні його у іншу мережу. Другий недолік в тім, що для роботи з пристроєм, який має декілька підключень у розподіленій мережі, необхідно знати всі його адреси, які ідентифікують ці підключення. <br /> <br /> Отже для кожного пристрою у мережах ІР можна говорити про адреси трьох рівнів:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Фізична адреса пристрою (точніше - визначеного інтерфейсу). Для пристроїв у мережах Ethernet - це МАС-адреса мережної карти або порту маршрутизатора. Ці адреси призначаються виробниками обладнання. Фізична адреса має шість байтів: старші три байти - ідентифікатор фірми-виробника. Молодші три байти призначаються самим виробником;&lt;/li&gt;<br /> &lt;li&gt;ІР-адреса, що складається з чотирьох байтів. Ця адреса застосовується на мережному рівні еталонної моделі OSI;&lt;/li&gt;<br /> &lt;li&gt;Символьний ідентифікатор - ім'я. Цей ідентифікатор може призначатися адміністратором довільно.&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Коли протокол ІР був стандартизований у вересні 1981 року, його специфікація вимагала, щоб кожний пристрій, підключений до мережі, мав унікальну 32-бітну адресу. Ця адреса поділяється на дві частини. Перша частина адреси ідентифікує мережу, в якій розміщений пристрій. Друга частина однозначно ідентифікує самий пристрій у рамках мережі. Така схема приводить до дворівневої адресної ієрархії.<br /> <br /> Зараз поле номера мережі у адресі називається мережним префіксом, так як воно ідентифікує мережу. Всі робочі станції у мережі мають один і той же префікс. При цьому вони повинні мати унікальні номери пристроїв. Дві робочі станції, розміщені в різних мережах, повинні мати різні мережні префікси, але при цьому вони можуть мати однакові номери пристроїв. <br /> <br /> Для забезпечення гнучкості у привласнюванні адрес комп'ютерним мережам розробники протоколу визначили, що адресний простір повинен бути поділений на три різних класи - А, В і С. Знаючи клас, Ви знаєте, де у 32-бітовій адресі проходить межа між мережним префіксом і номером пристрою. На мал.1 показані формати адрес цих основних класів.<br /> &lt;center&gt;[[Image:1 419.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.1 Три класи ІР-адрес.&lt;/center&gt;<br /> <br /> Одна з основних переваг застосування класів є в тім, що по класу адреси можна визначити, де проходить межа між мережним префіксом і номером пристрою. <br /> <br /> Недоліком такого методу є необхідність зміни мережної адреси при підключенні додаткових пристроїв. Наприклад, якщо загальне число пристроїв у мережі класу С буде перевищувати 255, то вимагатиметься заміна її адреси на адресу класу В. Зміна мережних адрес потребує від адміністратора додаткових зусиль по налагодженню мережі. Крім того, введення класів адрес значно зменшує теоретично можливе число індивідуальних адрес. У поточній версії протоколу ІР (версія 4) загальне число адрес складає 4 294 967 296, так як протокол передбачає застосування 32 біт для задання адреси. Природньо, застосування частини бітів у службових цілях зменшує доступну кількість індивідуальних адрес.<br /> <br /> Клас А призначений для великих мереж. Кожна адреса класу А має 8-бітовий префікс мережі, у якому старший біт встановлений у 1, а наступні 7 використовуються для номера мережі. Для номера пристрою задіюються 24 біти, що залишилися. На сьогоднішній день всі адреси класу А вже виділені. Мережі класу А також позначаються як &quot;/8&quot;, поскільки адреси цього класу мають 8-бітовий префікс.<br /> <br /> Максимальне число мереж класу А складає 126 (2 адреси віднімаються, що складаються з одних нулів і одиниць). Кожна мережа цього класу підтримує до 16 777 214 пристроїв. Так як адресний блок класу А може містити максимум 2 147 483 648 (2 в степіні 31) індивідуальних адрес, а в протоколі ІР версіі 4 може підтримуватися максимум до 4 294 967 296 (2 в степіні 32) адрес, то клас А займає 50% загального адресного простору протоколу ІР.<br /> <br /> Клас В призначений для мереж середнього розміру. Кожна адреса класу В має 16-бітовий мережний префікс, у якому два старших біти дорівнюють 10, наступні 14 біт використовуються для номера мережі. Для номера пристрою надані 16 біт. Мережі класу В також позначаються як &quot;/16&quot;, поскільки адреса цього класу має 16-бітний мережний префікс.<br /> <br /> Максимальне число мереж класу В дорівнює 16 382 (2 в 14 степіні мінус 2). Кожна мережа цього класу підтримує до 65 534 (2 в 16 степіні мінус 2) пристроїв. Так як весь адресний блок класу В може містити максимум до 1 073 741 824 (2 в 30 степіні) індивідуальних адрес, він займає 25% загального простору протоколу ІР.<br /> <br /> Адреса класу С використовується у мережах з невеликим числом пристроїв. Кожна мережа класу С має 24-бітний префікс, в якому три старших біти дорівнюють 110, а наступні 21 біт використовуються для номера мережі. Під номери пристроїв виділені 8 біт, що залишилися. Мережі класу С також позначаються як &quot;/24&quot;, поскільки адреса цього класу має 24-бітний мережний префікс.<br /> <br /> Максимальне число мереж класу С складає 2 097 152 (2 в 21 степіні). Кожна мережа цього класу підтримує до 254 (2 у восьмій мінус 2) пристроїв. Клас С займає 12,5% загального адресного простору протоколу ІР.<br /> <br /> У доповнення до цих класів адрес надають ще два класи. У класі D старші чотири біти дорівнюють 1110. Цей клас використовується для групової передачі даних. У класі Е старші чотири біти дорівнюють 1111. Він зарезервований для проведення експериментів.<br /> <br /> Для зручності читання адрес у технічній літературі, прикладних програмах і т.д. ІР-адреси зображаються у вигляді чотирьох десяткових чисел, розділених точками. Кожне з цих чисел відповідає одному октету (8 бітам) ІР-адреси. Цей формат називають точечно-десятковим (Decimal-Point Notation) або точечно-десятковою нотацією.<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;2&quot;<br /> |+ ІР-адреса у точечно-десятковому форматі.<br /> |-<br /> ! 0... !! !! !! ...31<br /> |-<br /> ! 10010001 !! 00001010 !! 00100010 !! 00000011<br /> |-<br /> ! 145. !! 10. !! 34. !! 3.<br /> |}<br /> <br /> <br /> <br /> ==Особливі ІР-адреси==<br /> У протоколі ІР існує декілька домовленостей про особливу інтерпретацію ІР-адрес. <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Якщо вся ІР-адреса складається тільки з двійкових нулів, то вона означає адресу того вузла, який згенерував цей пакет; цей режим використовується тільки у деяких повідомленнях ІСМР. &lt;/li&gt;<br /> &lt;li&gt;Якщо в полі адреси мережі стоять тільки нулі, по домовленості вважається, що вузол призначення належить тій самій мережі, що і вузол , який відправив пакет. &lt;/li&gt;<br /> &lt;li&gt;Якщо всі двійкові розряди ІР-адреси дорівнюють 1, то пакет з такою адресою призначення повинен розсилатися всім вузлам, які знаходяться у тій самій мережі, що і відправник цього пакета. Така розсилка називається обмеженим широкомовним повідомленням (limited broadcast).&lt;/li&gt; <br /> &lt;li&gt;Якщо в полі номера вузла призначення стоять тільки одиниці, то пакет, який має таку адресу, розсилається всім вузлам мережі із заданим номером мережі. Наприклад, пакет з адресою 192.190.21.255 доставляється всім вузлам мережі 192.190.21.0. Таке розсилання називається широкомовним повідомленням (broadcast). &lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Особливий зміст має ІР-адреса, перший октет якої дорівнює 127. Вона використовується для тестування програм і взаємодії процесів у межах однієї машини. Коли програма посилає дані за адресою 127.0.0.1, то утворюється як би &quot;петля&quot;. Дані не передаються по мережі, а повертаються модулям верхнього рівня як тільки но прийняті. Тому в ІР-мережі забороняється привласнювати машинам ІР-адреси, які починаються із 127. Ця адреса має назву loopback.<br /> <br /> У протоколі ІР немає поняття широкомовності у тому понятті, в якому воно використовується у протоколах канального рівня локальних мереж, коли дані повинні бути доставлені абсолютно всім вузлам. Як обмежена широкомовна ІР-адреса, так і широкомовна ІР-адреса мають межі розповсюдження у інтермережі - вони обмежені або мережею, до якої належить вузол-джерело пакета, або мережею, номер якої вказаний у адресі призначення. Тому поділ мережі за допомогою маршрутизаторів на частини локалізує широкомовний шторм межами однієї з частин, що складають загальну мережу просто тому, що немає способа адресувати пакет одночасно всім вузлам всіх мереж складеної мережі.<br /> <br /> Форма групової адреси - multicast - означає, що даний пакет повинен бути доставлений відразу декільком вузлам, які утворюють групу з номером, вказаним у полі адреси. Вузли самі ідентифікують себе, тобто визначають, до якої з груп вони відносяться. Один і той самий вузол може входити до декількох груп. Члени будь-якої групи multicast не обов'язково повинні належати одній мережі. Групова адреса не поділяється на поля номера мережі і вузла і обробляється маршрутизатором особливим чином.<br /> <br /> Основне призначення multicast-адрес - розповсюдження інформації за схемою &quot;один-до-багатьох&quot;. Хост, який хоче передавати одну й ту саму інформацію багатьом абонентам, за допомогою спеціального протокола IGMP (Internet Group Management Protocol) повідомляє про створення в мережі нової мультімовної групи із визначеною адресою. Маршрутизатори, які підтримують мультімовність, розповсюджують інформацію про створення нової групи у мережах, підключених до портів цього маршрутизатора. Хости, які хотять під'єднатися до знов створюваної мультімовної групи, повідомляють про це своїм локальним маршрутизаторам і ті передають цю інформацію хосту, ініціатору створення нової групи.<br /> <br /> Щоб маршрутизатори мали можливість автоматично розповсюджувати пакети з адресою multicast по складній мережі, необхідно використовувати у кінцевих маршрутизаторах модифіковані протоколи обміну маршрутною інформацією, такі як, наприклад, MOSPF (Multicast OSPF, аналог OSPF).<br /> Групова адресація призначена для економічного розповсюдження у Internet або у великій корпоративній мережі аудіо- чи відеопрограм, призначених одразу великій аудиторії слухачів або глядачів. Якщо такі засоби знайдуть широке застосування, то Internet зможе створити серйозну конкурецію радіо і телебаченню.<br /> <br /> ==Використання масок у ІР-адресації==<br /> Традиційна схема поділу ІР-адреси на номер мережі і номер вузла базується на понятті класу, який визначається значеннями кількох перших біт адреси. Саме тому, що перший байт адреси 185.23.44.206 попадає у діапазон 128-191, ми можемо сказати, що ця адреса відноситься до класу В, а значить, номером мережі є перші два байти, доповнені двома нульовими байтами - 185.23.0.0, а номером вузла - 0.0.44.206.<br /> <br /> Для гнучкого встановлення межі між номером мережі і номером вузла використовують маску, Маска - це число, яке використовується у парі з ІР-адресою; двійковий запис маски містить одиниці у тих розрядах, які повинні у ІР-адресі інтерпретуватися як номер мережі. Поскільки номер мережі є цілою частиною адреси, одиниці у масці також повинні бути безперервною послідовністю. Для стандартних класів мереж маски мають такі значення:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;клас А - 11111111.00000000.00000000.00000000 (255.0.0.0); &lt;/li&gt;<br /> &lt;li&gt;клас В - 11111111.11111111.00000000.00000000 (255.255.0.0);&lt;/li&gt; <br /> &lt;li&gt;клас С - 11111111.11111111.11111111.00000000 (255.255.255.0).&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Для запису масок використовують і інші формати, наприклад, зручно інтерпретувати значення маски, записаної у шістнадцятьковому коді: FF.FF.00.00 - маска для адрес класу В. Часто зустрічається і таке позначення 185.23.44.206/16 - цей запис означає, що маска для цієї адреси містить 16 одиниць або що у вказаній адресі під номер адреси мережі відведено 16 двійкових розрядів.<br /> <br /> ==Адресація і технологія CIDR==<br /> <br /> Технологія безкласової междоменной маршрутизації (Classless Inter-Domain Routing, CIDR), яка описана в документах RFC 1517, RFC 1518, RFC 1519, RFC 1520 і яка вперше була офіційно оголошена в 1993 році, дозволяє центрам розподілу адрес уникнути видачі абонентам зайвих адрес.<br /> <br /> Розподіл IP-адреси на номери мережі і вузла в технології CIDR відбувається на основі маски змінної довжини, що призначається постачальником послуг. Необхідною умовою застосування CIDR є наявність у організації, що розпоряджається адресами, безперервних діапазонів адрес. Такі адреси мають однаковий префікс, тобто однакову цифрову послідовність у кількох старших розрядах. Нехай в розпорядженні деякого постачальника послуг є безперервний простір IP-адрес в кількості 2n. Звідси випливає, що префікс має довжину (32 - n) розрядів. Решта n розрядів грає роль лічильника послідовних номерів.<br /> <br /> &lt;center&gt;[[Файл:Cidr.jpg]]&lt;/center&gt;<br /> <br /> Коли споживач звертається до постачальника послуг з проханням про виділення йому деякого числа адрес, то в наявному пулі адрес «вирізається» неперервна область S1,S2 або S3, в залежності від необхідної кількості адрес. При цьому повинні бути виконані<br /> наступні умови:<br /> <br /> * кількість адрес у виділеної області має дорівнювати степеню двійки;<br /> <br /> * початкова межа пулу адрес, що виділяється повинна бути кратна необхідній кількості вузлів.<br /> <br /> Очевидно, що префікс кожної з показаних на малюнку областей має власну довжину - чим менше кількість адрес в даній області, тим довший її префікс.<br /> <br /> Завдяки CIDR постачальник послуг одержує можливість «нарізати» блоки з виділеного йому адресного простору відповідно до вимог кожного<br /> клієнта.<br /> <br /> ==Підмережі==<br /> Як відомо, ІР-адреса складається з двох їєрархічних рівнів. Необхідність у введенні третього рівня їєрархії - рівня підмереж - була зумовлена виникненням дефіциту номерів мереж і стрімким зростанням таблиць маршрутизації маршрутизаторів у Internet. Після впровадження рівня підмережі номер пристрою поділяється на дві частини - номер підмережі та номер пристрою у цій підмережі.<br /> <br /> &lt;center&gt;[[Image:1 424.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.2 Формування трьохрівневої ієрархії.&lt;/center&gt;<br /> <br /> Збільшення кількості рівнів знімає проблему зростання таблиць маршрутизації завдяки тому, що інформація про топологію корпоративних мереж стає непотрібною магістральним маршрутизаторам Internet. Маршрути з мережі Internet до будь-якої конкретної підмережі, розташованої у мережі із заданою ІР-адресою, однакові і не залежать від того, у якій підмережі розташований отримувач. Це стало можливим завдяки тому, що всі підмережі мережі із заданим номером використовують один і той самий мережний префікс, хоч їх номери (номери підмереж) різні. Маршрутизаторам у приватній мережі потрібно відрізняти окремі підмережі, але для маршрутизаторів Internet всі підмережі відносяться до єдиного запису у таблиці маршрутизації. Це дозволяє адміністратору приватної мережі вносити будь-які зміни у логічну структуру всієї мережі, не впливаючи на розмір таблиць маршрутизації маршрутизаторів Internet.<br /> <br /> Крім того, легко розв'язується проблема виділення номерів при рості організації. Організація отримує номер мережі, а далі адміністратор довільно привласнює номери підмереж для кожної внутрішньої мережі. Це дозволяє організації розширювати свою мережу без необхідності отримання ще одного мережного номера.<br /> ==Маска підмережі==<br /> Якщо маршрутизатори у мережі Internet використовують тільки мережний префікс адреси отримувача для передачі трафіка у організацію, то марщрутизатори всередині приватної мережі організації розширений мережний префікс для передачі трафіка індивідуальним підмережам. Розширеним мережним префіксом називають префікс мережі і номер підмережі.<br /> <br /> &lt;center&gt;[[Image:1 425.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.3 Розширений мережний префікс.&lt;/center&gt;<br /> <br /> Поняття розширеного мережного префікса, по суті, еквівалентно поняттю маска підмережі (subnet mask). Маска підмережі - це двійкове число, яке містить одиниці у тих розрядах, які відносяться до розширеного мережного префікса. Маска підмережі дозволяє поділити ІР-адресу на дві частини: номер підмережі та номер пристрою у цій підмережі.<br /> <br /> Старші біти ІР-адреси використовуються робочими станціями і маршрутизаторами для визначення класу адреси. Після того, як клас визначений, пристрій може легко визначити межу між бітами, які використовувалися для ідентифікації номера мережі, і бітами номера пристрою у цій мережі. Однак для визначення межі бітів, які ідентифікують номер підмережі, така схема не підходить. Для цього саме і використовується 32-бітна маска підмережі, яка допомогає однозначно визначити необхідну межу.<br /> <br /> Біти у масці підмережі повинні бути усталені в одиницю, якщо система, яка перевіряє адресу, повинна розглядати відповідний біт у ІР-адресі як частину мережного префікса. Після визначення класу ІР-адреси, будь-який біт у номері пристрою, який має відповідний усталений біт у масці підмережі, використовується для ідентифікації номера підмережі. Частина номера пристрою, що залишилася, і якій відповідають нульові біти у масці підмережі, використовуються для задання номера пристрою. <br /> <br /> Документ RFC 1219 визначає основне правило, якому слід дотримуватися при привласнюванні номерів підмережам і пристроям. Номери підмереж призначаються таким чином, щоб старші біти у номері підмережі встановлювалися першими (тобто починаючи з крайньої лівої позиції). В той же час одиничні біти номериівпристроїв рекомендується встановлювати, починаючи з крайньої правої позиції. Отже, якщо дотримуватися цього правила, то на межі між номером підмережі і номером пристрою будуть існувати нульові невикористані біти. Це дозволяє змінити маску підмережі без зміни ІР-адреси, привласненої пристрою.<br /> <br /> У мережі із підмережами можна використовувати два види широкомовлення: направлене і обмежене. Направлене широкомовлення використовується для передавання дейтаграми всім пристроям визначеної підмережі. Для відправки дейтаграми всім пристроям у всіх підмережах необхідно використати обмежене широкомовлення із адресою 255.255.255.255. Необхідно, однак, врахувати, що маршрутизатори не пропускають дейтаграми з такою адресою (тому таке широкомовлення називається обмеженим).<br /> <br /> Номери мереж призначаються централізовано, якщо мережа є частиною Internet, або довільно, якщо мережа працює автономно. Номери вузлів і в тому і в іншому випадку адміністратор може призначати самостійно, не виходячи з дозволеного для цього класу мережі діапазону.<br /> <br /> Координуючу роль у централізованому розподілі ІР-адрес спочатку відігравала організація InterNIC, однак із зростанням мережі задача розподілу адрес стала дуже складною, і InterNIC делегувала частину своїх функцій іншим організаціям і крупним поставщикам послуг Internet.<br /> <br /> Якщо деяка ІР-мережа створена для роботи у &quot;автономному режимі&quot;, без зв'язку з Internet, в стандартах Internet визначено декілька діапазонів адрес, рекомендуємих для локального використання. Ці адреси не обробляються маршрутизаторами Internet ні за яких умов. Адреси, зарезервовані для локальних цілей, вибрані з різних класів: у класі А - це мережа 10.0.0.0, у класі В - це діапазон з 16 номерів мереж 172.16.0.0. - 172.31.0.0, у класі С - це діапазон з 255 мереж - 192.168.0.0. - 192.168.255.0.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Cidr.jpg 2011-12-19T14:21:26Z

<p>Aleksey: </p> <hr /> <div></div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%9E%D0%B1%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%B5%D0%BD%D0%BD%D1%8F:%D0%91%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B0_%D0%BA%D0%BE%D0%BC%D0%BF%27%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D0%B8%D1%85_%D0%BC%D0%B5%D1%80%D0%B5%D0%B6 2011-12-19T13:21:23Z

<p>Aleksey: </p> <hr /> <div>&quot;Чи необхідно вмикати брандмауер Windows, якщо є маршрутизатор із вбудованим брандмауером?&quot;<br /> --[[Користувач:Sergpsw|Sergpsw]] 10:58, 15 грудня 2011 (EET)<br /> <br /> Так, оскільки маршрутизатори із вбудованими брандмауерами надають захист від загроз, що надходять з інших комп’ютерів в Інтернеті, проте не захищають у домашній мережі. Наприклад, якщо портативний або гостьовий комп’ютер, заражений вірусом під час підключення до іншої мережі, підключити до вашої домашньої мережі, маршрутизатор із вбудованим брандмауером не зможе запобігти розповсюдженню хробака. Однак запуск брандмауера на всіх комп’ютерах у мережі може допомогти контролювати процес розповсюдження вірусів.<br /> --[[Користувач:Піменова Олена|Піменова Олена]] 11:08, 15 грудня 2011 (EET)<br /> <br /> Після аутентифікації наступним етапом є авторизація. Хотілося б докладно почитати про процедуру авторизації. --[[Користувач:Aleksey|Новіков Олексій]] 13:12, 19 грудня 2011 (EET)</div>

Aleksey https://wiki.cusu.edu.ua/index.php/OSPF 2011-12-19T13:19:26Z

<p>Aleksey: Створена сторінка: '''OSPF''' (Open Shortest Path First) - протокол динамічної маршрутизації, заснований на технології відст...</p> <hr /> <div>'''OSPF''' (Open Shortest Path First) - протокол динамічної маршрутизації, заснований на технології відстеження стану каналу (про стан каналу технологій) і використовує для знаходження найкоротшого шляху [[алгоритм Дейкстри]].<br /> <br /> Протокол OSPF був розроблений IETF в 1988 році. Остання версія протоколу представлена ​​в RFC 2328. Протокол OSPF являє собою протокол внутрішнього шлюзу (Interior Gateway Protocol - IGP). Протокол OSPF поширює інформацію про доступні маршрути між маршрутизаторами однієї автономної системи.<br /> <br /> OSPF пропонує вирішення наступних завдань:<br /> * Збільшення швидкості збіжності (у порівнянні з протоколом RIP2, так як немає необхідності вичікування багаторазових тайм-аутів по 30с);<br /> * Підтримка мережевих масок змінної довжини (VLSM);<br /> * Досяжність мережі (швидко виявляються маршрутизатори, що відмовили і топологія мережі змінюється відповідним чином);<br /> * Оптимальне використання пропускної спроможності (так як будується мінімальний остовний граф за алгоритмом Дейкстри);<br /> * Метод вибору шляху.<br /> <br /> == Опис роботи протоколу ==<br /> <br /> * Маршрутизатори обмінюються hello-пакетами через всі інтерфейси, на яких активований OSPF. Маршрутизатори, що розділяють загальний канал передачі даних, стають сусідами, коли вони приходять до домовленості про певні параметри, зазначених в їх hello-пакетах.<br /> <br /> * На наступному етапі роботи протоколу маршрутизатори будуть намагатися перейти в стан суміжності з маршрутизаторами, які перебувають з ними у межах прямого зв'язку (на відстані одного хопу). Перехід у стан суміжності визначається типом маршрутизаторів, які обмінюються hello-пакетами, і типом мережі, по якій передаються hello-пакети. OSPF визначає кілька типів мереж і кілька типів маршрутизаторів. Пара маршрутизаторів, що знаходяться в стані суміжності, синхронізує між собою базу даних стану каналів.<br /> <br /> * Кожен маршрутизатор посилає оголошення про стан каналу маршрутизаторам, з якими він знаходиться в стані суміжності.<br /> <br /> * Кожен маршрутизатор, який отримав оголошення від суміжного маршрутизатора, записує передану в ньому інформацію в базу даних стану каналів маршрутизатора і розсилає копію оголошення всім іншим суміжним з ним маршрутизаторам.<br /> <br /> * Розсилаючи оголошення через зону, всі маршрутизатори будують ідентичну базу даних стану каналів маршрутизатора.<br /> <br /> * Коли база даних побудована, кожен маршрутизатор використовує [[алгоритм Дейкстри]] для обчислення графа без петель, який буде описувати найкоротший шлях до кожного відомого пункту призначення з собою в якості кореня. Цей граф - дерево найкоротших шляхів.<br /> <br /> * Кожен маршрутизатор будує таблицю маршрутизації зі свого дерева найкоротших шляхів.<br /> <br /> == Типи мереж, підтримувані протоколом OSPF ==<br /> <br /> * Широкомовні мережі з множинним доступом ([[Ethernet]], [[Token Ring]])<br /> * Точка-точка (T1, E1, комутований доступ)<br /> * Мережі з множинним доступом (NBMA) (Frame relay)<br /> * Віртуальні канали (virtual links)<br /> <br /> == Типи оголошень про стан каналу (LSA) ==<br /> <br /> '''Type 1 LSA - Router LSA''' - оголошення про стан каналів маршрутизатора. Ці LSA поширюються всіма маршрутизаторами. У LSA міститься опис усіх каналів маршрутизатора і вартість (cost) кожного каналу. Поширюються тільки в межах однієї зони.<br /> <br /> '''Type 2 LSA - Network LSA''' - оголошення про стан каналів мережі. Поширюється DR в мережах з множинним доступом. У LSA міститься опис всіх маршрутизаторів приєднаних до мережі, включаючи DR. Поширюються тільки в межах однієї зони.<br /> <br /> '''Type 3 LSA - Network Summary LSA''' - сумарне оголошення про стан каналів мережі. Оголошення поширюється прикордонними маршрутизаторами. Оголошення описує тільки маршрути до мереж поза зоною і не описує маршрути усередині автономної системи. Прикордонний маршрутизатор відправляє окреме оголошення для кожної відомої йому мережі.<br /> <br /> Коли маршрутизатор отримує Network Summary LSA від прикордонного маршрутизатора він не запускає алгоритм обчислення найкоротшого шляху. Маршрутизатор просто додає до вартості маршруту, вказаного в LSA вартість маршруту до прикордонного маршрутизатора. Потім маршрут до мережі через прикордонний маршрутизатор поміщається в таблицю маршрутизації.<br /> <br /> '''Type 4 LSA - ASBR Summary LSA''' - сумарне оголошення про стан каналів прикордонного маршрутизатора автономної системи. Оголошення поширюється прикордонними маршрутизаторами. ASBR Summary LSA відрізняється від Network Summary LSA тим, що поширюється інформація не про мережу, а про прикордонний маршрутизаторі автономної системи.<br /> <br /> '''Type 5 LSA - AS External LSA''' - оголошення про стан зовнішніх каналів автономної системи. Оголошення поширюється прикордонним маршрутизатором автономної системи в межах всієї автономної системи. Оголошення описує маршрути зовнішні для автономної системи OSPF або маршрути за замовчуванням (default route) зовнішні для автономної системи OSPF.<br /> <br /> '''Type 6 LSA - Multicast OSPF LSA''' - спеціалізований LSA, який використовують мультікаст OSPF додатки (Not implemented by CISCO).<br /> <br /> '''Type 7 LSA - AS External LSA for NSSA''' - оголошення про стан зовнішніх каналів автономної системи в NSSA зоні. Це оголошення може передаватися тільки в NSSA зоні. На кордоні зони прикордонний маршрутизатор перетворює type 7 LSA в type 5 LSA.<br /> <br /> '''Type 8 LSA - Link LSA''' - анонсує link-local адреса і префікс (и) маршрутизатора всім маршрутизаторам розділяє канал (link). Відправляється тільки якщо на каналі присутні більше ніж один маршрутизатор. Поширюються лише в межах каналу (link).<br /> <br /> == Формат заголовка OSPF-пакета ==<br /> <br /> OSPF-пакет інкапсулюється безпосередньо в полі даних IP-пакета. Значення поля «протокол верхнього рівня» в заголовку IP-дейтаграми для OSPF дорівнює 89.<br /> 0 1 2 3<br /> 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7<br /> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br /> | version | type | packet length |<br /> +---------------+---------------+-------------------------------+<br /> | router ID |<br /> +---------------------------------------------------------------+<br /> | area ID |<br /> +-------------------------------+-------------------------------+<br /> | checksum | authentication type |<br /> +-------------------------------+-------------------------------+<br /> | authentication |<br /> +---------------------------------------------------------------+<br /> | authentication |<br /> +---------------------------------------------------------------+<br /> <br /> * Version - номер версії протоколу OSPF. Поточна версія OSPF для мереж IPv4 - 2.<br /> * Type - тип OSPF-пакета. В RFC 2328 описано 5 типів пакетів.<br /> * Packet length - довжина пакету, включаючи заголовок.<br /> * Router ID - ідентифікатор маршрутизатора - унікальне 32-хбітное число, ідентифікує<br /> маршрутизатор в межах автономної системи.<br /> * Area ID - 32-хбітний ідентифікатор зони.<br /> * Checksum - поле контрольної суми. Підраховується для всього пакету, включаючи заголовок.<br /> * Authentication type - тип використовуваної схеми [[аутентифікація | аутентифікації]]. Можливі значення:<br /> ** 0 - аутентифікація не використовується<br /> ** 1 - аутентифікація відкритим текстом<br /> ** 2 - MD5-аутентифікація<br /> * Authentication - поле даних аутентифікації.<br /> <br /> == Формат Hello-пакета ==<br /> <br /> 0 1 2 3<br /> 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7<br /> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br /> | version | type | packet length |<br /> +---------------+---------------+-------------------------------+<br /> | router ID |<br /> +---------------------------------------------------------------+<br /> | area ID |<br /> +-------------------------------+-------------------------------+<br /> | checksum | authentication type |<br /> +-------------------------------+-------------------------------+<br /> | authentication |<br /> +---------------------------------------------------------------+<br /> | authentication |<br /> +---------------------------------------------------------------+<br /> | network mask |<br /> +-------------------------------+---------------+---------------+<br /> | hello interval | options |router priority|<br /> +-------------------------------+---------------+---------------+<br /> | router dead interval |<br /> +---------------------------------------------------------------+<br /> | designated router |<br /> +---------------------------------------------------------------+<br /> | backup designated router |<br /> +---------------------------------------------------------------+<br /> | neighbor ID |<br /> +---------------------------------------------------------------+<br /> | neighbor ID |<br /> +---------------------------------------------------------------+<br /> | ... |<br /> <br /> Нижче наведено короткий опис полів hello-пакета.<br /> <br /> * Network mask - мережева маска інтерфейсу, через який відправляється hello-пакет.<br /> * Hello interval - hello-інтервал задає частоту розсилки вітальних повідомлень для виявлення сусідів в автономній системі. Для [[Локальна обчислювальна мережа | LAN]] значення за замовчуванням дорівнює 10 секундам.<br /> * Options - 8-бітове поле опцій. Описує можливості маршрутизатора.<br /> * Router priority - пріоритет маршрутизатора - 8-бітове число, яке символізує пріоритет маршрутизатора при виборі DR і BDR.<br /> * Router dead interval - період часу, протягом якого маршрутизатор очікує відповіді сусідів.<br /> * Designated router (DR) - IP-адреса DR.<br /> * Backup designated router (BDR) - IP-адреса BDR.<br /> * Neighbor ID - ідентифікатор сусіда. Список складається з ідентифікаторів сусідів, від яких маршрутизатор отримав hello-пакети протягом часу, заданого в поле router dead interval.<br /> <br /> ==Переваги та недоліки OSPF==<br /> <br /> ===Переваги OSPF===<br /> <br /> *Для кожної адреси може бути кілька маршрутних таблиць, по одній на кожен вид IP-операції (TOS).<br /> <br /> *Кожному інтерфейсу привласнюється безрозмірна ціна, що враховує пропускну здатність, час транспортування повідомлення. Для кожної IP-операції може бути привласнена своя ціна (коефіцієнт якості).<br /> <br /> *При існуванні еквівалентних маршрутів OSFP розподіляє потік рівномірно по цих маршрутах.<br /> <br /> *Підтримується адресація субмереж (різні маски для різних маршрутів).<br /> <br /> *При зв'язку точка-точка не потрібно IP-адресу для кожного з кінців. (Економія адрес!)<br /> <br /> Застосування мультикастингу замість широкомовних повідомлень знижує завантаження не залучених сегментів.<br /> <br /> ===Недоліки===<br /> <br /> *Важко отримати інформацію про перевагу каналів для вузлів, що підтримують інші протоколи, або зі статичною маршрутизацією.<br /> <br /> *OSPF є лише внутрішнім протоколом.</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D0%B8_%D0%BE%D0%B1%D0%BC%D1%96%D0%BD%D1%83_%D0%BC%D0%B0%D1%80%D1%88%D1%80%D1%83%D1%82%D0%BD%D0%BE%D1%8E_%D1%96%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D1%96%D1%94%D1%8E 2011-12-19T12:06:13Z

<p>Aleksey: </p> <hr /> <div>'''Протокол маршрутизації''' - такий протокол, який підтримує маршрутизовані протоколи і надає механізми обміну маршрутною інформацією. Повідомлення протоколу маршрутизації передаються між маршрутизаторами (роутерами). Протокол маршрутизації дозволяє роутерам обмінюватись інформацією між собою для оновлення записів і підтримки таблиці маршрутизації.<br /> Приклади протоколів маршрутизації: [[RIP]], IGRP, EIGRP, OSPF. Легше зрозуміти, що таке протоколи маршрутизації, якщо пам'ятати, що це протоколи обміну маршрутною інформацією.<br /> <br /> == ''[[RIP]]'' ==<br /> <br /> '''''Routing Information Protocol, [[RIP]]'''''— один із найбільшь розповсюджених протоколів маршрутизації в невеликих компютерних мережах, який дозворляє маршрутизаторам динамічно оновлювати маршрутну інформацію, отримуючи її від сусідніх маршрутизаторів.<br /> <br /> <br /> == ''IGP'' ==<br /> <br /> Протокол IGRP (англ. Interior Gateway Routing Protocol) — протокол маршрутизации, разработанный фирмой Cisco, для своих многопротокольных маршрутизаторов в середине 80-х годов для маршрутизации в пределах автономной системы (AS), имеющей сложную топологию и разные характеристики полосы пропускания и задержки. IGRP является протоколом внутренних роутеров (IGP) с вектором расстояния.<br /> <br /> Для выбора маршрута в IGRP используется комбинация показателей, таких как задержка сети, полоса пропускания, надежность и загруженность сети. Весовой коэффициент этих показателей может выбираться автоматически или задаваться администратором сети. Для надежности и загруженности сети это значения от 1 до 255, полоса пропускания — от 1200 бит/сек до 10 Гбит/сек, задержка может принимать значение до 24-го порядка.<br /> <br /> Для повышения стабильности работы IGRP предусматривает такие механизмы, как удержание изменений, разделенный горизонт (split-horizon) и корректировка отмены.<br /> <br /> Удержание изменений Когда в сеть поступает информация об изменениях маршрутов (например, об обрыве связи) от одного из роутеров, то изменения в таблицы маршрутизации поступают не мгновенно, а в течение некоторого времени. В этот период роутер, ещё не получивший информацию об изменениях, может продолжать распространять информацию об уже несуществующем маршруте. При этом возможна ситуация, когда устройство, уже внёсшее изменения в свою таблицу маршрутизации, после получения этих данных внесёт повторную корректировку в таблицу. Временное удержание изменений — это механизм, по которому удерживаются все изменения, которые могут повлиять на маршруты в течение некоторого времени. Время удержания должно быть больше времени, необходимого для того, чтобы информация об измененных маршрутах распространилась по всем роутерам системы.<br /> <br /> Разделенный горизонт (split-horizon) Суть этого механизма состоит в том, для предотвращения зацикливания маршрутов между соседними роутерами, информация об изменении маршрута не должна распространяться в направлении того роутера, от которого она пришла.<br /> <br /> Корректировка отмены маршрута (route-poisoning) — это принудительное удаление маршрута и перевод в состояние удержания, применяется для борьбы с маршрутными петлями.<br /> <br /> Таймеры Таймер корректировки определяет, как часто должны отправляться сообщения о корректировке маршрутов. Таймер недействующих маршрутов определяет, сколько времени должен ожидать роутер при отсутствии сообщений о корректировке какого-нибудь конкретного маршрута, прежде чем объявить этот маршрут недействующим. Время по умолчанию IGRP для этой переменной в три раза превышает период корректировки. Переменная величина времени удерживания определяет промежуток времени удерживания. Время по умолчанию IGRP для этой переменной в три раза больше периода таймера корректировки, плюс 10 сек. И наконец, таймер отключения указывает, сколько времени должно пройти прежде, чем какой-нибудь роутер должен быть исключен из маршрутной таблицы. Время по умолчанию IGRP для этой величины в семь раз превышает период корректировки маршрутизации.<br /> <br /> == ''EIGRP'' ==<br /> <br /> '''''Enhanced Interior Gateway Routing Protocol - (EIGRP)''''' - це пропрієтарний протокол маршрутизації, що базується на старому протоколі IGRP. EIGRP - дистанційно-векторний протокол маршрутизації, що був оптимізований для зменшення нестабільності протоколу після змін топології мережі, уникнення проблеми зациклення маршруту та більш ефективного і економного використання потужностей маршрутизатора. Роутери, що підтримують протокол EIGRP також підтримують і IGRP та перетворюють маршрутну інформацію для IGRP-сусідів з 32-бітної метрики EIGRP у 24-бітну метрику стандарту IGRP. Алгоритм визначення маршруту базується на алгоритмі Дейкстри пошуку в глибину на графі. EIGRP обчислює і враховує 5 параметрів для кожної ділянки маршруту між вузлами мережі:<br /> <br /> * Total Delay - Загальна затримка передачі (з точністю до мікросекунди)<br /> * Minimum Bandwidth - Мінімальна пропускна спроможність (в Кб/с - кілобіт/секунду)<br /> * Reliability - Надійнсть (оцінка від 1 до 255; 255 найбільш надійно)<br /> * Load - Завантаження (оцінка від 1 до 255; 255 найбільш завантажено)<br /> * Maximum Transmission Unit (MTU) (не враховується при обчисленні оптимального маршруту, береться до уваги окремо) - максимальний розмір блоку, що можливо передати по ділянці маршруту.<br /> <br /> Формула обчислення оцінки ділянки:<br /> <br /> [[Файл:EIGRP.JPG]]<br /> <br /> де (K1-K5) - змінні, що визначаються вручну користувачем для зміни приорітетів обчислення оцінок. За замовчанням всі змінні дорівнюють 1.<br /> <br /> EIGRP обчислює пропускну спроможність і затримку наступним чином:<br /> <br /> Bandwidth = 107 / Interface Bandwidth (пропускна спроможність інтерфейсу)<br /> Delay = Interface Delay(затримка інтерфейсу) / 10<br /> <br /> На маршрутизаторах Cisco Interface Bandwidth (пропускна спроможність інтерфейсу) є налаштованим параметром, що задається користувачем. Аналогічно Interface Delay (затримка інтерфейсу) є конфігурованим статичним параметром. EIGRP також обчислює кількість вузлів (хопів - hop) для кожного маршруту, проте не використовує це в обчисленні маршруту. Це лише перевіряється з вбудованим максимумом на маршрутизаторі EIGRP (за замовчанням це встановлюється на 100 і може бути змінено на будь-яке значення між 1 і 255). Якщо число хопів для певного вузла вище, ніж максимум, вузол вважатиметься як недосяжний маршрутизатором.<br /> <br /> <br /> == ''[[OSPF]]'' ==<br /> <br /> '''''[[OSPF]] (англ. Open Shortest Path First)''''' — протокол динамічної маршрутизації, заснований на технології відстеження стану каналу (link-state technology), що використовує для знаходження найкоротшого шляху Алгоритм Дейкстри (Dijkstra's algorithm).<br /> <br /> Протокол [[OSPF]] був розроблений IETF в 1988 році. Остання версія протоколу представлена в RFC 2328. Протокол [[OSPF]] являє собою протокол внутрішнього шлюзу (Interior Gateway Protocol - IGP). Протокол OSPF поширює інформацію про доступні маршрутах між маршрутизаторами однієї автономної системи.<br /> <br /> [[OSPF]] пропонує рішення наступних завдань:<br /> <br /> * Збільшення швидкості збіжності;<br /> * Підтримка мережних масок змінної довжини (VLSM);<br /> * Досяжності мережі;<br /> * Використання пропускної здатності;<br /> * Метод вибору шляху.<br /> <br /> <br /> <br /> <br /> <br /> == ''Протоколи обміну маршрутною інформацією стека [[TCP/IP]]'' ==<br /> <br /> Всі протоколи обміну маршрутною інформацією стека Tcp/ip відносяться до класу адаптивних протоколів, які у свою чергу діляться на дві групи, кожна з яких пов'язана з одним з наступних типів алгоритмів:<br /> <br /> * дистанційно-векторний алгоритм (Distance Vector Algorithms, DVA); ГП алгоритм стану зв'язків (Link State Algorithms, LSA).<br /> * дистанційно-векторних алгоритмах кожен маршрутизатор періодично і широкомовно розсилає по мережі вектор відстаней від себе до всіх відомих йому мереж. Під відстанню зазвичай розуміється число промежу точних маршрутизаторів, через які пакет повинен пройти перш, ніж потрапить у відповідну мережу. Може використовуватися і інша метрика, що враховує не тільки число перевалочних пунктів, але і час проходження пакетів по зв'язку між сусідніми маршрутизаторами. Отримавши вектор від сусіднього маршрутизатора, кожен маршрутизатор додає до нього інформацію про відомих йому інших мережах, про які він дізнався безпосередньо (якщо вони підключені до його портів) або з аналогічних оголошень інших маршрутизаторів, а потім знову розсилає нове значення вектора по мережі. Врешті-решт, кожен маршрутизатор дізнається інформацію про наявні в інтермережі мережі і про відстань до них через сусідні маршрутизатори.<br /> <br /> Дистанційно-векторні алгоритми добре працюють тільки в невеликих мережах. У великих мережах вони засмічують лінії зв'язку інтенсивним широкомовним трафіком, до того ж зміни конфігурації можуть відпрацьовуватися по цьому алгоритму не завжди коректно, оскільки маршрутизатори не мають точного уявлення про топологію зв'язків в мережі, а мають в своєму розпорядженні тільки узагальнену інформацію - вектор дистанцій, до того ж отриманою через посередників. Робота маршрутизатора відповідно до дистанційно-векторного протоколу нагадує роботу моста, оскільки точної топологічної картини мережі такий маршрутизатор не має.<br /> <br /> Найбільш поширеним протоколом, заснованим на дистанційно-векторному алгоритмі, є протокол RIP.<br /> <br /> Алгоритми стану зв'язків забезпечують кожен маршрутизатор інформацією, достатньою для побудови точного графа зв'язків мережі. Всі маршрутизатори працюють на підставі однакових графів, що робить процес маршрутизації стійкішим до змін конфігурації. Широкомовна розсилка використовується тут тільки при змінах стану зв'язків, що відбувається в надійних мережах не так часто.<br /> <br /> Для того, щоб зрозуміти, в якому стані знаходяться лінії зв'язки, підключені до його портів, маршрутизатор періодично обмінюється короткими пакетами зі своїми найближчими сусідами. Цей трафік також широкомовний, але він циркулює тільки між сусідами і тому не так засмічує мережу.<br /> <br /> Протоколом, заснованим на алгоритмі стану зв'язків, в стеку [[TCP/IP]] є протокол OSPF.</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D0%B8_%D0%BE%D0%B1%D0%BC%D1%96%D0%BD%D1%83_%D0%BC%D0%B0%D1%80%D1%88%D1%80%D1%83%D1%82%D0%BD%D0%BE%D1%8E_%D1%96%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D1%96%D1%94%D1%8E 2011-12-19T12:02:07Z

<p>Aleksey: </p> <hr /> <div>'''Протокол маршрутизації''' - такий протокол, який підтримує маршрутизовані протоколи і надає механізми обміну маршрутною інформацією. Повідомлення протоколу маршрутизації передаються між маршрутизаторами (роутерами). Протокол маршрутизації дозволяє роутерам обмінюватись інформацією між собою для оновлення записів і підтримки таблиці маршрутизації.<br /> Приклади протоколів маршрутизації: [[RIP]], IGRP, EIGRP, OSPF. Легше зрозуміти, що таке протоколи маршрутизації, якщо пам'ятати, що це протоколи обміну маршрутною інформацією.<br /> <br /> == ''[[RIP]]'' ==<br /> <br /> '''''Routing Information Protocol, [[RIP]]'''''— один із найбільшь розповсюджених протоколів маршрутизації в невеликих компютерних мережах, який дозворляє маршрутизаторам динамічно оновлювати маршрутну інформацію, отримуючи її від сусідніх маршрутизаторів.<br /> <br /> <br /> == ''IGP'' ==<br /> <br /> Протокол IGRP (англ. Interior Gateway Routing Protocol) — протокол маршрутизации, разработанный фирмой Cisco, для своих многопротокольных маршрутизаторов в середине 80-х годов для маршрутизации в пределах автономной системы (AS), имеющей сложную топологию и разные характеристики полосы пропускания и задержки. IGRP является протоколом внутренних роутеров (IGP) с вектором расстояния.<br /> <br /> Для выбора маршрута в IGRP используется комбинация показателей, таких как задержка сети, полоса пропускания, надежность и загруженность сети. Весовой коэффициент этих показателей может выбираться автоматически или задаваться администратором сети. Для надежности и загруженности сети это значения от 1 до 255, полоса пропускания — от 1200 бит/сек до 10 Гбит/сек, задержка может принимать значение до 24-го порядка.<br /> <br /> Для повышения стабильности работы IGRP предусматривает такие механизмы, как удержание изменений, разделенный горизонт (split-horizon) и корректировка отмены.<br /> <br /> Удержание изменений Когда в сеть поступает информация об изменениях маршрутов (например, об обрыве связи) от одного из роутеров, то изменения в таблицы маршрутизации поступают не мгновенно, а в течение некоторого времени. В этот период роутер, ещё не получивший информацию об изменениях, может продолжать распространять информацию об уже несуществующем маршруте. При этом возможна ситуация, когда устройство, уже внёсшее изменения в свою таблицу маршрутизации, после получения этих данных внесёт повторную корректировку в таблицу. Временное удержание изменений — это механизм, по которому удерживаются все изменения, которые могут повлиять на маршруты в течение некоторого времени. Время удержания должно быть больше времени, необходимого для того, чтобы информация об измененных маршрутах распространилась по всем роутерам системы.<br /> <br /> Разделенный горизонт (split-horizon) Суть этого механизма состоит в том, для предотвращения зацикливания маршрутов между соседними роутерами, информация об изменении маршрута не должна распространяться в направлении того роутера, от которого она пришла.<br /> <br /> Корректировка отмены маршрута (route-poisoning) — это принудительное удаление маршрута и перевод в состояние удержания, применяется для борьбы с маршрутными петлями.<br /> <br /> Таймеры Таймер корректировки определяет, как часто должны отправляться сообщения о корректировке маршрутов. Таймер недействующих маршрутов определяет, сколько времени должен ожидать роутер при отсутствии сообщений о корректировке какого-нибудь конкретного маршрута, прежде чем объявить этот маршрут недействующим. Время по умолчанию IGRP для этой переменной в три раза превышает период корректировки. Переменная величина времени удерживания определяет промежуток времени удерживания. Время по умолчанию IGRP для этой переменной в три раза больше периода таймера корректировки, плюс 10 сек. И наконец, таймер отключения указывает, сколько времени должно пройти прежде, чем какой-нибудь роутер должен быть исключен из маршрутной таблицы. Время по умолчанию IGRP для этой величины в семь раз превышает период корректировки маршрутизации.<br /> <br /> == ''EIGRP'' ==<br /> <br /> '''''Enhanced Interior Gateway Routing Protocol - (EIGRP)''''' - це пропрієтарний протокол маршрутизації, що базується на старому протоколі IGRP. EIGRP - дистанційно-векторний протокол маршрутизації, що був оптимізований для зменшення нестабільності протоколу після змін топології мережі, уникнення проблеми зациклення маршруту та більш ефективного і економного використання потужностей маршрутизатора. Роутери, що підтримують протокол EIGRP також підтримують і IGRP та перетворюють маршрутну інформацію для IGRP-сусідів з 32-бітної метрики EIGRP у 24-бітну метрику стандарту IGRP. Алгоритм визначення маршруту базується на алгоритмі Дейкстри пошуку в глибину на графі. EIGRP обчислює і враховує 5 параметрів для кожної ділянки маршруту між вузлами мережі:<br /> <br /> * Total Delay - Загальна затримка передачі (з точністю до мікросекунди)<br /> * Minimum Bandwidth - Мінімальна пропускна спроможність (в Кб/с - кілобіт/секунду)<br /> * Reliability - Надійнсть (оцінка від 1 до 255; 255 найбільш надійно)<br /> * Load - Завантаження (оцінка від 1 до 255; 255 найбільш завантажено)<br /> * Maximum Transmission Unit (MTU) (не враховується при обчисленні оптимального маршруту, береться до уваги окремо) - максимальний розмір блоку, що можливо передати по ділянці маршруту.<br /> <br /> Формула обчислення оцінки ділянки:<br /> <br /> [[Файл:EIGRP.JPG]]<br /> <br /> де (K1-K5) - змінні, що визначаються вручну користувачем для зміни приорітетів обчислення оцінок. За замовчанням всі змінні дорівнюють 1.<br /> <br /> EIGRP обчислює пропускну спроможність і затримку наступним чином:<br /> <br /> Bandwidth = 107 / Interface Bandwidth (пропускна спроможність інтерфейсу)<br /> Delay = Interface Delay(затримка інтерфейсу) / 10<br /> <br /> На маршрутизаторах Cisco Interface Bandwidth (пропускна спроможність інтерфейсу) є налаштованим параметром, що задається користувачем. Аналогічно Interface Delay (затримка інтерфейсу) є конфігурованим статичним параметром. EIGRP також обчислює кількість вузлів (хопів - hop) для кожного маршруту, проте не використовує це в обчисленні маршруту. Це лише перевіряється з вбудованим максимумом на маршрутизаторі EIGRP (за замовчанням це встановлюється на 100 і може бути змінено на будь-яке значення між 1 і 255). Якщо число хопів для певного вузла вище, ніж максимум, вузол вважатиметься як недосяжний маршрутизатором.<br /> <br /> <br /> == ''OSPF'' ==<br /> <br /> '''''OSPF (англ. Open Shortest Path First)''''' — протокол динамічної маршрутизації, заснований на технології відстеження стану каналу (link-state technology), що використовує для знаходження найкоротшого шляху Алгоритм Дейкстри (Dijkstra's algorithm).<br /> <br /> Протокол OSPF був розроблений IETF в 1988 році. Остання версія протоколу представлена в RFC 2328. Протокол OSPF являє собою протокол внутрішнього шлюзу (Interior Gateway Protocol - IGP). Протокол OSPF поширює інформацію про доступні маршрутах між маршрутизаторами однієї автономної системи.<br /> <br /> OSPF пропонує рішення наступних завдань:<br /> <br /> * Збільшення швидкості збіжності;<br /> * Підтримка мережних масок змінної довжини (VLSM);<br /> * Досяжності мережі;<br /> * Використання пропускної здатності;<br /> * Метод вибору шляху.<br /> <br /> <br /> <br /> <br /> <br /> == ''Протоколи обміну маршрутною інформацією стека [[TCP/IP]]'' ==<br /> <br /> Всі протоколи обміну маршрутною інформацією стека Tcp/ip відносяться до класу адаптивних протоколів, які у свою чергу діляться на дві групи, кожна з яких пов'язана з одним з наступних типів алгоритмів:<br /> <br /> * дистанційно-векторний алгоритм (Distance Vector Algorithms, DVA); ГП алгоритм стану зв'язків (Link State Algorithms, LSA).<br /> * дистанційно-векторних алгоритмах кожен маршрутизатор періодично і широкомовно розсилає по мережі вектор відстаней від себе до всіх відомих йому мереж. Під відстанню зазвичай розуміється число промежу точних маршрутизаторів, через які пакет повинен пройти перш, ніж потрапить у відповідну мережу. Може використовуватися і інша метрика, що враховує не тільки число перевалочних пунктів, але і час проходження пакетів по зв'язку між сусідніми маршрутизаторами. Отримавши вектор від сусіднього маршрутизатора, кожен маршрутизатор додає до нього інформацію про відомих йому інших мережах, про які він дізнався безпосередньо (якщо вони підключені до його портів) або з аналогічних оголошень інших маршрутизаторів, а потім знову розсилає нове значення вектора по мережі. Врешті-решт, кожен маршрутизатор дізнається інформацію про наявні в інтермережі мережі і про відстань до них через сусідні маршрутизатори.<br /> <br /> Дистанційно-векторні алгоритми добре працюють тільки в невеликих мережах. У великих мережах вони засмічують лінії зв'язку інтенсивним широкомовним трафіком, до того ж зміни конфігурації можуть відпрацьовуватися по цьому алгоритму не завжди коректно, оскільки маршрутизатори не мають точного уявлення про топологію зв'язків в мережі, а мають в своєму розпорядженні тільки узагальнену інформацію - вектор дистанцій, до того ж отриманою через посередників. Робота маршрутизатора відповідно до дистанційно-векторного протоколу нагадує роботу моста, оскільки точної топологічної картини мережі такий маршрутизатор не має.<br /> <br /> Найбільш поширеним протоколом, заснованим на дистанційно-векторному алгоритмі, є протокол RIP.<br /> <br /> Алгоритми стану зв'язків забезпечують кожен маршрутизатор інформацією, достатньою для побудови точного графа зв'язків мережі. Всі маршрутизатори працюють на підставі однакових графів, що робить процес маршрутизації стійкішим до змін конфігурації. Широкомовна розсилка використовується тут тільки при змінах стану зв'язків, що відбувається в надійних мережах не так часто.<br /> <br /> Для того, щоб зрозуміти, в якому стані знаходяться лінії зв'язки, підключені до його портів, маршрутизатор періодично обмінюється короткими пакетами зі своїми найближчими сусідами. Цей трафік також широкомовний, але він циркулює тільки між сусідами і тому не так засмічує мережу.<br /> <br /> Протоколом, заснованим на алгоритмі стану зв'язків, в стеку [[TCP/IP]] є протокол OSPF.</div>

Aleksey https://wiki.cusu.edu.ua/index.php/RIP 2011-12-19T12:01:36Z

<p>Aleksey: </p> <hr /> <div>==Загальні відомості==<br /> <br /> Протокол RIP (Routing Information Protocol) є внутрішнім протоколом маршрутизації дистанційно-векторного типу, він являє собою один з найбільш ранніх протоколів обміну маршрутною інформацією і досі надзвичайно поширений в обчислювальних мережах зважаючи на простоту реалізації. Окрім версії RIP для мереж [[TCP/IP]] існує також версія RIP для мереж [[IPX/SPX]] компанії Novell.<br /> <br /> Для IP є дві версії протоколу RIP: перша і друга. Протокол RIPvl не підтримує масок, тобто він поширює між маршрутизаторами тільки інформацію про номери мереж і відстанях до них, а інформацію про маски цих мереж не поширює, вважаючи, що всі адреси належать до стандартних класів А, В або С. Протокол RIPv2 передає інформацію про маски мереж, тому він більшою мірою відповідає вимогам сьогодення. Так як при побудові таблиць маршрутизації робота версії 2 принципово не відрізняється від версії 1, то в подальшому для спрощення записів буде описуватися робота першої версії.<br /> <br /> == Формат RIP пакету ==<br /> <br /> 0 1 2 3 <br /> 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7<br /> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br /> | command (1) | version (1) | must be zero (2) |<br /> +---------------+---------------+-------------------------------+<br /> | |<br /> ~ RIP Entry (20) ~<br /> | |<br /> +---------------+---------------+---------------+---------------+<br /> <br /> command — Команда, визначає призначення датаграми (1 — request; 2 — response)<br /> <br /> version — Номер версії, залежно від версії, визначається формат пакета<br /> <br /> must be zero — повинно бути нулем;<br /> <br /> RIP Entry — (RTE) Запис маршрутної інформації RIP. RIP пакет може містити від 1 до 25 записів RIP Entry.<br /> <br /> === Формат RIP Entry для протоколу RIP-1 (version = 1) ===<br /> <br /> 0 1 2 3 <br /> 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7<br /> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br /> | address family identifier (2) | must be zero (2) |<br /> +-------------------------------+-------------------------------+<br /> | IPv4 address (4) |<br /> +---------------------------------------------------------------+<br /> | must be zero (4) |<br /> +---------------------------------------------------------------+<br /> | must be zero (4) |<br /> +---------------------------------------------------------------+<br /> | metric (4) |<br /> +---------------------------------------------------------------+<br /> <br /> address family identifier — (AFI) Тип адреси, звичайно підтримується тільки запис AF_INET, яке дорівнює 2 (тобто використовується для протоколу IP)<br /> <br /> must be zero — повинно бути нулем<br /> <br /> IPv4 address — IP адреса місця призначення (хост або мережа)<br /> <br /> metric — Метрика маршруту<br /> <br /> === Формат RIP Entry для протоколу RIP-2 (version = 2) ===<br /> <br /> 0 1 2 3 <br /> 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7<br /> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br /> | Address Family Identifier (2) | Route Tag (2) |<br /> +-------------------------------+-------------------------------+<br /> | IP Address (4) |<br /> +---------------------------------------------------------------+<br /> | Subnet Mask (4) |<br /> +---------------------------------------------------------------+<br /> | Next Hop (4) |<br /> +---------------------------------------------------------------+<br /> | Metric (4) |<br /> +---------------------------------------------------------------+<br /> <br /> Address Family Identifier — (AFI) Тип адреси, звичайно підтримується тільки запис AF_INET, яке дорівнює 2 (тобто використовується для протоколу IP)<br /> <br /> Route Tag — (RT) Тег маршруту. Призначений для поділу «внутрішніх» маршрутів від «зовнішніх», взяті наприклад з іншого IGP або EGP<br /> <br /> IP Address — IP адреса місця призначення<br /> <br /> Subnet Mask — Маска підмережі<br /> <br /> Next Hop — Наступний хоп. Містить IP адреса маршрутизатора до місця призначення. Значення 0.0.0.0 — хопом до місця призначення є відправник пакета. Незамінне, якщо протокол RIP не може бути запущений на всіх маршрутизаторах!<br /> <br /> Metric — Метрика маршруту<br /> <br /> ==Побудова таблиці маршрутизації==<br /> <br /> В якості відстані до мережі стандарти протоколу RIP допускають різні види метрик: хопи, метрики, що враховують пропускну здатність, затримки і надійність мереж (тобто відповідні ознаками D, Т і R в поле «Якість сервісу» IP-пакета), а також будь-які комбінації цих метрик. Метрика повинна мати властивість адитивності - метрика складового шляху повинна дорівнювати сумі метрик складових цього шляху. У більшості реалізації RIP використовується найпростіша метрика - кількість хопов, тобто кількість проміжних маршрутизаторів, які потрібно подолати пакету до мережі призначення.<br /> <br /> Розглянемо процес побудови таблиці маршрутизації за допомогою протоколу RIP на прикладі складеної мережі, зображеної на мал.1.<br /> <br /> [[Файл: Rip1.jpg]]<br /> <br /> Мал. 1. Мережа побудована на маршрутизаторах RIP.<br /> <br /> '''Етап 1 - створення мінімальних таблиць'''. У цій мережі є вісім IP-мереж, пов'язаних чотирма маршрутизаторами з ідентифікаторами: Ml, М2, МЗ і М4. Маршрутизатори, що працюють по протоколу RIP, можуть мати ідентифікатори, проте для роботи протоколу вони не є необхідними. У RIP-повідомленнях ці ідентифікатори не передаються.<br /> <br /> У вихідному стані в кожному маршрутизаторі програмним забезпеченням стека [[TCP/IP]] автоматично створюється мінімальна таблиця маршрутизації, в якій враховуються тільки безпосередньо приєднані мережі. На малюнку адреси портів маршрутизаторів на відміну від адрес мереж поміщені в овали.<br /> <br /> Таблиця 1 дозволяє оцінити приблизний вигляд мінімальної таблиці маршрутизації маршрутизатора Ml.<br /> <br /> '''Таблиця 1'''. Мінімальна таблиця маршрутизації маршрутизатора Ml<br /> <br /> [[Файл:Rip2.jpg]]<br /> <br /> Мінімальні таблиці маршрутизації в інших маршрутизаторах будуть виглядати відповідно, наприклад, таблиця маршрутизатора М2 буде складатися з трьох записів (табл. 2).<br /> <br /> '''Таблиця 2'''. Мінімальна таблиця маршрутизації маршрутизатора М2<br /> <br /> [[Файл:Rip3.jpg]]<br /> <br /> '''Етап 2 - розсилка мінімальних таблиць сусідам'''. Після ініціалізації кожного маршрутизатора він починає посилати своїм сусідам повідомлення протоколу RIP, в яких міститься його мінімальна таблиця.<br /> <br /> RIP-повідомлення передаються в пакетах протоколу UDP і включають два параметри для кожної мережі: її IP-адресу та відстань до неї від маршрутизатора, що передає повідомлення.<br /> <br /> Сусідами є ті маршрутизатори, яким даний маршрутизатор безпосередньо може передати IP-пакет з якої-небудь своєї мережі, не користуючись послугами проміжних маршрутизаторів. Наприклад, для маршрутизатора Ml сусідами є маршрутизатори М2 і МЗ, а для маршрутизатора М4 - маршрутизатори М2 і МЗ.<br /> <br /> Таким чином, маршрутизатор Ml передає маршрутизатору М2 і МЗ таке повідомлення:<br /> <br /> *мережа 201.36.14.0, відстань 1;<br /> <br /> *мережа 132.11.0.0, відстань 1;<br /> <br /> *мережа 194.27.18.0, відстань 1.<br /> <br /> '''Етап 3 - отримання RIP-повідомлень від сусідів і обробка отриманої інформації'''.<br /> <br /> Після отримання аналогічних повідомлень від маршрутизаторів М2 і МЗ маршрутизатор Ml нарощує кожне отримане поле метрики на одиницю і запам'ятовує, через який порт і від якого маршрутизатора отримана нова інформація (адреса цього маршрутизатора буде адресою наступного маршрутизатора, якщо цей запис буде внесено в таблицю маршрутизації). Потім маршрутизатор починає порівнювати нову інформацію з тією, яка зберігається в його таблиці маршрутизації (табл. 3).<br /> <br /> '''Таблиця 3'''. Таблиця маршрутизації маршрутизатора M1<br /> <br /> [[Файл:Rip4.jpg]]<br /> <br /> Записи з четвертої по дев'ятий отримані від сусідніх маршрутизаторів, і вони претендують на занесення в таблицю. Однак лише записи з четвертої по сьому потрапляють в таблицю, а записи восьма і дев'ята - ні. Це відбувається тому, що вони містять дані про вже наявні в таблиці Ml мережах, а відстань до них гірша, ніж в існуючих записах.<br /> <br /> Протокол RIP заміщає запис про будь-яку мережу тільки в тому випадку, якщо нова інформація має кращу метрику (відстань в хопах менше), ніж наявна. У результаті в таблиці маршрутизації про кожну мережі залишається тільки один запис, а якщо є декілька рівнозначних щодо відстані шляхів до однієї і тієї ж мережі, то все одно в таблиці залишається один запис, який прийшов в маршрутизатор першим. Для цього правила існує виняток - якщо найгірша інформація про будь-якої мережі прийшла від того ж маршрутизатора, на підставі повідомлення якого був створений цей запис, то найгірша інформація заміщає кращу.<br /> <br /> Аналогічні операції з новою інформацією виконують і інші маршрутизатори мережі.<br /> <br /> '''Етап 4 - розсилка нової, вже не мінімальної, таблиці сусідам'''. Кожен маршрутизатор відсилає нове RIP-повідомлення всім своїм сусідам. У цьому повідомленні він поміщає дані про всі відомі йому мережі - як безпосередньо підключених, так і віддалених, про які маршрутизатор дізнався з RIP-повідомлень.<br /> <br /> '''Етап 5 - отримання RIP-повідомлень від сусідів і обробка отриманої інформації'''. Етап 5 повторює етап 3 - маршрутизатори приймають RIP-повідомлення, обробляють записи що містяться в них і коректують свої таблиці маршрутизації.<br /> <br /> Подивимося, як це робить маршрутизатор Ml (табл. 4).<br /> <br /> '''Таблиця 4'''. Таблиця маршрутизації маршрутизатора M1.<br /> <br /> [[Файл:Rip5.jpg]]<br /> <br /> На цьому етапі маршрутизатор Ml отримав від маршрутизатора М3 інформацію про мережу 132.15.0.0, яку той у свою чергу на попередньому циклі роботи отримав від маршрутизатора М4. Маршрутизатор вже знає про мережу 132.15.0.0, причому стара інформація має кращу метрику, ніж нова, тому нова інформація про цю мережі відкидається.<br /> <br /> Про мережу 202.101.16.0 маршрутизатор Ml дізнається на цьому етапі вперше, причому дані про неї приходять від двох сусідів - від МЗ і М4. Оскільки метрики в цих повідомленнях вказані однакові, то в таблицю потрапляють дані, які прийшли першими. У нашому прикладі вважається, що маршрутизатор М2 випередив маршрутизатор МЗ і першим переслав своє RIP-повідомлення маршрутизатору Ml.<br /> <br /> Якщо маршрутизатори періодично повторюють етапи розсилки та обробки RIP-повідомлень, то за кінцевий час в мережі встановиться коректний режим маршрутизаціі. Під коректним режимом маршрутизації тут розуміється такий стан таблиць маршрутизації, коли всі мережі будуть досяжні з будь-якої мережі за допомогою деякого раціонального маршруту. Пакети будуть доходити до адресатів і не зациклюватися в петлях, подібних до тієї, яка утворюється на мал. 1, маршрутизаторами М1-М2-МЗ-М4.<br /> <br /> Очевидно, якщо в мережі всі маршрутизатори, їх інтерфейси і канали зв'язку, що з'єднують їх постійно працездатні, то оголошення по протоколу RIP можна робити досить рідко, наприклад, один раз на день. Проте в мережах постійно відбуваються зміни - змінюється як працездатність маршрутизаторів і каналів, так і самі маршрутизатори і канали можуть додаватися в існуючу мережу або ж виводитися з її складу.<br /> <br /> Для адаптації до змін у мережі протокол RIP використовує ряд механізмів.<br /> <br /> ==Адаптація RIP-маршрутизаторів до змін стану мережі==<br /> <br /> До нових маршрутів RIP-маршрутизатори пристосовуються просто - вони передають нову інформацію в черговому повідомленні своїм сусідам і поступово ця інформація стає відома всім маршрутизаторам мережі. А ось до негативних змін, пов'язаних з втратою будь-якого маршруту, RIP-маршрутізатори пристосовуються складніше. Це пов'язано з тим, що у форматі повідомлень протоколу RIP немає поля, яке б вказувало на те, що шлях до цієї мережі більше не існує.<br /> <br /> Замість цього використовуються два механізми повідомлення про те, що деякий маршрут більш недійсний:<br /> <br /> *закінчення часу життя маршруту;<br /> <br /> *вказівка ​​спеціальної відстані (нескінченної) до мережі, що стала недоступною.<br /> <br /> Для відпрацювання першого механізму кожен запис таблиці маршрутизації (як і записи таблиці просування моста/комутатора), отримана за протоколом RIP, має час життя (TTL). При надходженні чергового RIP-повідомлення, яке підтверджує справедливість даного запису, таймер TTL встановлюється в початковий стан, а потім з нього кожну секунду віднімається одиниця. Якщо за час тайм-ауту не прийде нове маршрутне повідомлення про цей маршрут, то він позначається як недійсний.<br /> <br /> Час тайм-ауту пов'язаний з періодом розсилки векторів по мережі. У RIP IP період розсилки рівний 30 секундам, а в якості тайм-ауту вибрано шестиразове значення періоду розсилки, тобто 180 секунд. Вибір досить малого часу періоду розсилки пояснюється декількома причинами. Шестиразовий запас часу потрібний для впевненості в тому, що мережа дійсно стала недоступна, а не просто відбулися втрати RIP-повідомлень (а це можливо, оскільки RIP використовує транспортний протокол UDP, який не забезпечує надійної доставки повідомлень).<br /> <br /> Якщо який-небудь маршрутизатор відмовляє і перестає слати своїм сусідам повідомлення про мережі, які можна досягти через нього, то через 180 секунд всі записи, які породив цей маршрутизатор, стануть недійсними у його найближчих сусідів. Після цього процес повториться вже для сусідів найближчих сусідів - вони викреслять подібні записи вже через 360 секунд, тому що перші 180 секунд найближчі сусіди ще передавали повідомлення про ці записи.<br /> <br /> Як видно з пояснення, відомості про недоступні мережі через маршрутизатор, що відмовив поширюються по мережі не дуже швидко, час поширення кратний часу життя запису, а коефіцієнт кратності дорівнює кількості хопов між самими далекими маршрутизаторами мережі. У цьому полягає одна з причин вибору періоду розсилки в 30 секунд.<br /> <br /> Якщо відмовляють не маршрутизатор, а інтерфейс або мережу, що зв'язують його з яким-небудь сусідом, то ситуація зводиться до щойно описаної - знову починає працювати механізм тайм-ауту і маршрути, стали недійсними поступово будуть викреслені з таблиць всіх маршрутизаторів мережі.<br /> <br /> Тайм-аут працює в тих випадках, коли маршрутизатор не може послати сусідам повідомлення про маршрути, що відмовили, тому що або він сам непрацездатний, або непрацездатна лінія зв'язку, по якій можна було б передати повідомлення.<br /> <br /> Коли ж повідомлення послати можна, RIP-маршрутизатори не використовують спеціальної ознаки в повідомленнях, а вказують нескінченну відстань до мережі, причому в протоколі RIP воно вибрано рівним 16 хопам (при іншій метриці необхідно вказати маршрутизатору її значення, що вважається нескінченністю). Отримавши повідомлення, в якому деяка мережу супроводжується відстанню 16 (або 15, що призводить до того ж результату, так як маршрутизатор нарощує отримане значення на 1), маршрутизатор повинен перевірити, надходить ця «погана» інформація про мережу від того ж маршрутизатора, повідомлення якого послужило свого часу підставою для запису про дану мережу в таблиці маршрутизації. Якщо це той же маршрутизатор, то інформація вважається достовірною і маршрут позначається як недоступний.<br /> <br /> Таке невелике значення «нескінченної» відстані викликано тим, що в деяких випадках відмови зв'язків у мережі викликають тривалі періоди некоректної роботи RIP-маршрутизаторів, що виражається в зацикленні пакетів у петлях мережі. І чим менше відстань, що використовується як «нескінченна», тим такі періоди стають коротшими.<br /> <br /> ==Приклад зациклювання пакетів==<br /> <br /> Розглянемо випадок зациклювання пакетів на прикладі мережі, зображеної на рис. 1.<br /> <br /> Нехай маршрутизатор Ml виявив, що його зв'язок з безпосередньо підключеною мережею 201.36.14.0 втрачена (наприклад, з причини відмови інтерфейсу 201.36.14.3). Ml зазначив у своїй таблиці маршрутизації, що мережа 201.36.14.0 недоступна. У гіршому випадку він виявив це відразу ж після відправлення чергових RIP-повідомлень, так що до початку нового циклу його оголошень, в якому він повинен повідомити сусідам, що відстань до мережі 201.36.14.0 стало рівним 16, залишається майже 30 секунд.<br /> <br /> Кожен маршрутизатор працює на підставі свого внутрішнього таймера, не синхронізуючи роботу по розсилці оголошень з іншими маршрутизаторами. Тому дуже ймовірно, маршрутизатор М2 випередив маршрутизатор Ml і передав йому своє повідомлення раніше, ніж Ml встиг передати новину про недосяжність мережі 201.36.14.0. А в цьому повідомленні є дані, що породжені наступним записом в таблиці маршрутизації М2 (табл. 5).<br /> <br /> Таблиця 5. Таблиця маршрутизації маршрутизатора М2.<br /> <br /> [[Файл:Rip6.gif]]<br /> <br /> Цей запис був отриманий від маршрутизатора Ml і коректна до відмови інтерфейсу 201.36.14.3, а тепер вона застаріла, але маршрутизатор М2 про це не дізнався.<br /> <br /> Тепер маршрутизатор Ml отримав нову інформацію про мережу 201.36.14.0 - ця мережа досяжна через маршрутизатор М2 з метрикою 2. Раніше Ml також отримував цю інформацію від М2. Але ігнорував її, так як його власна метрика для 201.36.14.0 була краща. Тепер Ml повинен прийняти дані про мережу 201.36.14.0, отримані від М2, і замінити запис в таблиці маршрутизації про недосяжність цієї мережі (табл. 6).<br /> <br /> Таблиця 6. Таблиця маршрутизації маршрутизатора М1.<br /> <br /> [[Файл:Rip7.gif]]<br /> <br /> У результаті в мережі утворилася маршрутна петля: пакети, що направляються вузлам мережі 201.36.14.0, будуть передаватися маршрутизатором М2 маршрутизатору Ml, а маршрутизатор Ml буде повертати їх маршрутизатору М2. IP-пакети будуть циркулювати по цій петлі до тих пір, поки не закінчиться час життя кожного пакета.<br /> <br /> Маршрутна петля буде існувати в мережі досить довго. Розглянемо періоди часу, кратні часу життя записів у таблицях маршрутизаторів.<br /> <br /> *Час 0-180 с. Після відмови інтерфейсу в маршрутизаторах Ml і М2 будуть зберігатися некоректні записи, наведені вище. Маршрутизатор М2 як і раніше постачає маршрутизатор Ml своїм записом про мережу 201.36.14.0 з метрикою 2, так як її час життя не закінчився. Пакети зациклюються.<br /> <br /> *Час 180-360 с. На початку цього періоду у маршрутизатора М2 закінчується час життя запису про мережу 201.36.14.0 з метрикою 2, так як маршрутизатор Ml в попередній період посилав йому повідомлення про мережу 201.36.14.0 з гіршого метрикою, ніж у М2, і вони не могли підтверджувати цей запис. Тепер маршрутизатор М2 приймає від маршрутизатора Ml запис про мережу 201.36.14.0 з метрикою 3 та трансформує її в запис з метрикою 4. Маршрутизатор Ml не отримує нових повідомлень від маршрутизатора М2 про мережу 201.36.14.0 з метрикою 2, тому час життя його запису починає зменшуватися. Пакети продовжують зациклюватися.<br /> <br /> *Час 360-540 с. Тепер у маршрутизатора Ml закінчується час життя запису про мережу 201.36.14.0 з метрикою 3. Маршрутизатори Ml і М2 знову міняються ролями - М2 постачає Ml застарілою інформацією про шлях до мережі 201.36.14.0, вже з метрикою 4, яку Ml перетворює в метрику 5. Пакети продовжують зациклюватися.<br /> <br /> Якщо б у протоколі RIP не було вибрано відстань 16 як недосяжна, то описаний процес тривав би до нескінченності (вірніше, поки не була б вичерпана розрядна сітка поля відстані і не було б зафіксовано переповнення при черговому нарощуванні відстані).<br /> <br /> У результаті маршрутизатор М2 на черговому етапі описаного процесу отримує від маршрутизатора Ml метрику 15, яка після нарощування, перетворюючись на метрику 16, фіксує недосяжність мережі. Період нестабільної роботи мережі тривав 36 хвилин!<br /> <br /> Обмеження в 15 хопов звужує сферу застосування протоколу RIP до мереж, в яких число проміжних маршрутизаторів не може бути більше 15. Для більш масштабних мереж потрібно застосовувати інші протоколи маршрутизації, наприклад OSPF, або розбивати мережу на автономні області.<br /> <br /> Наведений приклад добре ілюструє головну причину нестабільної роботи маршрутизаторів, що працюють по протоколу RIP. Ця причина полягає в самому принципі роботи дистанційно-векторних протоколів - користування інформацією, отриманою з других рук. Дійсно, маршрутизатор М2 передав маршрутизатору Ml інформацію про досяжності мережі 201.36.14.0, за достовірність якої він сам не відповідає. Викорінити цю причину повністю не можна, адже сам спосіб побудови таблиць маршрутизації пов'язаний з передачею чужої інформації без зазначення джерела її походження.<br /> <br /> Не слід думати, що при будь-яких відмовах інтерфейсів і маршрутизаторів в мережах виникають маршрутні петлі. Якби маршрутизатор Ml встиг передати повідомлення про недосяжність мережі 201.36.14.0 раніше неправдивої інформації маршрутизатора М2, то маршрутна петля не утворилася б. Так що маршрутні петлі навіть без додаткових методів боротьби з ними, описаними в наступному розділі, виникають в середньому не більш ніж у половині потенційно можливих випадків.<br /> <br /> ==Методи боротьби з помилковими маршрутами в протоколі RIP==<br /> <br /> Незважаючи на те що протокол RIP не в змозі повністю виключити перехідні стани в мережі, коли деякі маршрутизатори користуються застарілою інформацією про вже неіснуючі маршрути, є кілька методів, які в багатьох випадках вирішують подібні проблеми.<br /> <br /> Ситуація з петлею, що утворюється між сусідніми маршрутизаторами, описана в попередньому розділі, надійно вирішується за допомогою методу, який отримав назву розщеплення горизонту (split horizon). Метод полягає в тому, що маршрутна інформація про деяку мережу, що зберігається в таблиці маршрутизації, ніколи не передається тому маршрутизатора, від якого вона отримана (це наступний маршрутизатор в даному маршруті). Якщо маршрутизатор М2 в розглянутому вище прикладі підтримує техніку розщеплення горизонту, то він не передасть маршрутизатора Ml застарілу інформацію про мережу 201.36.14.0, оскільки отримав її саме від маршрутизатора Ml.<br /> <br /> Практично всі сьогоднішні маршрутизатори, що працюють по протоколу RIP, використовують техніку розщеплення горизонту.<br /> <br /> Однак розщеплення горизонту не допомагає в тих випадках, коли петлі утворюються не двома, а кількома маршрутизаторами. Розглянемо більш детально ситуацію, яка виникне в мережі, наведеною на рис. 1, у разі втрати зв'язку маршрутизатора 2 з мережею А. Нехай всі маршрутизатори цієї мережі підтримують техніку розщеплення горизонту. Маршрутизатори М2 і МЗ не повертатимуть маршрутизатора в цій ситуації дані про мережу 201.36.14.0 з метрикою 2, так як вони отримали цю інформацію від маршрутизатора Ml. Однак вони будуть передавати маршрутизатору інформацію про досяжності мережі 201.36.14.0 з метрикою 4 через себе, тому що отримали цю інформацію по складному маршруту, а не від маршрутизатора Ml безпосередньо. Наприклад, маршрутизатор М2 отримав цю інформацію по ланцюжку М4-МЗ-М1. Тому маршрутизатор Ml знову може бути обдуреним, поки кожен з маршрутизаторів в ланцюжку МЗ-М4-М2 не викреслить запис про досяжності мережі 1 (а це відбудеться через період 3 х 180 секунд).<br /> <br /> Для запобігання зациклення пакетів по складовим петлям при відмовах зв'язків застосовуються два інших прийоми, так звані тригерні оновлення (triggered updates) і заморожування змін (hold down).<br /> <br /> Спосіб тригерних оновлень полягає в тому, що маршрутизатор, отримавши дані про зміну метрики до будь-якої мережі, не чекає закінчення періоду передачі таблиці маршрутизації, а передає дані про зміну маршруту негайно. Цей прийом може в багатьох випадках запобігти передачі застарілих відомостей про маршрут, що відмовив, але він перевантажує мережу службовими повідомленнями, тому тригерні оголошення також робляться з деякою затримкою. Тому можлива ситуація, коли регулярне оновлення в будь-якому маршрутизаторі трохи випередить за часом прихід тригерніх оновлень від попереднього в ланцюжку маршрутизатора і даний маршрутизатор встигне передати по мережі застарілу інформацію про неіснуючий маршрут.<br /> <br /> Другий прийом дозволяє виключити подібні ситуації. Він пов'язаний з введенням тайм-ауту на прийняття нових даних про мережу, яка щойно стала недоступною. Цей тайм-аут запобігає прийняттю застарілих відомостей про деякий маршрут від тих маршрутизаторів, які знаходяться на деякій відстані від зв'язку, що відмовив та передають застарілі відомості про його працездатність. Передбачається, що протягом тайм-ауту «заморожування змін» ці маршрутизатори викреслять даний маршрут зі своїх таблиць, оскільки не отримають про нього нових записів і не поширюватимуть застарілі відомості по мережі.<br /> <br /> <br /> Матеріали взяті з: В. Г. Олифер, Н. А. Олифер. Компьютерные сети. Принципы, технологии, протоколы. Учебник для вузов. 2010</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%97%D0%B0%D1%81%D0%BE%D0%B1%D0%B8_%D0%BC%D0%BE%D0%BD%D1%96%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3%D1%83_%D1%82%D0%B0_%D0%B0%D0%BD%D0%B0%D0%BB%D1%96%D0%B7%D1%83_%D0%BC%D0%B5%D1%80%D0%B5%D0%B6%D1%96 2011-12-19T11:41:25Z

<p>Aleksey: </p> <hr /> <div>== Класифікація засобів моніторингу та аналізу ==<br /> <br /> Всі засоби моніторингу та аналізу мереж, можна розділити на кілька великих класів:<br /> <br /> *''Системи управління мережею'' ([http://en.wikipedia.org/wiki/Network_management_system Network Management Systems]) - централізовані програмні системи, які збирають дані про стан вузлів і комунікаційних пристроїв мережі, а також дані про трафік в мережі. Ці системи не тільки здійснюють моніторинг і аналіз, а й виконують в автоматичному чи напівавтоматичному режимі управління мережею - включення і відключення портів пристроїв, зміна параметрів мостів адресних таблиць мостів, комутаторів і маршрутизаторів і т.п. Прикладами систем управління можуть служити популярні системи HPOpenView, SunNetManager, IBMNetView.<br /> <br /> *''Засоби управління системою'' ([http://uk.wikipedia.org/wiki/%D0%92%D0%B1%D1%83%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B0_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0#.D0.90.D1.80.D1.85.D1.96.D1.82.D0.B5.D0.BA.D1.82.D1.83.D1.80.D0.B8_.D0.BF.D1.80.D0.BE.D0.B3.D1.80.D0.B0.D0.BC.D0.BD.D0.BE.D0.B3.D0.BE_.D0.B7.D0.B0.D0.B1.D0.B5.D0.B7.D0.BF.D0.B5.D1.87.D0.B5.D0.BD.D0.BD.D1.8F_.D0.B2.D0.B1.D1.83.D0.B4.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.85_.D1.81.D0.B8.D1.81.D1.82.D0.B5.D0.BC System Management]). Засоби управління системою часто виконують функції, аналогічні функціям систем управління, але стосовно інших об'єктів. У першому випадку об'єктом управління є програмне і апаратне забезпечення комп'ютерів мережі, а у другому - комунікаційне устаткування. Разом з тим, деякі функції цих двох видів систем управління можуть дублюватися, наприклад, засоби управління системою можуть виконувати найпростіший аналіз мережевого трафіку.До найбільш відомих систем управління системами відносяться LANDesk, IBM Tivoli, Microsoft Systems Management Server, HP OpenView, Novell ZENworks і CA Unicenter.<br /> <br /> *''Вбудовані системи діагностики і управління'' ([http://en.wikipedia.org/wiki/Embedded_system Embedded Systems]). Ці системи виконуються у вигляді програмно-апаратних модулів, які встановлюються в комунікаційне обладнання, а також у вигляді програмних модулів, вбудованих в операційні системи. Вони виконують функції діагностики і управління тільки одним пристроєм, і в цьому їх основна відмінність від централізованих систем управління. Прикладом засобів цього класу може служити модуль управління концентратором Distrebuted 5000, реалізує функції автосигментацієї портів при виявленні несправностей, приписування портів внутрішнім сегментам концентратора і деякі інші. Як правило, вбудовані модулі управління також виконують роль SNMP-агентів, які поставляють дані про стан пристрою системам управління. <br /> <br /> *''Аналізатори протоколів'' (Protocolanalyzers). Представляють собою програмні або апаратно-програмні системи, які обмежуються на відміну від систем управління лише функціями моніторингу і аналізу трафіку в мережах. Хороший аналізатор протоколів може захоплювати і декодувати пакети великої кількості протоколів, що застосовуються в мережах - зазвичай кілька десятків. Аналізатори протоколів дозволяють встановити деякі логічні умови для захоплення окремих пакетів і виконують повне декодування захоплених пакетів, тобто показувати в зручній для користувача формі вкладеність пакетів протоколів різних рівнів один в одного з розшифруванням змісту окремих полів кожного пакета.<br /> <br /> *''Обладнання для діагностики і сертифікації кабельних систем''. Умовно це устаткування можна поділити на чотири основні групи: мережні монітори, прилади для сертифікації кабельних систем, кабельні сканери і тестери (мультиметри). Мережеві монітори (називають також мережевими аналізаторами) призначені для тестування кабелів різних категорій. Слід розрізняти мережеві монітори і аналізатори протоколів. Мережеві монітори збирають дані лише про статистичні показники трафіку - середньої інтенсивності загального трафіку мережі, середньої інтенсивності потоку пакетів з певним типом помилки і т.п. Призначення пристроїв для сертифікації кабельних систем, безпосередньо випливає з їх назви. Сертифікація виконується відповідно до вимог одного з міжнародних стандартів на кабельні системи. Кабельні сканери використовуються для діагностики мідних кабельних систем. Тестери призначені для перевірки кабелів на відсутність фізичного розриву.<br /> <br /> *''Експертні системи''. Цей вид систем акумулює людські знання про виявлення причин аномальної роботи мереж і можливі способи приведення мережі у працездатний стан. Експертні системи часто реалізуються у вигляді окремих підсистем різних засобів моніторингу та аналізу мереж: систем управління мережами, аналізаторів протоколів, мережевих аналізаторів. Найпростішим варіантом експертної системи є контекстно-залежна help-система. Більш складні експертні системи являють собою так звані бази знань, що володіють елементами штучного інтелекту. Прикладом такої системи є експертна система, вбудована в систему управління Spectrum компанії Cabletron. <br /> <br /> *''Багатофункціональні пристрої аналізу та діагностики''. У зв'язку з розповсюдженням локальних мереж виникла необхідність розробки недорогих портативних приладів, які суміщають функції декількох пристроїв: аналізаторів протоколів, кабельних сканерів і, навіть, деяких можливостей ПЗ мережного управління. Як приклад такого роду пристроїв можна привести Compas компанії MicrotestInc. або 675 LANMeterкомпаніі FlukeCorp.<br /> <br /> == Системи управління ==<br /> Відповідно до рекомендацій ISO можна виділити такі функцій '''засобів управління мережею''':<br /> <br /> * ''Управління конфігурацією мережі'' - полягає в конфігурації компонентів мережі, включаючи їх місце розташування, мережні адреси і ідентифікатори, управління параметрами мережевих операційних систем, підтримку схеми мережі: також ці функції використовуються для іменування об'єктів. <br /> <br /> * ''Обробка помилок'' - це виявлення і усунення наслідків збоїв у роботі мережі. <br /> <br /> * ''Аналіз продуктивності'' - допомагає на основі накопиченої статистичної інформації оцінювати час відповіді системи і величину трафіка, а також планувати розвиток мережі. <br /> <br /> * ''Управління безпекою'' - включає в себе контроль доступу та збереження цілісності даних. У функції входить процедура аутентифікації, перевірки привілеїв, підтримка ключів шифрування, управління правами. До цієї ж групи можна віднести важливі механізми управління паролями, зовнішнім доступом, з'єднання з іншими мережами. <br /> <br /> * ''Облік роботи мережі'' - включає реєстрацію і управління використовуваними ресурсами і пристроями. Ця функція оперує такими поняттями як час використання і плата за ресурси.<br /> <br /> З наведеного списку видно, що системи управління виконують не тільки функції моніторингу та аналізу роботи мережі, необхідні для отримання вихідних даних для налаштування мережі, але і включають функції активного впливу на мережу - управління конфігурацією і безпекою, які потрібні для відпрацювання виробленого плану настройки та оптимізації мережі. Сам етап створення плану налаштування мережі зазвичай залишається за межами функцій системи управління, хоча деякі системи управління мають у своєму складі експертні підсистеми, що допомагають адміністратору або интегратору визначити необхідні заходи з настроювання мережі. <br /> <br /> Засоби управління мережею (NetworkManagement), не слід плутати із засобами управління комп'ютерами та їх операційними системами (SystemManagement). Типовими представниками засобів управління мережами є системи HPOpenView, SunNetManager і IBMNetView.<br /> <br /> '''Засоби управління системою''' зазвичай виконують такі функції:<br /> <br /> *''Облік використовуваних апаратних і програмних засобів''. Система автоматично збирає інформацію про комп'ютери і створює записи в базі даних про апаратні і програмні ресурси. Після цього адміністратор може швидко з'ясувати, що він має і де це знаходиться. Наприклад, дізнатися про те, на яких комп'ютерах потрібно оновити драйвери принтерів, які ПК мають достатню кількість пам'яті і дискового простору і т. п. <br /> <br /> * ''Розподіл й встановлення програмного забезпечення''. Після завершення обстеження адміністратор може створити пакети розсилки програмного забезпечення, що являється дуже ефективним способом для зменшення вартості такої процедури. Система може також дозволяти централізовано встановлювати і адмініструвати програми, які запускаються з файлових серверів, а також дати можливість кінцевим користувачам запускати такі програми з будь-якої робочої станції мережі.<br /> <br /> * ''Віддалений аналіз продуктивності і виникаючих проблем''. Адміністратор може віддалено управляти ресурсами будь-якого ПК, що працює в мережі. База даних системи управління зберігає детальну інформацію про конфігурацію всіх комп'ютерів в мережі для того, щоб можна було виконувати віддалений аналіз виникаючих проблем.<br /> <br /> Прикладами засобів управління системою є такі продукти, як SystemManagementServer компанії Microsoft або LANDeskManager фірми Intel.<br /> <br /> Останнім часом в області систем управління спостерігаються дві досить чітко виражені тенденції: <br /> <br /> *інтеграція в одному продукті функцій управління мережами і системами;<br /> *розподіленість системи управління, при якій в системі існує кілька консолей, які збирають інформацію про стан пристроїв і систем та видають керуючі дії.<br /> <br /> ===Стандарти управління мережою===<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Організація&lt;/td&gt;<br /> &lt;td&gt;Стандарти&lt;/td&gt;<br /> &lt;td&gt;Особливості&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;IETF&lt;/td&gt;<br /> &lt;td&gt;SNMP&lt;/td&gt;<br /> &lt;td&gt;Управління має бути простим, орієнтоване на змінні&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;ISO&lt;/td&gt;<br /> &lt;td&gt;CMIP, CMIS&lt;/td&gt;<br /> &lt;td&gt;Управління має бути потужним, об'єктно-орієнтованим&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;ITU-T&lt;/td&gt;<br /> &lt;td&gt;TMN&lt;/td&gt;<br /> &lt;td&gt;Визначена тільки архітектура&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;DMTF&lt;/td&gt;<br /> &lt;td&gt;WBEM, CIM&lt;/td&gt;<br /> &lt;td&gt;Управління мережами і системами, об'єктно-орієнтоване&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;OMG&lt;/td&gt;<br /> &lt;td&gt;CORBA&lt;/td&gt;<br /> &lt;td&gt;Архітектура віддалених об'єктів&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> Нині найуспішнішим сімейством стандартів є [[SNMP]]. Він лідирує за кількістю керованих систем (агентів). Керуючі системи (менеджери) зазвичай підтримують безліч стандартів, тому тут складно говорити про лідерство SNMP. За кількістю вкладених грошей, можливо, лідирує Telecommunications Management Network (TMN).<br /> <br /> Показово простежити залежність популярності стандартів від середовища їх застосування. У локальних і глобальних мережах передачі даних, що використовують Протокол інтернету (Internet Protocol, IP) найбільш широко розповсюджений стандарт [[SNMP]]. У системах відомчих автоматичних телефонних станцій (ВАТС) та в публічних телефонних мережах найбільш часто використовуються пропрієтарні рішення. У мобільних мережах в основному використовуються рішення на основі стандартів ISO.<br /> <br /> Майже всі успіхи SNMP пов'язані з особливостями процесу стандартизації в IETF:<br /> <br /> *Стандарти безкоштовні і вільно розповсюджувані;<br /> <br /> *Стандарти легко доступні в електронній формі;<br /> <br /> *Швидкий розвиток стандартів, продумані етапи стандартизації;<br /> <br /> *На всіх етапах ведеться технічна експертиза;<br /> <br /> *Робочі групи очолюють технічні, а не політичні лідери;<br /> <br /> *Прототипи систем на основі стандартів демонструють їх придатність;<br /> <br /> ===Протокол [[SNMP]]===<br /> <br /> Створення систем управління мережами неможливе без орієнтації на певні стандарти, тому що управляюче програмне забезпечення та мережеве обладнання розробляють сотні компаній. Оскільки корпоративна мережа напевно неоднорідна, керуючі інструменти не можуть відображати специфіки однієї системи або мережі. <br /> Найбільш поширеним протоколом управління мережами є протокол [[SNMP]] (SimpleNetworkManagementProtocol), його підтримують сотні виробників. Головні переваги протоколу SNMP - простота, доступність, незалежність від виробників. Значною мірою саме популярність [[SNMP]] затримала прийняття CMIP, варіанта керуючого протоколу за версією OSI. Протокол SNMP розроблений для управління маршрутизаторами в мережі Internet і є частиною стека TCP/IP.<br /> <br /> У системах управління, побудованих на основі протоколу [[SNMP]], стандартизуються наступні елементи:<br /> <br /> *протокол взаємодії агента і менеджера;<br /> <br /> *мова опису моделей MIВ та повідомлень [[SNMP]] - мова абстрактної синтаксичної нотації [[ASN.1]] (стандарт ISO 8824:1987, рекомендації ITU-T X.208);<br /> <br /> *кілька конкретних моделей MIB (MIB-I, MIB-II, RMON, RMON 2), імена об'єктів яких реєструються в дереві стандартів ISO. Все інше віддається на розсуд розробника системи управління. Протокол SNMP і тісно пов'язана з ним концепція SNMP MIB були розроблені для управління маршрутизаторами Internet як тимчасове рішення. Але, як це часто буває з усім тимчасовим, простота і ефективність вирішення забезпечили успіх цього протоколу, і сьогодні він використовується при управлінні практично будь-якими видами обладнання і програмного забезпечення обчислювальних мереж. І хоча в області управління телекомунікаційними мережами спостерігається стійка тенденція застосування стандартів ITU-T, в які входить протокол CMIP, і тут є досить багато прикладів успішного використання SNMP-управління. Агенти SNMP вбудовуються в аналогові модеми, модеми ADSL, комутатори АТМ і т. д.<br /> <br /> SNMP - це протокол, що використовується для отримання від мережевих пристроїв інформації про їх статус, продуктивність та характеристики, які зберігаються в спеціальній базі даних мережевих пристроїв, що називається MIB (ManagementInformationBase). Існують стандарти, що визначають структуру MIB, в тому числі набір типів її змінних (об'єктів в термінології ISO), їх імена і допустимі операції цими змінними (наприклад, читати). У MIB, поряд з іншою інформацією, можуть зберігатися мережеві та / або MAC-адреси пристроїв, значення лічильників оброблених пакетів і помилок, номери, пріоритети та інформація про стан портів. Деревоподібна структура MIB містить обов'язкові (стандартні) піддерева, а також в ній можуть знаходитися приватні (private) піддерева, що дозволяють виробнику інтелектуальних пристроїв реалізувати будь-які специфічні функції на основі його специфічних змінних. <br /> <br /> Агент в протоколі SNMP - це елемент, який надає менеджерам, розміщеним на керуючих станціях мережі, доступ до значень змінних MIB, і тим самим дає їм можливість реалізовувати функції з управління та спостереження за пристроєм. Типова структура системи управління зображена на наступному малюнку:<br /> <br /> [[Файл:Locnop2211.gif]] <br /> <br /> ===Стандарти управління OSI===<br /> <br /> ====Загальні відомості. Концепція SMAE====<br /> <br /> Модель мережевого управління OSI - OSI Management Framework - визначена в документі ISO / IEC 7498-4: Basic Reference Model, Part 4, Management Framework.<br /> <br /> Документ ISO / IEC 7498-4 складається з наступних основних розділів:<br /> <br /> *Терміни та загальні концепції.<br /> <br /> *Модель управління системами.<br /> <br /> *Інформаційна модель.<br /> <br /> *Функціональні області управління системами.<br /> <br /> *Структура стандартів управління системами.<br /> <br /> Функціональні області управління системами вже були розглянуті вище.<br /> <br /> Стандарти ISO в галузі управління використовує термінологію, яка частково збігається з термінологією систем управління SNMP.<br /> <br /> Як показано на малюнку, обмін керуючою інформацією з використанням протоколу управління (Management Protocol) відбувається між суб'єктами програм управління системами (Systems Management Application Entities, SMAE):<br /> <br /> [[Файл:Smae.jpg]]<br /> <br /> Суб'єкти SMAE розташовані на прикладному рівні семирівневої моделі OSI і є елементами служби управління. Під суб'єктом в моделі OSI розуміється активний в даний момент елемент протоколу будь-якого рівня, який бере участь у взаємодії. Прикладами SMAE є агенти та менеджери систем управління.<br /> <br /> ====Агенти та менеджери====<br /> <br /> Визначення функцій агентів і менеджерів в стандартах OSI досить добре узгоджуються з визначеннями систем SNMP, за деякими винятками в термінології. Повідомлення, які агент посилає менеджеру за своєю ініціативою, називаються повідомленнями - notifications.<br /> <br /> Наприклад, якщо деякий елемент мережі Х відмовив, то менеджеру необхідно оновити свою базу даних конфігурації мережі. Елемент X, який є для системи управління керованим об'єктом (managed object), може послати повідомлення агенту. Елемент Х може знаходитися в тій же керованої системі, що і агент, або може перебувати в іншій системі. У свою чергу агент надсилає повідомлення менеджеру про те, що елемент Х відмовив. Відповідно до цього повідомленням менеджер оновлює базу даних конфігурації.<br /> <br /> ''ПРИМІТКА''. У стандартах Internet під об'єктом розуміється окремий атрибут бази МIВ, що є моделлю керованого ресурсу, а в стандартах ISO об'єкт позначає всю модель керованого ресурсу.<br /> <br /> Менеджер не тільки збирає і порівнює дані, одержувані від агентів, на основі цих даних він може також виконувати адміністративні функції, керуючи операціями віддалених агентів.<br /> <br /> У стандартах OSI різниця між менеджерами та агентами не дуже чітка. Суб'єкт SMAE, що виконує в одній взаємодії роль менеджера, може в іншій взаємодії виконувати роль агента, і навпаки.Стандарти OSI не визначають способів взаємодії агента з керованими об'єктами. Стандарти OSI також не говорять про те, як агент взаємодіє з керованими об'єктами, які перебувають за межами керованої системи, тобто об'єктами, з якими потрібно взаємодіяти через мережу. У таких випадках може знадобитися, наприклад, щоб один агент запросив дані про деякий об'єкт від іншого агента. Порядок такого роду взаємодії також не визначається стандартами OSI.<br /> <br /> Щоб менеджер і агент змогли взаємодіяти, кожен повинен мати певні відомості про один одного. Ці відомості модель OSI називає контекстом додатку (Application Context, AC). AC описує елементи прикладного рівня стека OSI, які використовуються агентами і менеджерами.<br /> <br /> ''ПРИМІТКА''. Необхідно зазначити, що стандарти управління OSI значною мірою орієнтовані на стек протоколів OSI (саме стек, а не модель OSI), так само як системи управління SNMP орієнтовані на роботу зі стеком TCP / IP.<br /> <br /> Прикладний рівень стека OSI включає кілька допоміжних служб загального призначення, які використовуються прикладними протоколами і клієнтськими програмами (в тому числі і додатками управління) для автоматизації найбільш часто виконуваних дій. Це не закінчені протоколи прикладного рівня, подібні протоколах ftp, telnet або NCP, за допомогою яких користувач мережі може виконати якусь корисну дію, а допоміжні системні функції, які допомагають розробнику прикладного протоколу або програми написати її компактно і ефективно. На прикладному рівні стека OSI існують наступні допоміжних служби:<br /> <br /> *ACSE (Association Control Service Element). Відповідає за встановлення з'єднань між додатками різних систем. З'єднання (сесія, сеанс) на прикладному рівні OSI носить назву асоціації. Асоціації бувають індивідуальними та груповими (shared).<br /> <br /> *RTSE (Reliable Transfer Service Element). Займається підтримкою відновлення діалогу, викликаного розривом нижележащих комунікаційних служб, в рамках асоціації.<br /> <br /> *ROSE (Remote Operations Service Element). Організовує виконання програмних функцій на віддалених машинах (аналог служби виклику віддалених процедур RPC).<br /> <br /> ====Управління системами, управління рівнем та операції рівня====<br /> <br /> Основна модель управління OSI включає: управління системами, управління N-рівнем і операції N-рівня. Це розбиття на три області зроблено для того, щоб врахувати всі можливі ситуації, що виникають при управлінні.<br /> <br /> Управління системами має справу з керованими об'єктами на всіх семи рівнях OSI, включаючи прикладний рівень. Воно засноване на надійній передачі з встановленням з'єднання керуючої інформації між кінцевими системами. Необхідно підкреслити, що модель управління OSI не дозволяє використання служб без встановлення з'єднання.<br /> <br /> Управління N-рівнем обмежено керованими об'єктами якогось певного рівня семирівневої моделі. Протокол управління використовує при цьому комунікаційні протоколи нижчих рівнів. Управління N-рівнем корисно, коли немає можливості використовувати всі семи рівнів OSI. У цьому випадку допускається користуватися протоколом управління N-рівня, який строго призначений для даного рівня. Прикладами рівневого протоколу управління є протоколи управління для локальних мереж, розроблені інститутом IEEE (SMT технології FDDI), які обмежені рівнями 1 і 2.<br /> <br /> Нарешті, операції N-рівня зводяться до моніторингу та управління на основі керуючої інформації, що міститься в комунікаційних протоколах тільки даного рівня. Наприклад, дані моніторингу мережі, що містяться в кадрах STM-n технології SDH, відносяться до операцій N-рівня, а саме фізичного рівня.<br /> Стандарти на управління N-рівнем і операції N-рівня не входять в набір стандартів управління OSI. Стандарти OSI розглядають лише управління системами за допомогою повного семирівневого стека.<br /> <br /> Основна модель управління системами передбачає виконання керуючих операцій і передачу повідомлень між одноранговими системами, що означає необов'язковість жорсткого розподілу ролей на керуючі та керовані системи. Ця модель полегшує реалізацію розподілених аспектів управління. З іншого боку, допускається реалізація однорангових систем як керуючих і керованих.<br /> <br /> ====Інформаційна модель управління====<br /> <br /> Керований об'єкт - це представлення OSI про ресурс з метою управління. Ресурс може бути описаний як керований об'єкт. Конкретний керований об'єкт - це екземпляр (instance) деякого класу керованих об'єктів. Модель управління OSI широко використовує об'єктно-орієнтований підхід. Клас керованих об'єктів - це набір властивостей, які можуть бути обов'язковими або умовними. За допомогою опису одного класу керованих об'єктів, наприклад комутаторів, можна створити інший клас керованих об'єктів, наприклад комутаторів, що підтримують техніку VLAN, успадкувавши всі властивості класу комутаторів, але додавши нові атрибути.<br /> <br /> Для управління ресурсами менеджер і агент повинні бути обізнані про деталі цих ресурсів. Деталізація представлення керованих об'єктів, які потрібні для виконання функцій управління, зберігається в репозиторії, відомому як Management Information Base (MIB). Бази MIB OSI зберігають не тільки описи класів керованих об'єктів, але й характеристики мережі та її елементів. Бази MIB містять характеристики кожної частини керованого обладнання і ресурсів. MIB також включає опис дій, які можуть виконуватися на основі зібраних даних або ж викликані зовнішніми командами. Бази MIB дозволяють зовнішнім системам опитувати, змінювати, створювати і видаляти керовані об'єкти (реальні ресурси мережі при цьому, природно, продовжують працювати). Протокол CMIP і локальні інтерфейси управління забезпечують доступ до цих можливостей.<br /> <br /> MIB - це концептуальна модель, і вона не має ніякого зв'язку зі способом фізичного або логічного зберігання даних в ресурсі. Стандарти не визначають аспекти власне зберігання даних. Протоколи OSI визначають синтаксис інформації, що зберігається в MIB, і семантику обміну даними.<br /> <br /> ====Протокол CMIP та послуги CMIS====<br /> <br /> Доступ до керуючої інформації, що зберігається в керованих об'єктах, забезпечується за допомогою елемента системи управління, званого службою CMSIE (Common Management Information Service Element). Служба CMSIE побудована в архітектурі розподіленого додатку, де частину функцій виконує менеджер, а частина - агент. Взаємодія між менеджером і агентом здійснюється по протоколу CMIP. Послуги, що надаються службою CMSIE, називаються послугами CMIS (Common Management Information Services).<br /> <br /> Протокол CMIP та послуги CMIS визначені в стандартах Х.710 і Х.711 ITU-T. Послуги CMIS поділяються на дві групи - послуги, що ініціюються менеджером (запити), та послуги, що ініціюються агентом (повідомлення).<br /> <br /> Послуги, що ініціюються менеджером, включають наступні операції:<br /> <br /> *M-CREATE інструктує агента про необхідність створити новий екземпляр об'єкту певного класу або новий атрибут усередині екземпляра об'єкта;<br /> <br /> *M-DELETE інструктує агента про необхідність видалення деякого екземпляра об'єкту певного класу або атрибуту усередині екземпляра об'єкта;<br /> <br /> *M-GET інструктує агента про повернення значення деякого атрибуту певного екземпляра об'єкту;<br /> <br /> *M-SET інструктує агента про зміну значення деякого атрибуту певного екземпляра об'єкту;<br /> <br /> *M-ACTION інструктує агента про необхідність виконання певної дії над одним або кількома примірниками об'єктів.<br /> <br /> Агент ініціює тільки одну операцію:<br /> M-EVENT_REPORT - відправка повідомлення менеджеру.<br /> <br /> Для реалізації своїх послуг служба CMISE повинна використовувати служби прикладного рівня стека OSI - ACSE, ROSE.<br /> <br /> Відмінність послуг CMIS від аналогічних послуг SNMP полягає в більшій гнучкості. Якщо запити GET і SET протоколу SNMP застосовні тільки до одного атрибуту одного об'єкта, то запити M-GET, M-SET, M-ACTION і M-DELETE можуть застосовуватися до більш ніж одного об'єкту. Для цього стандарти CMIP / CMIS вводять такі поняття, як огляд (scoping), фільтрація (filtering) і синхронізація (synchronization).<br /> <br /> ===Порівняння протоколів SNMP та CMIP===<br /> <br /> *Застосування протоколу SNMP дозволяє будувати як прості, так і складні системи управління, а застосування протоколу CMIP визначає деякий, досить високий початковий рівень складності системи управління, так як для його роботи необхідно реалізувати ряд допоміжних служб, об'єктів і баз даних об'єктів.<br /> <br /> *Агенти CMIP виконують, як правило, більш складні функції, ніж агенти SNMP. Через це операції, які менеджеру можна виконати над агентом SNMP, носять атомарний характер, що призводить до численних обмінів між менеджером і агентом.<br /> <br /> *Повідомлення (traps) агента SNMP надсилаються менеджеру без очікування підтвердження, що може привести до того, що важливі мережеві проблеми залишаться непоміченими, оскільки відповідне повідомлення виявиться втраченим, у той час як повідомлення агента CMIP завжди передаються за допомогою надійного транспортного протоколу і в разі втрати будуть передані повторно.<br /> <br /> *Вирішення частини проблем SNMP може бути досягнуто за рахунок застосування більш інтелектуальних MIB (до яких відноситься RMON MIB), але для багатьох пристроїв і ситуацій таких MIB немає (або немає стандарту, або немає відповідної MIB в керованому обладнанні).<br /> <br /> *Протокол CMIP розрахований на інтелектуальних агентів, які можуть по одній простій команді від менеджера виконати складну послідовність дій.<br /> <br /> *Протокол CMIP істотно краще масштабується, тому що може впливати відразу на декілька об'єктів, а відповіді від агентів проходять через фільтри, які обмежують передачу керуючої інформації тільки певним агентам і менеджерам.<br /> <br /> == Вбудовані засоби моніторингу і аналізу мереж ==<br /> <br /> === Агенти [[SNMP]] ===<br /> <br /> На сьогоднішній день існує кілька стандартів на бази даних управляючої інформації. Основними є стандарти MIB-I і MIB-II, а також версія бази даних для віддаленого управління [[RMON MIB]]. Крім цього, існують стандарти для спеціальних [[MIB]] пристроїв конкретного типу, а також приватні [[MIB]] конкретних фірм-виробників обладнання.<br /> <br /> Початкова специфікація MIB-I визначала лише операції читання значень змінні величини. Операції зміни чи установки значень об'єкта є частиною специфікацій MIB-II.<br /> <br /> Версія MIB-I (RFC 1156) визначає до 114 об'єктів, які поділяються на 8 груп:<br /> <br /> * System - загальні дані про пристрій (наприклад, ідентифікатор постачальника, час останньої ініціалізації системи).<br /> <br /> * Interfaces - описуються параметри мережевих інтерфейсів пристрою (наприклад, їх кількість, типи, швидкості обміну, максимальний розмір пакету).<br /> <br /> * AddressTranslationTable - описується відповідність між мережевими і фізичними адресами (наприклад, за протоколом [[ARP]]).<br /> <br /> * [[IP|InternetProtocol]] - дані, що відносяться до протоколу IP (адреси IP-шлюзів, хостів, статистика про IP-пакети).<br /> <br /> * [[ICMP]] - дані, що пов'язані з протоколом обміну керуючими повідомленнями [[ICMP]].<br /> <br /> * [[TCP]] - дані, що належать до протоколу [[TCP]]. <br /> <br /> * [[UDP]] - дані, що належать до протоколу [[UDP]] (кількість переданих, прийнятих та помилкових UPD-дейтаграмм). <br /> <br /> * [[EGP]] - дані, що пов'язані з протоколом обміну маршрутною інформацією ExteriorGatewayProtocol, який використовується в мережі Internet (число прийнятих з помилками і без помилок повідомлень).<br /> <br /> З цього переліку груп змінних видно, що стандарт MIB-I розроблявся з жорсткою орієнтацією на управління маршрутизаторами, які підтримують протоколи стека TCP/IP.<br /> <br /> У версії MIB-II (RFC 1213), прийнятої в 1992 році, був істотно (до 185) розширено набір стандартних об'єктів, а кількість груп збільшилася до 10.<br /> <br /> У число об'єктів, що описують кожен конкретний інтерфейс пристрою, включені наступні:<br /> <br /> * IfType - тип протоколу, який підтримує інтерфейс. Цей об'єкт приймає значення всіх стандартних протоколів канального рівня, наприклад, rfc877-x25, ethernet-csmacd, iso88023-csmacd, iso88024-tokenBus, iso88025-tokenRing і т. д.<br /> <br /> * IfMtu - максимальний розмір пакета мережного рівня, який можна послати через цей інтерфейс.<br /> <br /> * IfSpeed - пропускна здатність інтерфейсу в бітах в секунду (100 для Fast Ethernet).<br /> <br /> * IfPhysAddress - фізичну адресу порту, для [[Fast Ethernet]] ним буде [[MAC]]-адреса.<br /> <br /> * IfAdminStatus - бажаний статус порту:<br /> <br /> :up - готовий передавати пакети;<br /> :down - не готовий передавати пакети;<br /> :testing - знаходиться в тестовому режимі.<br /> <br /> * IfOperStatus - фактичний поточний статус порту, має ті ж значення, що і ifAdminStatus.<br /> <br /> * IfInOctets - загальна кількість байт, прийняте даним портом, включаючи службові, з моменту останньої ініціалізації SNMP-агента.<br /> <br /> * IfInUcastPkts - кількість пакетів з індивідуальним адресою інтерфейсу, доставлених протоколу верхнього рівня.<br /> <br /> * IfInNUcastPkts - кількість пакетів з широкомовним або мультівещательнимі адресою інтерфейсу, доставлених протоколу верхнього рівня.<br /> <br /> * IfInDiscards - кількість пакетів, які були прийняті інтерфейсом, виявилися коректними, але не були доставлені протоколу верхнього рівня, швидше за все через переповнення буфера пакетів або ж з іншої причини.<br /> <br /> * IfInErrors - кількість пакетів, що прийшли, які не були передані протоколу верхнього рівня через виявлення в них помилок.<br /> <br /> Окрім об'єктів, що описують статистику за вхідними пакетів, є аналогічні об'єкти, пов'язані з вихідними пакетами. Як видно з опису об'єктів MIB-II, ця база даних не дає детальної статистики по характерних помилок кадрів [[Ethernet]], крім цього, вона не відображає зміну характеристик у часі, що часто цікавить мережевого адміністратора. Ці обмеження були згодом зняті новим стандартом на [[MIB]] - [[RMON MIB]], який спеціально орієнтований на збір детальної статистики по протоколу [[Ethernet]], до того ж з підтримкою такої важливої функції, як побудова агентом залежностей статистичних характеристик від часу.<br /> <br /> === Агенти [[RMON]] ===<br /> <br /> Нововведенням до функціональних можливостей SNMP є специфікація RMON, яка забезпечує віддалену взаємодію з базою MIB. До появи RMON протокол SNMP не міг використовуватися віддалено, він допускав лише локальне управління пристроями. База RMONMIB має поліпшений набір властивостей для віддаленого управління, оскільки містить агреговану інформацію про пристрій, що не вимагає передачі по мережі великих обсягів інформації. Об'єкти RMONMIB включають додаткові лічильники помилок в пакетах, гнучкіші засоби аналізу графічних трендів і статистики, більш потужні засоби фільтрації для захоплення і аналізу окремих пакетів, а також більш складні умови встановлення сигналів попередження. Агенти RMONMIB більш інтелектуальні порівняно з агентами MIB-I або MIB-II і виконують значну частину роботи по обробці інформації про пристрій, яку раніше виконували менеджери. Ці агенти можуть розташовуватися усередині різних комунікаційних пристроїв, а також бути виконані у вигляді окремих програмних модулів, що працюють на універсальних ПК і ноутбуках (прикладом може служити LANalyzerNovell). <br /> <br /> Об'єкту [[RMON]] присвоєно номер 16 в наборі об'єктів [[MIB]], а сам об'єкт [[RMON]] об'єднує 10 груп наступних об'єктів:<br /> <br /> * ''Statistics'' - поточні накопичені статистичні дані про характеристики пакетів, кількості колізій тощо. <br /> <br /> * ''History'' - статистичні дані, збережені через певні проміжки часу для подальшого аналізу тенденцій їх змін. <br /> <br /> * ''Alarms'' - порогові значення статистичних показників, при перевищенні яких агент RMON посилає повідомлення менеджеру.<br /> <br /> * ''Host'' - дані про хости мережі, у тому числі про їх [[MAC]]-адресах.<br /> <br /> * ''HostTopN'' - таблиця найбільш завантажених хостів мережі.<br /> <br /> * ''TrafficMatrix'' - статистика про інтенсивність трафіка між кожною парою хостів мережі.<br /> <br /> * ''Filter'' - умови фільтрації пакетів. <br /> <br /> * ''PacketCapture'' - умови захоплення пакетів. <br /> <br /> * ''Event'' - умови реєстрації і генерації подій.<br /> <br /> Дані групи пронумеровані у вказаному порядку, тому, наприклад, група Hosts має числове ім'я 1.3.6.1.2.1.16.4.<br /> <br /> Десяту групу складають спеціальні об'єкти протоколу TokenRing.<br /> <br /> Всього стандарт RMONMIB визначає близько 200 об'єктів в 10 групах, зафіксованих в двох документах - RFC 1271 для мереж Ethernet і RFC 1513 для мереж TokenRing.<br /> <br /> Відмінною рисою стандарту RMONMIB є його незалежність від протоколу мережевого рівня (на відміну від стандартів MIB-I і MIB-II, орієнтованих на протоколи TCP / IP). Тому, його зручно використовувати в гетерогенних середовищах, що використовують різні протоколи мережевого рівня.<br /> <br /> Розглянемо більш докладно групу Statistics, яка визначає, яку інформацію про кадри [[Ethernet]] може надати агент RMON.<br /> <br /> До групи Statistics входять наступні об'єкти:<br /> <br /> *''etherStatsDropEvents'' - загальне число подій, при яких пакети були проігноровані агентом через нестачу його ресурсів. Самі пакети при цьому не обов'язково були втрачені.<br /> <br /> *''etherStatsOrtets'' - загальне число байт (включаючи помилкові пакети), прийнятих з мережі (крім заголовка але з байтами контрольної суми).<br /> <br /> *''etherStatsPkts'' - загальне число отриманих пакетів (включаючи помилкові).<br /> <br /> *''etherStatsBroadcastPkts'' - загальне число хороших пакетів, які були надіслані широкомовною адресою.<br /> <br /> *''etherStatsMulticastPkts'' - загальне число хороших пакетів, отриманих за мультівещательнимі адресою.<br /> <br /> *''etherStatsCRCAlign Errors'' - загальне число отриманих пакетів, які мали довжину (виключаючи заголовок) між 64 і 1518 байт, не містили ціле число байт (alignment error) або мали невірну контрольну суму (FCS error).<br /> <br /> *''etherStatsUndersizePkts'' - загальне число пакетів, які мали довжину менше, ніж 64 байт, але були правильно сформовані.<br /> <br /> *''etherStatsOversizePkts'' - загальне число отриманих пакетів, які мали довжину більше, ніж 1518 байт, але були тим не менш правильно сформовані.<br /> <br /> *''etherStatsFragments'' - загальне число отриманих пакетів, які не складалися з цілого числа байт або мали невірну контрольну суму і мали до того ж довжину, меншу 64 байт.<br /> <br /> *''etherStatsJabbers'' - загальне число отриманих пакетів, які не складалися з цілого числа байт або мали невірну контрольну суму і мали до того ж довжину, більшу 1518 байт.<br /> <br /> *''etherStatsCollisions'' - найкраща оцінка числа колізій на даному сегменті Ethernet.<br /> <br /> *''etherStatsPkts640ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром 64 байт.<br /> <br /> *''etherStatsPkts65to1270ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 65 до 127 байт.<br /> <br /> *''etherStatsPktsl28to2550ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 128 до 255 байт.<br /> <br /> *''etherStatsPkts256to5110ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 256 до 511 байт.<br /> <br /> *''etherStatsPkts512tol0230ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 512 до 1023 байт.<br /> <br /> *''etherStatsPktsl024tol5180ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 1024 до 1518 байт.<br /> <br /> Як видно з опису об'єктів, за допомогою агента RMON, вбудованого в повторювач або інше комунікаційне обладнання, можна провести дуже детальний аналіз роботи сегмента Ethernet або Fast Ethernet. Спочатку можна отримати дані про типи помилок в кадрах, що зустрічаються в сегменті, а потім доцільно зібрати за допомогою группи History залежності інтенсивності цих помилок від часу (в тому числі і прив'язавши їх до часу). Після аналізу тимчасових залежностей часто вже можна зробити деякі попередні висновки про джерело помилкових кадрів і на цій підставі сформулювати більш тонкі умови захоплення кадрів зі специфічними ознаками (задавши умови в групі Filter). Після цього можна провести ще більш детальний аналіз за рахунок вивчення захоплених кадрів, витягуючи їх з об'єктів группи Packet Capture.<br /> <br /> Пізніше був прийнятий стандарт RMON 2, який поширює ідеї інтелектуальної RMON MIB на протоколи верхніх рівнів, виконуючи частину роботи аналізаторів протоколів.<br /> <br /> == Аналізатори протоколів ==<br /> <br /> У ході проектування нової або модернізації старої мережі часто виникає необхідність в кількісному вимірі деяких характеристик мережі таких, наприклад, як інтенсивності потоків даних по лініях зв'язку, затримки, що виникають на різних етапах обробки пакетів, часи реакції на запити того чи іншого виду, частота виникнення певних подій та інших характеристик.<br /> <br /> Для цих цілей можуть бути використані різні засоби і насамперед - засоби моніторингу в системах управління мережею, які вже обговорювалися в попередніх розділах. Деякі вимірювання мережі можуть бути виконані і вбудованими в операційну систему програмами.<br /> <br /> Але найбільш досконалим засобом дослідження мережі є аналізатор протоколів. Процес аналізу протоколів включає захоплення циркулюючих в мережі пакетів, що реалізують той чи інший мережевий протокол, і вивчення вмісту цих пакетів. Ґрунтуючись на результатах аналізу, можна здійснювати обґрунтовану і зважену зміну будь-якого компонента мережі, оптимізацію її продуктивності, пошук і усунення неполадок. Очевидно, що для того, щоб можна було зробити якісь висновки про вплив деякої зміни на мережу, необхідно виконати аналіз протоколів і до, і після внесення змін.<br /> <br /> Аналізатор протоколів є самостійним спеціалізованим пристроєм, або персональним комп'ютером, зазвичай переносним, класу Notebook, оснащений спеціальною мережевою картою і відповідним програмним забезпеченням. Мережева карта і програмне забезпечення, що використовуються повинні відповідати топології мережі (кільце, шина, зірка). Аналізатор підключається до мережі точно так, як і звичайний вузол. Відмінність полягає в тому, що аналізатор може приймати всі пакети даних, що передаються по мережі, в той час як звичайна станція - лише адресовані їй. Програмне забезпечення аналізатора складається з ядра, що підтримує роботу мережевого адаптера і декодує одержувані дані, та додаткового програмного коду, що залежить від типу топології досліджуваної мережі. Крім того, поставляється ряд процедур декодування, орієнтованих на певний протокол, наприклад, IPX. До складу деяких аналізаторів може входити також експертна система, яка може видавати користувачеві рекомендації про те, які експерименти слід проводити в даній ситуації, що можуть означати ті чи інші результати вимірювань, як усунути деякі види несправності мережі.<br /> <br /> Незважаючи на відносне різноманіття аналізаторів протоколів, представлених на ринку, можна назвати деякі риси, в тій чи іншій мірі притаманні всім їм:<br /> <br /> *''Інтерфейс користувача''. Більшість аналізаторів мають розвинений дружній інтерфейс, який базується, як правило, на Windows чи Motif. Цей інтерфейс дозволяє користувачеві: виводити результати аналізу інтенсивності трафіку; отримувати миттєву і середню статистичну оцінку продуктивності мережі; задавати певні події і критичні ситуації для відстежування їх виникнення; робити декодування протоколів різного рівня і представляти в зрозумілій формі вміст пакетів.<br /> <br /> *''Буфер захоплення''. Буфери різних аналізаторів відрізняються за обсягом. Буфер може розташовуватися на мережевій карті, або для нього може бути відведено місце в оперативній пам'яті одного з комп'ютерів мережі. Якщо буфер розташований на мережевій карті, то управління ним здійснюється апаратно, і за рахунок цього швидкість введення підвищується. Однак це призводить до подорожчання аналізатора. У разі недостатньої продуктивності процедури захоплення, частина інформації буде губитися, і аналіз буде неможливий. Розмір буфера визначає можливості аналізу по більш або менш представницьким вибіркам даних, що захоплюються. Але яким би великим не був буфер захоплення, рано чи пізно він заповниться. У цьому випадку або припиняється захоплення, або заповнення починається з початку буфера.<br /> <br /> *Можливість ''вимірювання середньостатистичних показників трафіку в сегменті локальної мережі'', в якому встановлений мережевий адаптер аналізатора.<br /> <br /> *Вимірюється коефіцієнт використання сегменту, матриці перехресного трафіку вузлів, кількість хороших і поганих кадрів, що пройшли через сегмент.<br /> <br /> *Можливість роботи з декількома агентами, котрі поставляють захоплені пакети з різних сегментів локальної мережі. Ці агенти найчастіше взаємодіють з аналізатором протоколів за власним протоколом прикладного рівня.<br /> <br /> *''Фільтри''. Фільтри дозволяють керувати процесом захоплення даних, і, тим самим, дозволяють економити простір буфера. Залежно від значення певних полів пакета, заданих у вигляді умови фільтрації, пакет або ігнорується, або записується в буфер захоплення. Використання фільтрів значно прискорює і спрощує аналіз, оскільки виключає перегляд непотрібних в даний момент пакетів.<br /> <br /> *''Перемикачі'' - це деякі умови початку і припинення процесу захоплення даних з мережі, що задаються користувачем. Такими умовами можуть бути виконання ручних команд запуску і зупинки процесу захоплення, тривалість процесу захоплення, поява певних значень в кадрах даних. Перемикачі можуть використовуватися спільно з фільтрами, дозволяючи більш детально й тонко проводити аналіз, а також продуктивніше використовувати обмежений обсяг буфера захоплення.<br /> <br /> *''Пошук''. Деякі аналізатори протоколів дозволяють автоматизувати перегляд інформації, що знаходиться в буфері, і знаходити в ній дані по заданим критеріям. У той час, як фільтри перевіряють вхідний потік на предмет відповідності умовам фільтрації, функції пошуку застосовуються до вже накопичених в буфері даних.<br /> <br /> *''Багатоканальність''. Деякі аналізатори протоколів дозволяють проводити одночасний запис пакетів від декількох мережевих адаптерів, що зручно для зіставлення процесів, що відбуваються в різних сегментах мережі. Можливості аналізу проблем мережі на фізичному рівні у аналізаторів протоколів мінімальні, оскільки всю інформацію вони отримують від стандартних мережевих адаптерів. Тому вони передають і узагальнюють інформацію фізичного рівня, яку повідомляє їм мережевий адаптер, а вона багато в чому залежить від типу мережного адаптера. Деякі мережні адаптери повідомляють більш детальні дані про помилки кадрів та інтенсивності колізій в сегменті, а деякі взагалі не передають таку інформацію верхнім рівням протоколів, на яких працює аналізатор протоколів.<br /> <br /> Методологія проведення аналізу може бути представлена у вигляді наступних шести етапів:<br /> <br /> *Захоплення даних.<br /> <br /> *Перегляд захоплених даних.<br /> <br /> *Аналіз даних.<br /> <br /> *Пошук помилок (більшість аналізаторів полегшують цю роботу, визначаючи типи помилок і ідентифікуючи станцію, від якої прийшов пакет з помилкою).<br /> <br /> *Дослідження продуктивності. Розраховується коефіцієнт використання пропускної здатності мережі або середній час реакції на запит.<br /> <br /> *Докладне дослідження окремих ділянок мережі. Зміст цього етапу конкретизується в міру того, як проводиться аналіз.<br /> <br /> Зазвичай процес аналізу протоколів займає відносно небагато часу - 1-2 робочих дні.<br /> <br /> == Обладнання для діагностики та сертифікації кабельних систем ==<br /> <br /> До обладнання даного класу відносяться мережеві аналізатори, прилади для сертифікації кабелів, кабельні сканери і тестери. Перш, ніж перейти до більш докладного огляду цих пристроїв, наведемо деякі необхідні відомості про основні електромагнітні характеристики кабельних систем.<br /> <br /> === Основні електромагнітні характеристики кабельних систем ===<br /> <br /> Основними електричними характеристиками, що впливають на роботу кабелю, є: затухання, імпеданс (хвильовий опір), перехресні наводки двох кручених пар і рівень зовнішнього електромагнітного випромінювання.<br /> <br /> ''Перехресні наводки між витими парами або NearEndCrosstalk (NEXT)'' - являють собою результат інтерференції електромагнітних сигналів, що виникають у двох кручених парах. Один з кабелів крученої пари передає сигнал, а другий - приймає. При проходженні сигналу по одному з кабелів, наприклад, по тому, що передає, у кабелі, що приймає сигнал виникають перехресні наводки. Величина NEXT залежить від частоти переданого сигналу - чим вище величина NEXT, тим краще (для категорії 5 NEXT повинен бути не менше 27 Дб при частоті 100 Мгц, для кабелю категорії 3 на частоті 10 МГц NEXT повинен бути не менше 26 Дб).<br /> <br /> ''Затухання (Attenuation)'' - являє собою втрату амплітуди електричного сигналу при його поширенні по кабелю. Затухання має два основних джерела: електричні характеристики кабелю і поверхневий ефект. Останній пояснює залежність затухання від частоти. Затухання вимірюється в децибелах на метр. Для кабелю категорії 5 при частоті 100 Мгц загасання не повинно перевищувати 23.6 Дб на 100 м, а для кабелю категорії 3, за стандартом IEEE 802.3 10BASE-T, допустима величина затухання на сегменті довжиною 100 м не повинна перевищувати 11,5 Дб при частоті змінного струму 10 МГц.<br /> <br /> ''Імпеданс (хвильовий опір)'' - це повний (активне і реактивне) опір в електричному ланцюзі. Імпеданс вимірюється в омах і є відносно постійною величиною для кабельних систем. Для неекранованої крученої пари найбільш часті значення імпедансу - 100 і 120 Ом. Характерні значення імпедансу для мереж стандарту Ethernet на коаксіальному кабелі становлять 50 Ом, а для мереж стандарту Arcnet - 93 Ом. Різкі зміни імпедансу по довжині кабелю можуть викликати процеси внутрішнього відображення, що призводять до виникнення стоячих хвиль. Стояча хвиля — тип коливань у неперервному середовищі, при яких кожна точка середовища здійснює періодичний рух зі сталою амплітудою, залежною від її положення. Стоячі хвилі не переносять енергію. Робоча станція, підключена до кабелю у районі вузла стоячої хвилі, не зможе отримувати адресовані їй повідомлення.<br /> <br /> ''Активний опір'' - це опір постійному струму в електричному ланцюзі. На відміну від імпедансу активний опір не залежить від частоти і зростає зі збільшенням довжини кабелю. Для неекранованої крученої пари категорії 5 активний опір не повинен перевищувати 9.4 Ом на 100 м.<br /> <br /> ''Ємність'' - це властивість металевих провідників накопичувати енергію. Два електричних провідника в кабелі, розділені діелектриком, являють собою конденсатор, здатний накопичувати заряд. Ємність є небажаною величиною, тому її слід робити якомога менше. Високе значення ємності в кабелі приводить до спотворення сигналу і обмежує смугу пропускання лінії. Для кабельних систем категорії 5 значення ємності не повинен перевищувати 5.6нФ на 100 м.<br /> <br /> ''Рівень зовнішнього електромагнітного випромінювання, або електричний шум'' - це небажана зміна напруги в провіднику. Електричний шум буває двох типів: фоновий і імпульсний. Електричний шум можна також розділити на низько-, середньо-і високочастотний. Джерелами фонового електричного шуму є в діапазоні до 150 КГц лінії електропередачі, телефони і лампи денного світла; в діапазоні від 150 КГц до 20 Мгц комп'ютери, принтери, ксерокси; в діапазоні від 20 МГц до 1 ГГц – теле- і радіопередавачі, мікрохвильові печі. Основними джерелами імпульсного електричного шуму є мотори, перемикачі і зварювальні агрегати. Електричний шум вимірюється в мВ. Кабельні системи на крученій парі не сильно схильні до впливу електричного шуму (на відміну від впливу NEXT).<br /> <br /> ===Мережеві аналізатори===<br /> <br /> Мережеві аналізатори (не слід плутати їх з аналізаторами протоколів) являють собою еталонні вимірювальні інструменти для діагностики та сертифікації кабелів і кабельних систем. Як приклад можна привести мережеві аналізатори компанії HewlettPackard - HP 4195A і HP 8510C.<br /> Мережеві аналізатори містять високоточний частотний генератор і вузькосмуговий приймач. Передаючи сигнали різних частот в передавальну пару і вимірюючи сигнал у приймальній парі, можна виміряти затухання і NEXT. Мережеві аналізатори - це великогабаритні і дорогі прилади, призначені для використання в лабораторних умовах спеціально навченим технічним персоналом.<br /> <br /> ===Кабельні сканери===<br /> <br /> Дані прилади дозволяють визначити довжину кабелю, NEXT, затухання, імпеданс, схему розводки, рівень електричних шумів і провести оцінку отриманих результатів. Існує досить багато пристроїв даного класу, наприклад, сканери компаній MicrotestInc., FlukeCorp., DatacomTechnologiesInc., ScopeCommunicationInc. На відміну від мережевих аналізаторів сканери можуть бути використані не тільки спеціально навченим технічним персоналом, але навіть адміністраторами-новачками.<br /> <br /> Для визначення місця розташування несправності кабельної системи (обриву, короткого замикання, неправильно встановленого роз'єму і т.д.) використовується метод &quot;кабельного радара&quot;, або TimeDomainReflectometry (TDR). Суть цього методу полягає в тому, що сканер випромінює в кабель короткий електричний імпульс і вимірює час затримки до приходу відбитого сигналу. За полярності відображеного імпульсу визначається характер пошкодження кабелю (коротке замикання або обрив). У правильно встановленому і підключеному кабелі відбитий імпульс зовсім відсутній.<br /> <br /> Точність вимірювання відстані залежить від того, наскільки точно відома швидкість розповсюдження електромагнітних хвиль у кабелі. У різних кабелях вона буде різною. Швидкість розповсюдження електромагнітних хвиль у кабелі (NVP) зазвичай задається у відсотках до швидкості світла у вакуумі. Сучасні сканери містять в собі електронну таблицю даних про NVP для всіх основних типів кабелів і дозволяють користувачеві встановлювати ці параметри самостійно після попереднього калібрування.<br /> <br /> Найбільш відомими виробниками компактних кабельних сканерів є компанії MicrotestInc., WaveTekCorp., ScopeCommunicationInc.<br /> <br /> ===Тестери===<br /> <br /> Тестери кабельних систем - найбільш прості і дешеві прилади для діагностики кабелю. Вони дозволяють визначити пошкодження кабеля, проте, на відміну від кабельних сканерів, не дають відповіді на питання про те, в якому місці стався збій.<br /> <br /> <br /> Перейти до [[Засоби аналізу та оптимізації мереж]]<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%9E%D0%B1%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%B5%D0%BD%D0%BD%D1%8F:%D0%A2%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D1%96%D1%8F_CDMA 2011-12-19T11:27:27Z

<p>Aleksey: </p> <hr /> <div>== Пропозиції та зауваження, щото викладеного матеріалу. ==<br /> <br /> ----<br /> <br /> == Потреба в доповненні ==<br /> <br /> Не акцентовано увагу на кодуванні данних та форматах повідомлень. Бажано доповнити.<br /> <br /> --[[User:V kotyak|V kotyak]] 13:08, 9 декабря 2008 (EET)<br /> <br /> Найближчим часом стаття буде доповненна!<br /> <br /> --[[User:Mnagorniy|Mnagorniy]] 11:46, 24 декабря 2008 (EET)<br /> <br /> <br /> <br /> == Потреба в доповненні ==<br /> <br /> Бажано також вказати на особливості налагодження підключення в ОС Windows<br /> <br /> --[[User:V kotyak|V kotyak]] 13:08, 9 декабря 2008 (EET)<br /> <br /> Налагодження підключення відбувається аналогічно звичайному підключенню!<br /> <br /> ----[[User:Mnagorniy|Mnagorniy]] 11:44, 24 декабря 2008 (EET)<br /> <br /> ----<br /> <br /> <br /> == Потрбно пояснити ==<br /> <br /> &quot;згортальне кодування &quot;вниз&quot; із швидкістю 1/2, &quot;вгору&quot; - 1/3,&quot;<br /> Необхідно пояснити суть кодування<br /> <br /> --[[User:V kotyak|V kotyak]] 13:08, 9 декабря 2008 (EET)<br /> <br /> Дякую за коментар, поясню!<br /> <br /> --[[User:Mnagorniy|Mnagorniy]] 11:46, 24 декабря 2008 (EET)<br /> <br /> &quot;Чи існують на сьогодні проблеми із зоною покриття CDMA?&quot;<br /> --[[Користувач:Піменова Олена|Піменова Олена]] 10:47, 15 грудня 2011 (EET)<br /> <br /> == Відгуки ==<br /> &quot;Чи існують на сьогодні проблеми із зоною покриття CDMA?&quot;<br /> &quot;Відповідь на питання знаходиться під №11 в пункті змісту&quot;<br /> --[[Користувач:Sergpsw|Sergpsw]] 10:54, 15 грудня 2011 (EET)<br /> <br /> &quot;Яка стійкість звя'язку CDMA?&quot;<br /> &quot;Відповідь на питання знаходиться під №10 в пункті змісту&quot;<br /> --[[Користувач:Sergpsw|Sergpsw]] 11:00, 15 грудня 2011 (EET)<br /> <br /> Щодо підключення інтернету в Linux через технологію CDMA то інформація дуже доречна!!! Все підключилося з першого разу!! Дякую за статтю!!!<br /> <br /> --[[User:Dpirogowsky|Dpirogowsky]] 12:00, 24 декабря 2008 (EET)<br /> <br /> Дійсно, в мене модем Novatel U720, щоб підключити інтернет в лінуксі, я перечитала багато статтей, та була на багатьох форумах, все що я робила, нічого не дало. Коли я скористалася даною статтею, то все запрацювало з першого разу!!!!<br /> <br /> '''ВЕЛИКЕ ДЯКУЮ ЗА ТАКУ КОРИСНУ ІНФОРМАЦІЮ!!!!!'''<br /> <br /> --[[User:Kozirna|Kozirna]] 12:04, 24 декабря 2008 (EET)<br /> -Допоможи-<br /> <br /> ----<br /> --[[Користувач:VetalQ|VetalQ]] 23:51, 20 січня 2010 (UTC)<br /> Стаття супер.Респект и уважуха.<br /> Допоможи для '''PANTECH UM150''' в Linux підключення таке саме як для модему Novatel U720?<br /> <br /> Статья интересная, но портит один фактор. &lt;br&gt;<br /> Статья написана на одной странице - и за раз очень туго воспринимается вся информация.&lt;br&gt;<br /> просьба разбить статью на несколько более мелких статтей для более легкого восприятия&lt;br&gt;<br /> --[[Користувач:Онищенко Сергей|Godrik]] 18:10, 28 грудня 2010 (EET)<br /> <br /> --[[Користувач:Лера Тирон|Лера Тирон]] 15:55, 18 грудня 2011 (UTC)<br /> Дякую за інформацію про Створення Мережевих підключень та підключення кабелю передачі даних.<br /> <br /> <br /> Чи є ще недоліки у CDMA, окрім проблеми близької-далекої зони? --[[Користувач:Aleksey|Новіков Олексій]] 13:27, 19 грудня 2011 (EET)</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%9E%D0%B1%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%B5%D0%BD%D0%BD%D1%8F:%D0%91%D0%B5%D0%B7%D0%BF%D0%B5%D0%BA%D0%B0_%D0%BA%D0%BE%D0%BC%D0%BF%27%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D0%B8%D1%85_%D0%BC%D0%B5%D1%80%D0%B5%D0%B6 2011-12-19T11:12:26Z

<p>Aleksey: </p> <hr /> <div>&quot;Чи необхідно вмикати брандмауер Windows, якщо є маршрутизатор із вбудованим брандмауером?&quot;<br /> --[[Користувач:Sergpsw|Sergpsw]] 10:58, 15 грудня 2011 (EET)<br /> <br /> Так, оскільки маршрутизатори із вбудованими брандмауерами надають захист від загроз, що надходять з інших комп’ютерів в Інтернеті, проте не захищають у домашній мережі. Наприклад, якщо портативний або гостьовий комп’ютер, заражений вірусом під час підключення до іншої мережі, підключити до вашої домашньої мережі, маршрутизатор із вбудованим брандмауером не зможе запобігти розповсюдженню хробака. Однак запуск брандмауера на всіх комп’ютерах у мережі може допомогти контролювати процес розповсюдження вірусів.<br /> --[[Користувач:Піменова Олена|Піменова Олена]] 11:08, 15 грудня 2011 (EET)<br /> <br /> Після аутентифікації наступним єтапом є авторизація. Хотілося б докладно почитати про процедуру авторизації. --[[Користувач:Aleksey|Новіков Олексій]] 13:12, 19 грудня 2011 (EET)</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%9E%D0%B1%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%B5%D0%BD%D0%BD%D1%8F:DNS_%D1%82%D0%B0_DHCP_%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0 2011-12-19T10:26:24Z

<p>Aleksey: </p> <hr /> <div>http://kunegin.narod.ru/ref3/dns/format.htm<br /> <br /> Який термін оренди IP-адреси?<br /> --[[Користувач:Sergpsw|Sergpsw]] 12:00, 16 грудня 2011 (EET)<br /> <br /> Надпис '''DHCP''' якось загубився серед всього різноманіття тексту.<br /> На мою думку спочатку треба було зробити зміст чи поставити 1, 2, ...<br /> <br /> --[[Користувач:Куделькін Влад|Куделькін Влад]] 12:16, 24 грудня 2010 (EET)<br /> &lt;br&gt;<br /> на мою думку, спочатку потрібно дати означення DNS , а потім все інше, історія... ір адреси...&lt;br&gt;<br /> --[[Користувач:kolbka|kolbka]] 12:30, 24 грудня 2010 (EET)<br /> <br /> Є достатньо корисної інформації, однак таблицю в пункті Структура повідомлень DHCP було б непогано краще оформити, щоб інформація не зливалась. <br /> --[[Користувач:Лера Тирон|Лера Тирон]] 16:12, 18 грудня 2011 (EET)<br /> <br /> Хотілося б почитати про схему роботи DNS.<br /> --[[Користувач:Aleksey|Новіков Олексій]] 12:26, 19 грудня 2011 (EET)</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%9E%D0%B1%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%B5%D0%BD%D0%BD%D1%8F:DNS_%D1%82%D0%B0_DHCP_%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0 2011-12-19T10:23:57Z

<p>Aleksey: </p> <hr /> <div>http://kunegin.narod.ru/ref3/dns/format.htm<br /> <br /> Який термін оренди IP-адреси?<br /> --[[Користувач:Sergpsw|Sergpsw]] 12:00, 16 грудня 2011 (EET)<br /> <br /> Надпис '''DHCP''' якось загубився серед всього різноманіття тексту.<br /> На мою думку спочатку треба було зробити зміст чи поставити 1, 2, ...<br /> <br /> --[[Користувач:Куделькін Влад|Куделькін Влад]] 12:16, 24 грудня 2010 (EET)<br /> &lt;br&gt;<br /> на мою думку, спочатку потрібно дати означення DNS , а потім все інше, історія... ір адреси...&lt;br&gt;<br /> --[[Користувач:kolbka|kolbka]] 12:30, 24 грудня 2010 (EET)<br /> <br /> Є достатньо корисної інформації, однак таблицю в пункті Структура повідомлень DHCP було б непогано краще оформити, щоб інформація не зливалась. <br /> --[[Користувач:Лера Тирон|Лера Тирон]] 16:12, 18 грудня 2011 (EET)<br /> <br /> Хотілося б почитати про схему роботи DNS.</div>

Aleksey https://wiki.cusu.edu.ua/index.php/RIP 2011-12-19T09:51:20Z

<p>Aleksey: </p> <hr /> <div>==Загальні відомості==<br /> <br /> Протокол RIP (Routing Information Protocol) є внутрішнім протоколом маршрутизації дистанційно-векторного типу, він являє собою один з найбільш ранніх протоколів обміну маршрутною інформацією і досі надзвичайно поширений в обчислювальних мережах зважаючи на простоту реалізації. Окрім версії RIP для мереж [[TCP/IP]] існує також версія RIP для мереж [[IPX/SPX]] компанії Novell.<br /> <br /> Для IP є дві версії протоколу RIP: перша і друга. Протокол RIPvl не підтримує масок, тобто він поширює між маршрутизаторами тільки інформацію про номери мереж і відстанях до них, а інформацію про маски цих мереж не поширює, вважаючи, що всі адреси належать до стандартних класів А, В або С. Протокол RIPv2 передає інформацію про маски мереж, тому він більшою мірою відповідає вимогам сьогодення. Так як при побудові таблиць маршрутизації робота версії 2 принципово не відрізняється від версії 1, то в подальшому для спрощення записів буде описуватися робота першої версії.<br /> <br /> ==Побудова таблиці маршрутизації==<br /> <br /> В якості відстані до мережі стандарти протоколу RIP допускають різні види метрик: хопи, метрики, що враховують пропускну здатність, затримки і надійність мереж (тобто відповідні ознаками D, Т і R в поле «Якість сервісу» IP-пакета), а також будь-які комбінації цих метрик. Метрика повинна мати властивість адитивності - метрика складового шляху повинна дорівнювати сумі метрик складових цього шляху. У більшості реалізації RIP використовується найпростіша метрика - кількість хопов, тобто кількість проміжних маршрутизаторів, які потрібно подолати пакету до мережі призначення.<br /> <br /> Розглянемо процес побудови таблиці маршрутизації за допомогою протоколу RIP на прикладі складеної мережі, зображеної на мал.1.<br /> <br /> [[Файл: Rip1.jpg]]<br /> <br /> Мал. 1. Мережа побудована на маршрутизаторах RIP.<br /> <br /> '''Етап 1 - створення мінімальних таблиць'''. У цій мережі є вісім IP-мереж, пов'язаних чотирма маршрутизаторами з ідентифікаторами: Ml, М2, МЗ і М4. Маршрутизатори, що працюють по протоколу RIP, можуть мати ідентифікатори, проте для роботи протоколу вони не є необхідними. У RIP-повідомленнях ці ідентифікатори не передаються.<br /> <br /> У вихідному стані в кожному маршрутизаторі програмним забезпеченням стека [[TCP/IP]] автоматично створюється мінімальна таблиця маршрутизації, в якій враховуються тільки безпосередньо приєднані мережі. На малюнку адреси портів маршрутизаторів на відміну від адрес мереж поміщені в овали.<br /> <br /> Таблиця 1 дозволяє оцінити приблизний вигляд мінімальної таблиці маршрутизації маршрутизатора Ml.<br /> <br /> '''Таблиця 1'''. Мінімальна таблиця маршрутизації маршрутизатора Ml<br /> <br /> [[Файл:Rip2.jpg]]<br /> <br /> Мінімальні таблиці маршрутизації в інших маршрутизаторах будуть виглядати відповідно, наприклад, таблиця маршрутизатора М2 буде складатися з трьох записів (табл. 2).<br /> <br /> '''Таблиця 2'''. Мінімальна таблиця маршрутизації маршрутизатора М2<br /> <br /> [[Файл:Rip3.jpg]]<br /> <br /> '''Етап 2 - розсилка мінімальних таблиць сусідам'''. Після ініціалізації кожного маршрутизатора він починає посилати своїм сусідам повідомлення протоколу RIP, в яких міститься його мінімальна таблиця.<br /> <br /> RIP-повідомлення передаються в пакетах протоколу UDP і включають два параметри для кожної мережі: її IP-адресу та відстань до неї від маршрутизатора, що передає повідомлення.<br /> <br /> Сусідами є ті маршрутизатори, яким даний маршрутизатор безпосередньо може передати IP-пакет з якої-небудь своєї мережі, не користуючись послугами проміжних маршрутизаторів. Наприклад, для маршрутизатора Ml сусідами є маршрутизатори М2 і МЗ, а для маршрутизатора М4 - маршрутизатори М2 і МЗ.<br /> <br /> Таким чином, маршрутизатор Ml передає маршрутизатору М2 і МЗ таке повідомлення:<br /> <br /> *мережа 201.36.14.0, відстань 1;<br /> <br /> *мережа 132.11.0.0, відстань 1;<br /> <br /> *мережа 194.27.18.0, відстань 1.<br /> <br /> '''Етап 3 - отримання RIP-повідомлень від сусідів і обробка отриманої інформації'''.<br /> <br /> Після отримання аналогічних повідомлень від маршрутизаторів М2 і МЗ маршрутизатор Ml нарощує кожне отримане поле метрики на одиницю і запам'ятовує, через який порт і від якого маршрутизатора отримана нова інформація (адреса цього маршрутизатора буде адресою наступного маршрутизатора, якщо цей запис буде внесено в таблицю маршрутизації). Потім маршрутизатор починає порівнювати нову інформацію з тією, яка зберігається в його таблиці маршрутизації (табл. 3).<br /> <br /> '''Таблиця 3'''. Таблиця маршрутизації маршрутизатора M1<br /> <br /> [[Файл:Rip4.jpg]]<br /> <br /> Записи з четвертої по дев'ятий отримані від сусідніх маршрутизаторів, і вони претендують на занесення в таблицю. Однак лише записи з четвертої по сьому потрапляють в таблицю, а записи восьма і дев'ята - ні. Це відбувається тому, що вони містять дані про вже наявні в таблиці Ml мережах, а відстань до них гірша, ніж в існуючих записах.<br /> <br /> Протокол RIP заміщає запис про будь-яку мережу тільки в тому випадку, якщо нова інформація має кращу метрику (відстань в хопах менше), ніж наявна. У результаті в таблиці маршрутизації про кожну мережі залишається тільки один запис, а якщо є декілька рівнозначних щодо відстані шляхів до однієї і тієї ж мережі, то все одно в таблиці залишається один запис, який прийшов в маршрутизатор першим. Для цього правила існує виняток - якщо найгірша інформація про будь-якої мережі прийшла від того ж маршрутизатора, на підставі повідомлення якого був створений цей запис, то найгірша інформація заміщає кращу.<br /> <br /> Аналогічні операції з новою інформацією виконують і інші маршрутизатори мережі.<br /> <br /> '''Етап 4 - розсилка нової, вже не мінімальної, таблиці сусідам'''. Кожен маршрутизатор відсилає нове RIP-повідомлення всім своїм сусідам. У цьому повідомленні він поміщає дані про всі відомі йому мережі - як безпосередньо підключених, так і віддалених, про які маршрутизатор дізнався з RIP-повідомлень.<br /> <br /> '''Етап 5 - отримання RIP-повідомлень від сусідів і обробка отриманої інформації'''. Етап 5 повторює етап 3 - маршрутизатори приймають RIP-повідомлення, обробляють записи що містяться в них і коректують свої таблиці маршрутизації.<br /> <br /> Подивимося, як це робить маршрутизатор Ml (табл. 4).<br /> <br /> '''Таблиця 4'''. Таблиця маршрутизації маршрутизатора M1.<br /> <br /> [[Файл:Rip5.jpg]]<br /> <br /> На цьому етапі маршрутизатор Ml отримав від маршрутизатора М3 інформацію про мережу 132.15.0.0, яку той у свою чергу на попередньому циклі роботи отримав від маршрутизатора М4. Маршрутизатор вже знає про мережу 132.15.0.0, причому стара інформація має кращу метрику, ніж нова, тому нова інформація про цю мережі відкидається.<br /> <br /> Про мережу 202.101.16.0 маршрутизатор Ml дізнається на цьому етапі вперше, причому дані про неї приходять від двох сусідів - від МЗ і М4. Оскільки метрики в цих повідомленнях вказані однакові, то в таблицю потрапляють дані, які прийшли першими. У нашому прикладі вважається, що маршрутизатор М2 випередив маршрутизатор МЗ і першим переслав своє RIP-повідомлення маршрутизатору Ml.<br /> <br /> Якщо маршрутизатори періодично повторюють етапи розсилки та обробки RIP-повідомлень, то за кінцевий час в мережі встановиться коректний режим маршрутизаціі. Під коректним режимом маршрутизації тут розуміється такий стан таблиць маршрутизації, коли всі мережі будуть досяжні з будь-якої мережі за допомогою деякого раціонального маршруту. Пакети будуть доходити до адресатів і не зациклюватися в петлях, подібних до тієї, яка утворюється на мал. 1, маршрутизаторами М1-М2-МЗ-М4.<br /> <br /> Очевидно, якщо в мережі всі маршрутизатори, їх інтерфейси і канали зв'язку, що з'єднують їх постійно працездатні, то оголошення по протоколу RIP можна робити досить рідко, наприклад, один раз на день. Проте в мережах постійно відбуваються зміни - змінюється як працездатність маршрутизаторів і каналів, так і самі маршрутизатори і канали можуть додаватися в існуючу мережу або ж виводитися з її складу.<br /> <br /> Для адаптації до змін у мережі протокол RIP використовує ряд механізмів.<br /> <br /> ==Адаптація RIP-маршрутизаторів до змін стану мережі==<br /> <br /> До нових маршрутів RIP-маршрутизатори пристосовуються просто - вони передають нову інформацію в черговому повідомленні своїм сусідам і поступово ця інформація стає відома всім маршрутизаторам мережі. А ось до негативних змін, пов'язаних з втратою будь-якого маршруту, RIP-маршрутізатори пристосовуються складніше. Це пов'язано з тим, що у форматі повідомлень протоколу RIP немає поля, яке б вказувало на те, що шлях до цієї мережі більше не існує.<br /> <br /> Замість цього використовуються два механізми повідомлення про те, що деякий маршрут більш недійсний:<br /> <br /> *закінчення часу життя маршруту;<br /> <br /> *вказівка ​​спеціальної відстані (нескінченної) до мережі, що стала недоступною.<br /> <br /> Для відпрацювання першого механізму кожен запис таблиці маршрутизації (як і записи таблиці просування моста/комутатора), отримана за протоколом RIP, має час життя (TTL). При надходженні чергового RIP-повідомлення, яке підтверджує справедливість даного запису, таймер TTL встановлюється в початковий стан, а потім з нього кожну секунду віднімається одиниця. Якщо за час тайм-ауту не прийде нове маршрутне повідомлення про цей маршрут, то він позначається як недійсний.<br /> <br /> Час тайм-ауту пов'язаний з періодом розсилки векторів по мережі. У RIP IP період розсилки рівний 30 секундам, а в якості тайм-ауту вибрано шестиразове значення періоду розсилки, тобто 180 секунд. Вибір досить малого часу періоду розсилки пояснюється декількома причинами. Шестиразовий запас часу потрібний для впевненості в тому, що мережа дійсно стала недоступна, а не просто відбулися втрати RIP-повідомлень (а це можливо, оскільки RIP використовує транспортний протокол UDP, який не забезпечує надійної доставки повідомлень).<br /> <br /> Якщо який-небудь маршрутизатор відмовляє і перестає слати своїм сусідам повідомлення про мережі, які можна досягти через нього, то через 180 секунд всі записи, які породив цей маршрутизатор, стануть недійсними у його найближчих сусідів. Після цього процес повториться вже для сусідів найближчих сусідів - вони викреслять подібні записи вже через 360 секунд, тому що перші 180 секунд найближчі сусіди ще передавали повідомлення про ці записи.<br /> <br /> Як видно з пояснення, відомості про недоступні мережі через маршрутизатор, що відмовив поширюються по мережі не дуже швидко, час поширення кратний часу життя запису, а коефіцієнт кратності дорівнює кількості хопов між самими далекими маршрутизаторами мережі. У цьому полягає одна з причин вибору періоду розсилки в 30 секунд.<br /> <br /> Якщо відмовляють не маршрутизатор, а інтерфейс або мережу, що зв'язують його з яким-небудь сусідом, то ситуація зводиться до щойно описаної - знову починає працювати механізм тайм-ауту і маршрути, стали недійсними поступово будуть викреслені з таблиць всіх маршрутизаторів мережі.<br /> <br /> Тайм-аут працює в тих випадках, коли маршрутизатор не може послати сусідам повідомлення про маршрути, що відмовили, тому що або він сам непрацездатний, або непрацездатна лінія зв'язку, по якій можна було б передати повідомлення.<br /> <br /> Коли ж повідомлення послати можна, RIP-маршрутизатори не використовують спеціальної ознаки в повідомленнях, а вказують нескінченну відстань до мережі, причому в протоколі RIP воно вибрано рівним 16 хопам (при іншій метриці необхідно вказати маршрутизатору її значення, що вважається нескінченністю). Отримавши повідомлення, в якому деяка мережу супроводжується відстанню 16 (або 15, що призводить до того ж результату, так як маршрутизатор нарощує отримане значення на 1), маршрутизатор повинен перевірити, надходить ця «погана» інформація про мережу від того ж маршрутизатора, повідомлення якого послужило свого часу підставою для запису про дану мережу в таблиці маршрутизації. Якщо це той же маршрутизатор, то інформація вважається достовірною і маршрут позначається як недоступний.<br /> <br /> Таке невелике значення «нескінченної» відстані викликано тим, що в деяких випадках відмови зв'язків у мережі викликають тривалі періоди некоректної роботи RIP-маршрутизаторів, що виражається в зацикленні пакетів у петлях мережі. І чим менше відстань, що використовується як «нескінченна», тим такі періоди стають коротшими.<br /> <br /> ==Приклад зациклювання пакетів==<br /> <br /> Розглянемо випадок зациклювання пакетів на прикладі мережі, зображеної на рис. 1.<br /> <br /> Нехай маршрутизатор Ml виявив, що його зв'язок з безпосередньо підключеною мережею 201.36.14.0 втрачена (наприклад, з причини відмови інтерфейсу 201.36.14.3). Ml зазначив у своїй таблиці маршрутизації, що мережа 201.36.14.0 недоступна. У гіршому випадку він виявив це відразу ж після відправлення чергових RIP-повідомлень, так що до початку нового циклу його оголошень, в якому він повинен повідомити сусідам, що відстань до мережі 201.36.14.0 стало рівним 16, залишається майже 30 секунд.<br /> <br /> Кожен маршрутизатор працює на підставі свого внутрішнього таймера, не синхронізуючи роботу по розсилці оголошень з іншими маршрутизаторами. Тому дуже ймовірно, маршрутизатор М2 випередив маршрутизатор Ml і передав йому своє повідомлення раніше, ніж Ml встиг передати новину про недосяжність мережі 201.36.14.0. А в цьому повідомленні є дані, що породжені наступним записом в таблиці маршрутизації М2 (табл. 5).<br /> <br /> Таблиця 5. Таблиця маршрутизації маршрутизатора М2.<br /> <br /> [[Файл:Rip6.gif]]<br /> <br /> Цей запис був отриманий від маршрутизатора Ml і коректна до відмови інтерфейсу 201.36.14.3, а тепер вона застаріла, але маршрутизатор М2 про це не дізнався.<br /> <br /> Тепер маршрутизатор Ml отримав нову інформацію про мережу 201.36.14.0 - ця мережа досяжна через маршрутизатор М2 з метрикою 2. Раніше Ml також отримував цю інформацію від М2. Але ігнорував її, так як його власна метрика для 201.36.14.0 була краща. Тепер Ml повинен прийняти дані про мережу 201.36.14.0, отримані від М2, і замінити запис в таблиці маршрутизації про недосяжність цієї мережі (табл. 6).<br /> <br /> Таблиця 6. Таблиця маршрутизації маршрутизатора М1.<br /> <br /> [[Файл:Rip7.gif]]<br /> <br /> У результаті в мережі утворилася маршрутна петля: пакети, що направляються вузлам мережі 201.36.14.0, будуть передаватися маршрутизатором М2 маршрутизатору Ml, а маршрутизатор Ml буде повертати їх маршрутизатору М2. IP-пакети будуть циркулювати по цій петлі до тих пір, поки не закінчиться час життя кожного пакета.<br /> <br /> Маршрутна петля буде існувати в мережі досить довго. Розглянемо періоди часу, кратні часу життя записів у таблицях маршрутизаторів.<br /> <br /> *Час 0-180 с. Після відмови інтерфейсу в маршрутизаторах Ml і М2 будуть зберігатися некоректні записи, наведені вище. Маршрутизатор М2 як і раніше постачає маршрутизатор Ml своїм записом про мережу 201.36.14.0 з метрикою 2, так як її час життя не закінчився. Пакети зациклюються.<br /> <br /> *Час 180-360 с. На початку цього періоду у маршрутизатора М2 закінчується час життя запису про мережу 201.36.14.0 з метрикою 2, так як маршрутизатор Ml в попередній період посилав йому повідомлення про мережу 201.36.14.0 з гіршого метрикою, ніж у М2, і вони не могли підтверджувати цей запис. Тепер маршрутизатор М2 приймає від маршрутизатора Ml запис про мережу 201.36.14.0 з метрикою 3 та трансформує її в запис з метрикою 4. Маршрутизатор Ml не отримує нових повідомлень від маршрутизатора М2 про мережу 201.36.14.0 з метрикою 2, тому час життя його запису починає зменшуватися. Пакети продовжують зациклюватися.<br /> <br /> *Час 360-540 с. Тепер у маршрутизатора Ml закінчується час життя запису про мережу 201.36.14.0 з метрикою 3. Маршрутизатори Ml і М2 знову міняються ролями - М2 постачає Ml застарілою інформацією про шлях до мережі 201.36.14.0, вже з метрикою 4, яку Ml перетворює в метрику 5. Пакети продовжують зациклюватися.<br /> <br /> Якщо б у протоколі RIP не було вибрано відстань 16 як недосяжна, то описаний процес тривав би до нескінченності (вірніше, поки не була б вичерпана розрядна сітка поля відстані і не було б зафіксовано переповнення при черговому нарощуванні відстані).<br /> <br /> У результаті маршрутизатор М2 на черговому етапі описаного процесу отримує від маршрутизатора Ml метрику 15, яка після нарощування, перетворюючись на метрику 16, фіксує недосяжність мережі. Період нестабільної роботи мережі тривав 36 хвилин!<br /> <br /> Обмеження в 15 хопов звужує сферу застосування протоколу RIP до мереж, в яких число проміжних маршрутизаторів не може бути більше 15. Для більш масштабних мереж потрібно застосовувати інші протоколи маршрутизації, наприклад OSPF, або розбивати мережу на автономні області.<br /> <br /> Наведений приклад добре ілюструє головну причину нестабільної роботи маршрутизаторів, що працюють по протоколу RIP. Ця причина полягає в самому принципі роботи дистанційно-векторних протоколів - користування інформацією, отриманою з других рук. Дійсно, маршрутизатор М2 передав маршрутизатору Ml інформацію про досяжності мережі 201.36.14.0, за достовірність якої він сам не відповідає. Викорінити цю причину повністю не можна, адже сам спосіб побудови таблиць маршрутизації пов'язаний з передачею чужої інформації без зазначення джерела її походження.<br /> <br /> Не слід думати, що при будь-яких відмовах інтерфейсів і маршрутизаторів в мережах виникають маршрутні петлі. Якби маршрутизатор Ml встиг передати повідомлення про недосяжність мережі 201.36.14.0 раніше неправдивої інформації маршрутизатора М2, то маршрутна петля не утворилася б. Так що маршрутні петлі навіть без додаткових методів боротьби з ними, описаними в наступному розділі, виникають в середньому не більш ніж у половині потенційно можливих випадків.<br /> <br /> ==Методи боротьби з помилковими маршрутами в протоколі RIP==<br /> <br /> Незважаючи на те що протокол RIP не в змозі повністю виключити перехідні стани в мережі, коли деякі маршрутизатори користуються застарілою інформацією про вже неіснуючі маршрути, є кілька методів, які в багатьох випадках вирішують подібні проблеми.<br /> <br /> Ситуація з петлею, що утворюється між сусідніми маршрутизаторами, описана в попередньому розділі, надійно вирішується за допомогою методу, який отримав назву розщеплення горизонту (split horizon). Метод полягає в тому, що маршрутна інформація про деяку мережу, що зберігається в таблиці маршрутизації, ніколи не передається тому маршрутизатора, від якого вона отримана (це наступний маршрутизатор в даному маршруті). Якщо маршрутизатор М2 в розглянутому вище прикладі підтримує техніку розщеплення горизонту, то він не передасть маршрутизатора Ml застарілу інформацію про мережу 201.36.14.0, оскільки отримав її саме від маршрутизатора Ml.<br /> <br /> Практично всі сьогоднішні маршрутизатори, що працюють по протоколу RIP, використовують техніку розщеплення горизонту.<br /> <br /> Однак розщеплення горизонту не допомагає в тих випадках, коли петлі утворюються не двома, а кількома маршрутизаторами. Розглянемо більш детально ситуацію, яка виникне в мережі, наведеною на рис. 1, у разі втрати зв'язку маршрутизатора 2 з мережею А. Нехай всі маршрутизатори цієї мережі підтримують техніку розщеплення горизонту. Маршрутизатори М2 і МЗ не повертатимуть маршрутизатора в цій ситуації дані про мережу 201.36.14.0 з метрикою 2, так як вони отримали цю інформацію від маршрутизатора Ml. Однак вони будуть передавати маршрутизатору інформацію про досяжності мережі 201.36.14.0 з метрикою 4 через себе, тому що отримали цю інформацію по складному маршруту, а не від маршрутизатора Ml безпосередньо. Наприклад, маршрутизатор М2 отримав цю інформацію по ланцюжку М4-МЗ-М1. Тому маршрутизатор Ml знову може бути обдуреним, поки кожен з маршрутизаторів в ланцюжку МЗ-М4-М2 не викреслить запис про досяжності мережі 1 (а це відбудеться через період 3 х 180 секунд).<br /> <br /> Для запобігання зациклення пакетів по складовим петлям при відмовах зв'язків застосовуються два інших прийоми, так звані тригерні оновлення (triggered updates) і заморожування змін (hold down).<br /> <br /> Спосіб тригерних оновлень полягає в тому, що маршрутизатор, отримавши дані про зміну метрики до будь-якої мережі, не чекає закінчення періоду передачі таблиці маршрутизації, а передає дані про зміну маршруту негайно. Цей прийом може в багатьох випадках запобігти передачі застарілих відомостей про маршрут, що відмовив, але він перевантажує мережу службовими повідомленнями, тому тригерні оголошення також робляться з деякою затримкою. Тому можлива ситуація, коли регулярне оновлення в будь-якому маршрутизаторі трохи випередить за часом прихід тригерніх оновлень від попереднього в ланцюжку маршрутизатора і даний маршрутизатор встигне передати по мережі застарілу інформацію про неіснуючий маршрут.<br /> <br /> Другий прийом дозволяє виключити подібні ситуації. Він пов'язаний з введенням тайм-ауту на прийняття нових даних про мережу, яка щойно стала недоступною. Цей тайм-аут запобігає прийняттю застарілих відомостей про деякий маршрут від тих маршрутизаторів, які знаходяться на деякій відстані від зв'язку, що відмовив та передають застарілі відомості про його працездатність. Передбачається, що протягом тайм-ауту «заморожування змін» ці маршрутизатори викреслять даний маршрут зі своїх таблиць, оскільки не отримають про нього нових записів і не поширюватимуть застарілі відомості по мережі.<br /> <br /> <br /> Матеріали взяті з: В. Г. Олифер, Н. А. Олифер. Компьютерные сети. Принципы, технологии, протоколы. Учебник для вузов. 2010</div>

Aleksey https://wiki.cusu.edu.ua/index.php/RIP 2011-12-18T23:55:01Z

<p>Aleksey: Створена сторінка: ==Загальні відомості== Протокол RIP (Routing Information Protocol) є внутрішнім протоколом маршрутизаці...</p> <hr /> <div>==Загальні відомості==<br /> <br /> Протокол RIP (Routing Information Protocol) є внутрішнім протоколом маршрутизації дистанційно-векторного типу, він являє собою один з найбільш ранніх протоколів обміну маршрутною інформацією і досі надзвичайно поширений в обчислювальних мережах зважаючи на простоту реалізації. Окрім версії RIP для мереж [[TCP/IP]] існує також версія RIP для мереж [[IPX/SPX]] компанії Novell.<br /> <br /> Для IP є дві версії протоколу RIP: перша і друга. Протокол RIPvl не підтримує масок, тобто він поширює між маршрутизаторами тільки інформацію про номери мереж і відстанях до них, а інформацію про маски цих мереж не поширює, вважаючи, що всі адреси належать до стандартних класів А, В або С. Протокол RIPv2 передає інформацію про маски мереж, тому він більшою мірою відповідає вимогам сьогодення. Так як при побудові таблиць маршрутизації робота версії 2 принципово не відрізняється від версії 1, то в подальшому для спрощення записів буде описуватися робота першої версії.<br /> <br /> ==Побудова таблиці маршрутизації==<br /> <br /> В якості відстані до мережі стандарти протоколу RIP допускають різні види метрик: хопи, метрики, що враховують пропускну здатність, затримки і надійність мереж (тобто відповідні ознаками D, Т і R в поле «Якість сервісу» IP-пакета), а також будь-які комбінації цих метрик. Метрика повинна мати властивість адитивності - метрика складового шляху повинна дорівнювати сумі метрик складових цього шляху. У більшості реалізації RIP використовується найпростіша метрика - кількість хопов, тобто кількість проміжних маршрутизаторів, які потрібно подолати пакету до мережі призначення.<br /> <br /> Розглянемо процес побудови таблиці маршрутизації за допомогою протоколу RIP на прикладі складеної мережі, зображеної на мал.1.<br /> <br /> [[Файл: Rip1.jpg]]<br /> <br /> Мал. 1. Мережа побудована на маршрутизаторах RIP.<br /> <br /> '''Етап 1 - створення мінімальних таблиць'''. У цій мережі є вісім IP-мереж, пов'язаних чотирма маршрутизаторами з ідентифікаторами: Ml, М2, МЗ і М4. Маршрутизатори, що працюють по протоколу RIP, можуть мати ідентифікатори, проте для роботи протоколу вони не є необхідними. У RIP-повідомленнях ці ідентифікатори не передаються.<br /> <br /> У вихідному стані в кожному маршрутизаторі програмним забезпеченням стека [[TCP/IP]] автоматично створюється мінімальна таблиця маршрутизації, в якій враховуються тільки безпосередньо приєднані мережі. На малюнку адреси портів маршрутизаторів на відміну від адрес мереж поміщені в овали.<br /> <br /> Таблиця 1 дозволяє оцінити приблизний вигляд мінімальної таблиці маршрутизації маршрутизатора Ml.<br /> <br /> '''Таблиця 1'''. Мінімальна таблиця маршрутизації маршрутизатора Ml<br /> <br /> [[Файл:Rip2.jpg]]<br /> <br /> Мінімальні таблиці маршрутизації в інших маршрутизаторах будуть виглядати відповідно, наприклад, таблиця маршрутизатора М2 буде складатися з трьох записів (табл. 2).<br /> <br /> '''Таблиця 2'''. Мінімальна таблиця маршрутизації маршрутизатора М2<br /> <br /> [[Файл:Rip3.jpg]]<br /> <br /> '''Етап 2 - розсилка мінімальних таблиць сусідам'''. Після ініціалізації кожного маршрутизатора він починає посилати своїм сусідам повідомлення протоколу RIP, в яких міститься його мінімальна таблиця.<br /> <br /> RIP-повідомлення передаються в пакетах протоколу UDP і включають два параметри для кожної мережі: її IP-адресу та відстань до неї від маршрутизатора, що передає повідомлення.<br /> <br /> Сусідами є ті маршрутизатори, яким даний маршрутизатор безпосередньо може передати IP-пакет з якої-небудь своєї мережі, не користуючись послугами проміжних маршрутизаторів. Наприклад, для маршрутизатора Ml сусідами є маршрутизатори М2 і МЗ, а для маршрутизатора М4 - маршрутизатори М2 і МЗ.<br /> <br /> Таким чином, маршрутизатор Ml передає маршрутизатору М2 і МЗ таке повідомлення:<br /> <br /> *мережа 201.36.14.0, відстань 1;<br /> <br /> *мережа 132.11.0.0, відстань 1;<br /> <br /> *мережа 194.27.18.0, відстань 1.<br /> <br /> '''Етап 3 - отримання RIP-повідомлень від сусідів і обробка отриманої інформації'''.<br /> <br /> Після отримання аналогічних повідомлень від маршрутизаторів М2 і МЗ маршрутизатор Ml нарощує кожне отримане поле метрики на одиницю і запам'ятовує, через який порт і від якого маршрутизатора отримана нова інформація (адреса цього маршрутизатора буде адресою наступного маршрутизатора, якщо цей запис буде внесено в таблицю маршрутизації). Потім маршрутизатор починає порівнювати нову інформацію з тією, яка зберігається в його таблиці маршрутизації (табл. 3).<br /> <br /> '''Таблиця 3'''. Таблиця маршрутизації маршрутизатора M1<br /> <br /> [[Файл:Rip4.jpg]]<br /> <br /> Записи з четвертої по дев'ятий отримані від сусідніх маршрутизаторів, і вони претендують на занесення в таблицю. Однак лише записи з четвертої по сьому потрапляють в таблицю, а записи восьма і дев'ята - ні. Це відбувається тому, що вони містять дані про вже наявні в таблиці Ml мережах, а відстань до них гірша, ніж в існуючих записах.<br /> <br /> Протокол RIP заміщає запис про будь-яку мережу тільки в тому випадку, якщо нова інформація має кращу метрику (відстань в хопах менше), ніж наявна. У результаті в таблиці маршрутизації про кожну мережі залишається тільки один запис, а якщо є декілька рівнозначних щодо відстані шляхів до однієї і тієї ж мережі, то все одно в таблиці залишається один запис, який прийшов в маршрутизатор першим. Для цього правила існує виняток - якщо найгірша інформація про будь-якої мережі прийшла від того ж маршрутизатора, на підставі повідомлення якого був створений цей запис, то найгірша інформація заміщає кращу.<br /> <br /> Аналогічні операції з новою інформацією виконують і інші маршрутизатори мережі.<br /> <br /> '''Етап 4 - розсилка нової, вже не мінімальної, таблиці сусідам'''. Кожен маршрутизатор відсилає нове RIP-повідомлення всім своїм сусідам. У цьому повідомленні він поміщає дані про всі відомі йому мережі - як безпосередньо підключених, так і віддалених, про які маршрутизатор дізнався з RIP-повідомлень.<br /> <br /> '''Етап 5 - отримання RIP-повідомлень від сусідів і обробка отриманої інформації'''. Етап 5 повторює етап 3 - маршрутизатори приймають RIP-повідомлення, обробляють записи що містяться в них і коректують свої таблиці маршрутизації.<br /> <br /> Подивимося, як це робить маршрутизатор Ml (табл. 4).<br /> <br /> '''Таблиця 4'''. Таблиця маршрутизації маршрутизатора M1.<br /> <br /> [[Файл:Rip5.jpg]]<br /> <br /> На цьому етапі маршрутизатор Ml отримав від маршрутизатора М3 інформацію про мережу 132.15.0.0, яку той у свою чергу на попередньому циклі роботи отримав від маршрутизатора М4. Маршрутизатор вже знає про мережу 132.15.0.0, причому стара інформація має кращу метрику, ніж нова, тому нова інформація про цю мережі відкидається.<br /> <br /> Про мережу 202.101.16.0 маршрутизатор Ml дізнається на цьому етапі вперше, причому дані про неї приходять від двох сусідів - від МЗ і М4. Оскільки метрики в цих повідомленнях вказані однакові, то в таблицю потрапляють дані, які прийшли першими. У нашому прикладі вважається, що маршрутизатор М2 випередив маршрутизатор МЗ і першим переслав своє RIP-повідомлення маршрутизатору Ml.<br /> <br /> Якщо маршрутизатори періодично повторюють етапи розсилки та обробки RIP-повідомлень, то за кінцевий час в мережі встановиться коректний режим маршрутизаціі. Під коректним режимом маршрутизації тут розуміється такий стан таблиць маршрутизації, коли всі мережі будуть досяжні з будь-якої мережі за допомогою деякого раціонального маршруту. Пакети будуть доходити до адресатів і не зациклюватися в петлях, подібних до тієї, яка утворюється на мал. 1, маршрутизаторами М1-М2-МЗ-М4.<br /> <br /> Очевидно, якщо в мережі всі маршрутизатори, їх інтерфейси і канали зв'язку, що з'єднують їх постійно працездатні, то оголошення по протоколу RIP можна робити досить рідко, наприклад, один раз на день. Проте в мережах постійно відбуваються зміни - змінюється як працездатність маршрутизаторів і каналів, так і самі маршрутизатори і канали можуть додаватися в існуючу мережу або ж виводитися з її складу.<br /> <br /> Для адаптації до змін у мережі протокол RIP використовує ряд механізмів.<br /> <br /> ==Адаптація RIP-маршрутизаторів до змін стану мережі==<br /> <br /> До нових маршрутів RIP-маршрутизатори пристосовуються просто - вони передають нову інформацію в черговому повідомленні своїм сусідам і поступово ця інформація стає відома всім маршрутизаторам мережі. А ось до негативних змін, пов'язаних з втратою будь-якого маршруту, RIP-маршрутізатори пристосовуються складніше. Це пов'язано з тим, що у форматі повідомлень протоколу RIP немає поля, яке б вказувало на те, що шлях до цієї мережі більше не існує.<br /> <br /> Замість цього використовуються два механізми повідомлення про те, що деякий маршрут більш недійсний:<br /> <br /> *закінчення часу життя маршруту;<br /> <br /> *вказівка ​​спеціальної відстані (нескінченної) до мережі, що стала недоступною.<br /> <br /> Для відпрацювання першого механізму кожен запис таблиці маршрутизації (як і записи таблиці просування моста/комутатора), отримана за протоколом RIP, має час життя (TTL). При надходженні чергового RIP-повідомлення, яке підтверджує справедливість даного запису, таймер TTL встановлюється в початковий стан, а потім з нього кожну секунду віднімається одиниця. Якщо за час тайм-ауту не прийде нове маршрутне повідомлення про цей маршрут, то він позначається як недійсний.<br /> <br /> Час тайм-ауту пов'язаний з періодом розсилки векторів по мережі. У RIP IP період розсилки рівний 30 секундам, а в якості тайм-ауту вибрано шестиразове значення періоду розсилки, тобто 180 секунд. Вибір досить малого часу періоду розсилки пояснюється декількома причинами. Шестиразовий запас часу потрібний для впевненості в тому, що мережа дійсно стала недоступна, а не просто відбулися втрати RIP-повідомлень (а це можливо, оскільки RIP використовує транспортний протокол UDP, який не забезпечує надійної доставки повідомлень).<br /> <br /> Якщо який-небудь маршрутизатор відмовляє і перестає слати своїм сусідам повідомлення про мережі, які можна досягти через нього, то через 180 секунд всі записи, які породив цей маршрутизатор, стануть недійсними у його найближчих сусідів. Після цього процес повториться вже для сусідів найближчих сусідів - вони викреслять подібні записи вже через 360 секунд, тому що перші 180 секунд найближчі сусіди ще передавали повідомлення про ці записи.<br /> <br /> Як видно з пояснення, відомості про недоступні мережі через маршрутизатор, що відмовив поширюються по мережі не дуже швидко, час поширення кратний часу життя запису, а коефіцієнт кратності дорівнює кількості хопов між самими далекими маршрутизаторами мережі. У цьому полягає одна з причин вибору періоду розсилки в 30 секунд.<br /> <br /> Якщо відмовляють не маршрутизатор, а інтерфейс або мережу, що зв'язують його з яким-небудь сусідом, то ситуація зводиться до щойно описаної - знову починає працювати механізм тайм-ауту і маршрути, стали недійсними поступово будуть викреслені з таблиць всіх маршрутизаторів мережі.<br /> <br /> Тайм-аут працює в тих випадках, коли маршрутизатор не може послати сусідам повідомлення про маршрути, що відмовили, тому що або він сам непрацездатний, або непрацездатна лінія зв'язку, по якій можна було б передати повідомлення.<br /> <br /> Коли ж повідомлення послати можна, RIP-маршрутизатори не використовують спеціальної ознаки в повідомленнях, а вказують нескінченну відстань до мережі, причому в протоколі RIP воно вибрано рівним 16 хопам (при іншій метриці необхідно вказати маршрутизатору її значення, що вважається нескінченністю). Отримавши повідомлення, в якому деяка мережу супроводжується відстанню 16 (або 15, що призводить до того ж результату, так як маршрутизатор нарощує отримане значення на 1), маршрутизатор повинен перевірити, надходить ця «погана» інформація про мережу від того ж маршрутизатора, повідомлення якого послужило свого часу підставою для запису про дану мережу в таблиці маршрутизації. Якщо це той же маршрутизатор, то інформація вважається достовірною і маршрут позначається як недоступний.<br /> <br /> Таке невелике значення «нескінченної» відстані викликано тим, що в деяких випадках відмови зв'язків у мережі викликають тривалі періоди некоректної роботи RIP-маршрутизаторів, що виражається в зацикленні пакетів у петлях мережі. І чим менше відстань, що використовується як «нескінченна», тим такі періоди стають коротшими.<br /> <br /> ==Приклад зациклювання пакетів==<br /> <br /> Розглянемо випадок зациклювання пакетів на прикладі мережі, зображеної на рис. 1.<br /> <br /> Нехай маршрутизатор Ml виявив, що його зв'язок з безпосередньо підключеною мережею 201.36.14.0 втрачена (наприклад, з причини відмови інтерфейсу 201.36.14.3). Ml зазначив у своїй таблиці маршрутизації, що мережа 201.36.14.0 недоступна. У гіршому випадку він виявив це відразу ж після відправлення чергових RIP-повідомлень, так що до початку нового циклу його оголошень, в якому він повинен повідомити сусідам, що відстань до мережі 201.36.14.0 стало рівним 16, залишається майже 30 секунд.<br /> <br /> Кожен маршрутизатор працює на підставі свого внутрішнього таймера, не синхронізуючи роботу по розсилці оголошень з іншими маршрутизаторами. Тому дуже ймовірно, маршрутизатор М2 випередив маршрутизатор Ml і передав йому своє повідомлення раніше, ніж Ml встиг передати новину про недосяжність мережі 201.36.14.0. А в цьому повідомленні є дані, що породжені наступним записом в таблиці маршрутизації М2 (табл. 5).<br /> <br /> Таблиця 5. Таблиця маршрутизації маршрутизатора М2.<br /> <br /> [[Файл:Rip6.gif]]<br /> <br /> Цей запис був отриманий від маршрутизатора Ml і коректна до відмови інтерфейсу 201.36.14.3, а тепер вона застаріла, але маршрутизатор М2 про це не дізнався.<br /> <br /> Тепер маршрутизатор Ml отримав нову інформацію про мережу 201.36.14.0 - ця мережа досяжна через маршрутизатор М2 з метрикою 2. Раніше Ml також отримував цю інформацію від М2. Але ігнорував її, так як його власна метрика для 201.36.14.0 була краща. Тепер Ml повинен прийняти дані про мережу 201.36.14.0, отримані від М2, і замінити запис в таблиці маршрутизації про недосяжність цієї мережі (табл. 6).<br /> <br /> Таблиця 6. Таблиця маршрутизації маршрутизатора М1.<br /> <br /> [[Файл:Rip7.gif]]<br /> <br /> У результаті в мережі утворилася маршрутна петля: пакети, що направляються вузлам мережі 201.36.14.0, будуть передаватися маршрутизатором М2 маршрутизатору Ml, а маршрутизатор Ml буде повертати їх маршрутизатору М2. IP-пакети будуть циркулювати по цій петлі до тих пір, поки не закінчиться час життя кожного пакета.<br /> <br /> Маршрутна петля буде існувати в мережі досить довго. Розглянемо періоди часу, кратні часу життя записів у таблицях маршрутизаторів.<br /> <br /> *Час 0-180 с. Після відмови інтерфейсу в маршрутизаторах Ml і М2 будуть зберігатися некоректні записи, наведені вище. Маршрутизатор М2 як і раніше постачає маршрутизатор Ml своїм записом про мережу 201.36.14.0 з метрикою 2, так як її час життя не закінчився. Пакети зациклюються.<br /> <br /> *Час 180-360 с. На початку цього періоду у маршрутизатора М2 закінчується час життя запису про мережу 201.36.14.0 з метрикою 2, так як маршрутизатор Ml в попередній період посилав йому повідомлення про мережу 201.36.14.0 з гіршого метрикою, ніж у М2, і вони не могли підтверджувати цей запис. Тепер маршрутизатор М2 приймає від маршрутизатора Ml запис про мережу 201.36.14.0 з метрикою 3 та трансформує її в запис з метрикою 4. Маршрутизатор Ml не отримує нових повідомлень від маршрутизатора М2 про мережу 201.36.14.0 з метрикою 2, тому час життя його запису починає зменшуватися. Пакети продовжують зациклюватися.<br /> <br /> *Час 360-540 с. Тепер у маршрутизатора Ml закінчується час життя запису про мережу 201.36.14.0 з метрикою 3. Маршрутизатори Ml і М2 знову міняються ролями - М2 постачає Ml застарілою інформацією про шлях до мережі 201.36.14.0, вже з метрикою 4, яку Ml перетворює в метрику 5. Пакети продовжують зациклюватися.<br /> <br /> Якщо б у протоколі RIP не було вибрано відстань 16 як недосяжна, то описаний процес тривав би до нескінченності (вірніше, поки не була б вичерпана розрядна сітка поля відстані і не було б зафіксовано переповнення при черговому нарощуванні відстані).<br /> <br /> У результаті маршрутизатор М2 на черговому етапі описаного процесу отримує від маршрутизатора Ml метрику 15, яка після нарощування, перетворюючись на метрику 16, фіксує недосяжність мережі. Період нестабільної роботи мережі тривав 36 хвилин!<br /> <br /> Обмеження в 15 хопов звужує сферу застосування протоколу RIP до мереж, в яких число проміжних маршрутизаторів не може бути більше 15. Для більш масштабних мереж потрібно застосовувати інші протоколи маршрутизації, наприклад OSPF, або розбивати мережу на автономні області.<br /> <br /> Наведений приклад добре ілюструє головну причину нестабільної роботи маршрутизаторів, що працюють по протоколу RIP. Ця причина полягає в самому принципі роботи дистанційно-векторних протоколів - користування інформацією, отриманою з других рук. Дійсно, маршрутизатор М2 передав маршрутизатору Ml інформацію про досяжності мережі 201.36.14.0, за достовірність якої він сам не відповідає. Викорінити цю причину повністю не можна, адже сам спосіб побудови таблиць маршрутизації пов'язаний з передачею чужої інформації без зазначення джерела її походження.<br /> <br /> Не слід думати, що при будь-яких відмовах інтерфейсів і маршрутизаторів в мережах виникають маршрутні петлі. Якби маршрутизатор Ml встиг передати повідомлення про недосяжність мережі 201.36.14.0 раніше неправдивої інформації маршрутизатора М2, то маршрутна петля не утворилася б. Так що маршрутні петлі навіть без додаткових методів боротьби з ними, описаними в наступному розділі, виникають в середньому не більш ніж у половині потенційно можливих випадків.<br /> <br /> ==Методи боротьби з помилковими маршрутами в протоколі RIP==<br /> <br /> Незважаючи на те що протокол RIP не в змозі повністю виключити перехідні стани в мережі, коли деякі маршрутизатори користуються застарілою інформацією про вже неіснуючі маршрути, є кілька методів, які в багатьох випадках вирішують подібні проблеми.<br /> <br /> Ситуація з петлею, що утворюється між сусідніми маршрутизаторами, описана в попередньому розділі, надійно вирішується за допомогою методу, який отримав назву розщеплення горизонту (split horizon). Метод полягає в тому, що маршрутна інформація про деяку мережу, що зберігається в таблиці маршрутизації, ніколи не передається тому маршрутизатора, від якого вона отримана (це наступний маршрутизатор в даному маршруті). Якщо маршрутизатор М2 в розглянутому вище прикладі підтримує техніку розщеплення горизонту, то він не передасть маршрутизатора Ml застарілу інформацію про мережу 201.36.14.0, оскільки отримав її саме від маршрутизатора Ml.<br /> <br /> Практично всі сьогоднішні маршрутизатори, що працюють по протоколу RIP, використовують техніку розщеплення горизонту.<br /> <br /> Однак розщеплення горизонту не допомагає в тих випадках, коли петлі утворюються не двома, а кількома маршрутизаторами. Розглянемо більш детально ситуацію, яка виникне в мережі, наведеною на рис. 1, у разі втрати зв'язку маршрутизатора 2 з мережею А. Нехай всі маршрутизатори цієї мережі підтримують техніку розщеплення горизонту. Маршрутизатори М2 і МЗ не повертатимуть маршрутизатора в цій ситуації дані про мережу 201.36.14.0 з метрикою 2, так як вони отримали цю інформацію від маршрутизатора Ml. Однак вони будуть передавати маршрутизатору інформацію про досяжності мережі 201.36.14.0 з метрикою 4 через себе, тому що отримали цю інформацію по складному маршруту, а не від маршрутизатора Ml безпосередньо. Наприклад, маршрутизатор М2 отримав цю інформацію по ланцюжку М4-МЗ-М1. Тому маршрутизатор Ml знову може бути обдуреним, поки кожен з маршрутизаторів в ланцюжку МЗ-М4-М2 не викреслить запис про досяжності мережі 1 (а це відбудеться через період 3 х 180 секунд).<br /> <br /> Для запобігання зациклення пакетів по складовим петлям при відмовах зв'язків застосовуються два інших прийоми, так звані тригерні оновлення (triggered updates) і заморожування змін (hold down).<br /> <br /> Спосіб тригерних оновлень полягає в тому, що маршрутизатор, отримавши дані про зміну метрики до будь-якої мережі, не чекає закінчення періоду передачі таблиці маршрутизації, а передає дані про зміну маршруту негайно. Цей прийом може в багатьох випадках запобігти передачі застарілих відомостей про маршрут, що відмовив, але він перевантажує мережу службовими повідомленнями, тому тригерні оголошення також робляться з деякою затримкою. Тому можлива ситуація, коли регулярне оновлення в будь-якому маршрутизаторі трохи випередить за часом прихід тригерніх оновлень від попереднього в ланцюжку маршрутизатора і даний маршрутизатор встигне передати по мережі застарілу інформацію про неіснуючий маршрут.<br /> <br /> Другий прийом дозволяє виключити подібні ситуації. Він пов'язаний з введенням тайм-ауту на прийняття нових даних про мережу, яка щойно стала недоступною. Цей тайм-аут запобігає прийняттю застарілих відомостей про деякий маршрут від тих маршрутизаторів, які знаходяться на деякій відстані від зв'язку, що відмовив та передають застарілі відомості про його працездатність. Передбачається, що протягом тайм-ауту «заморожування змін» ці маршрутизатори викреслять даний маршрут зі своїх таблиць, оскільки не отримають про нього нових записів і не поширюватимуть застарілі відомості по мережі.</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Rip7.gif 2011-12-18T23:32:48Z

<p>Aleksey: </p> <hr /> <div></div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Rip6.gif 2011-12-18T23:29:46Z

<p>Aleksey: </p> <hr /> <div></div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Rip5.jpg 2011-12-18T23:01:52Z

<p>Aleksey: </p> <hr /> <div></div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Rip4.jpg 2011-12-18T22:52:08Z

<p>Aleksey: </p> <hr /> <div></div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Rip3.jpg 2011-12-18T22:42:07Z

<p>Aleksey: </p> <hr /> <div></div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Rip2.jpg 2011-12-18T22:32:37Z

<p>Aleksey: </p> <hr /> <div></div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Rip1.jpg 2011-12-18T22:25:30Z

<p>Aleksey: </p> <hr /> <div></div>

Aleksey https://wiki.cusu.edu.ua/index.php/TCP/IP 2011-12-18T22:04:21Z

<p>Aleksey: </p> <hr /> <div>==Вступ (TCP/IP)==<br /> Протоколи мережної взаємодії TCP/IP є результатом еволюційного розвитку протоколів глобальної обчислювальної мережі ARPANET. <br /> Роботи зі створення мережі ARPANET були розпочаті рядом університетів США і фірмою [http://itc.ua/node/16632/ BBN] у 1968 р. У 1971 р. мережа була введена в регулярну експлуатацію і забезпечувала для усіх своїх вузлів три основні послуги: <br /> · інтерактивний вхід користувача на вилучений вузол; <br /> · передача файлів між вузлами мережі; <br /> · електронна пошта. <br /> Усі ці засоби базувалися на транспортних послугах, наданих програмою керування мережі NCP (Network Control Program), що реалізує свій внутрішній набір протоколів. <br /> Накопичений до 1974 р. досвід експлуатації мережі ARPANET виявив багато недоліків протоколів NCP і дозволив визначити основні вимоги до нового набору протоколів, що отримали назву TCP/IP: <br /> · незалежність від середовища передачі повідомлень; <br /> · можливість підключення до мережі ЕОМ будь-якої архітектури; <br /> · єдиний спосіб організації з'єднання між вузлами в мережі; <br /> · стандартизація прикладних протоколів. <br /> Широко використовувана нині версія 4 протоколів TCP/IP була стандартизована в 1981 р. у вигляді документів, названих RFC (Request For Comment). Повний перехід мережі ARPANET на нові протоколи був завершений у 1982 р. Ця мережа зіграла роль &quot;зародка&quot; всесвітньої мережі Internet, побудованої на базі протоколів TCP/IP. <br /> Реалізація протоколів TCP/IP виявилася найбільш вдалою у версіях BSD4.2 і BSD4.3 операційної системи UNIX. Ця реалізація є еталоном (стандартом &quot;de facto&quot;) для всіх наступних. <br /> <br /> ==Основи TCP/IP==<br /> TCP/IP - це засіб для обміну інформацією між комп'ютерами, об'єднаними в мережу. Не має значення, чи складають вони частину однієї і тієї ж мережі або підключені до окремих мереж. Не грає ролі і те, що один з них може бути комп'ютером Cray, а інший Macintosh. TCP/IP - це не залежний від платформи стандарт, що перекидає мости через прірву, що лежить між різнорідними комп'ютерами, операційними системами і мережами. Це протокол, що глобально керує Internet, і значною мірою завдяки мережі TCP/IP завоював свою популярність. <br /> <br /> Розуміння TCP/IP головним чином має на увазі здатність розбиратися в наборах таємничих протоколів, що використовуються головними комп'ютерами TCP/IP для обміну інформацією. <br /> '''''TCP/IP''''' – це абревіатура терміна Transmission Control Protocol/Internet Protocol (Протокол керування передачею/Протокол Internet). У термінології обчислювальних мереж ''протокол'' – це заздалегідь погоджений стандарт, що дозволяє двом комп'ютерам обмінюватися даними. Фактично TCP/IP не один протокол, а декілька. Саме тому ви часто чуєте, як його називають набором, або комплектом протоколів, серед яких TCP і IP - два основних. <br /> <br /> Програмне забезпечення для TCP/IP, на комп'ютері, являє собою специфічну для даної платформи реалізацію TCP, IP і інших членів сімейства TCP/IP. Звичайно в ньому також маються такі високорівневі прикладні програми, як FTP (File Transfer Protocol, Протокол передачі файлів), що дають можливість через командний рядок керувати обміном файлами по мережі. <br /> <br /> Причина, по якій TCP/IP настільки важливий сьогодні, полягає в тому, що він дозволяє самостійним мережам підключатися до Internet або поєднуватися для створення часток інтрамереж. Обчислювальні мережі, що складають інтрамережу, фізично підключаються через пристрої, що називаються маршрутизаторами або IP-маршрутизаторами. '''[[Маршрутизатор]]''' - це комп'ютер, що передає пакети даних з однієї мережі в іншу. В інтрамережі, що працює на основі TCP/IP, інформація передається у виді дискретних блоків, що називаються IP-пакетами (IP packets) або IP-дейтаграмами (IP datagrams). Завдяки програмному забезпеченню TCP/IP усі комп'ютери, підключені до обчислювальної мережі, стають &quot;близькими родичами&quot;. Власне кажучи воно ховає маршрутизатори і базову архітектуру мереж і робить так, що все це виглядає як одна велика мережа. Точно так само, як підключення до мережі Ethernet розпізнаються по 48-розрядних ідентифікаторах Ethernet, підключення до інтрамережі ідентифікуються 32-розрядними IP-адресами, що ми виражаємо у формі десяткових чисел, розділених крапками (наприклад, 128.10.2.3). Узявши IP-адресу вилученого комп'ютера, комп'ютер в інтрамережі або в Internet може відправити дані на нього, начебто вони складають частину однієї і тієї ж фізичної мережі. <br /> <br /> TCP/IP дає рішення проблеми обміну даними між двома комп'ютерами, підключеними до одній і тієї ж інтрамережі, але приналежним різним фізичним мережам. Рішення складається з декількох частин, причому кожен член сімейства протоколів TCP/IP вносить свою лепту в загальну справу.<br /> <br /> ==Структура стеку TCP/IP==<br /> &lt;center&gt;[[Image:777.PNG]]&lt;/center&gt;<br /> <br /> [[ARP]]. (Address Resolution Protocol, протокол визначення адрес): протокол для визначення фізичної адреси інтерфейсу. Ця адреса необхідна для формування заголовка пакета канального рівня (кадру). Пакети ARP протоколу не доповнюються IP-заголовком міжмережного рівня, а одразу пакуються в кадри (пакети канального рівня), бо вони циркулюють тільки в межах однієї мережі.<br /> <br /> [[ATM]] ( Asynchronous Transfer Mode ) – нова універсальна технологія побудови каналів зв’язку для глобальних і локальних мереж, що забезпечує гарантовану якість і терміновість передавання даних. За цією технологією створюють нові швидкісні магістральні мережі для передавання даних в Україні. Високі ціни на обладнання стримують процес розширення застосування технології ATM . <br /> <br /> [[DNS]] ( Domain Name System ) – доменна система імен, яка призначена для перетворення символьних імен мережних ресурсів у цифрові адреси серверів, де розміщено ці ресурси. <br /> <br /> Ethernet – найбільш розповсюджена технологія побудови каналів зв’язку у локальних мережах. <br /> <br /> Frame Relay – найбільш розповсюджена технологія побудови каналів зв’язку для глобальних мереж. <br /> <br /> [[FTP]] (File Transfer Protocol, протокол передачі файлів): дозволяє передавати файли з одного комп'ютера на іншій з використанням TCP-з'єднань. У схожому, але менш розповсюдженому протоколі передачі файлів - Trivial File Transfer Protocol (TFTP) - для пересилання файлів застосовується UDP, а не TCP. <br /> <br /> [[HTTP]] ( Hypertext Transfer Protocol ) – протокол для передавання Web -сторінок (гіпертексту). <br /> <br /> [[ICMP]] (Internet Control Message Protocol, протокол керуючих повідомлень Internet): дозволяє IP-маршрутизаторам посилати повідомлення про помилки і керуючу інформацію іншим IP-маршрутизаторам і головним комп'ютерам мережі. ICMP-повідомлення &quot;подорожують&quot; у вигляді полів даних IP-дейтаграм і обов'язково повинні реалізовуватися у всіх варіантах IP. <br /> <br /> [[IGMP]] (Internet Group Management Protocol, протокол керування групами Internet): дозволяє [[IP-дейтаграмам]] поширюватися в циркулярному режимі (multicast) серед комп'ютерів, що належать до відповідних груп. <br /> <br /> [[IP]] (Internet Protocol, протокол Internet): низькорівневий протокол, що направляє пакети даних по окремих мережах, зв'язаних разом за допомогою маршрутизаторів для формування Internet або інтрамережі. Дані &quot;подорожують&quot; у формі пакетів, називаних IP-дейтаграмами. <br /> <br /> [[Протокол ІРv6]]<br /> <br /> [[PPP]] ( Point - to - Point Protocol ) – протокол, що широко застосовують для побудови каналу зв’язку між двома віддаленими вузлами, що з’єднані між собою фізичною лінією зв’язку. <br /> <br /> [[RARP]] (Reverse Address Resolution Protocol, протокол зворотного перетворення адрес): перетворить фізичні мережні адреси в IP-адреси. <br /> <br /> [[SMTP]] (Simple Mail Transfer Protocol, простий протокол обміну електронною поштою): визначає формат повідомлень, що SMTP-клієнт, що працює на одному комп'ютері, може використовувати для пересилання електронної пошти на SMTP-сервер, запущений на іншому комп'ютері. <br /> <br /> [[TCP]] (Transmission Control Protocol, протокол керування передачею): протокол орієнтований на роботу з підключеннями і передає дані у вигляді потоків байтів. Дані пересилаються пакетами - TCP-сегментами, - які складаються з заголовків TCP і даних. TCP - &quot;надійний&quot; протокол, тому що в ньому використовуються контрольні суми для перевірки цілісності даних і відправлення підтверджень, щоб гарантувати, що передані дані прийняті без перекручувань. <br /> <br /> [[UDP]] (User Datagram Protocol, протокол користувацьких дейтаграм): протокол, що не залежить від підключень, що передає дані пакетами, називаними UDP-дейтаграмами. UDP - &quot;ненадійний&quot; протокол, оскільки відправник не одержує інформацію, що показує, чи була в дійсності прийнята [[дейтаграма]]. <br /> <br /> [[SNMP]] (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури TCP/IP.<br /> <br /> ==Рівні протоколів TCP/IP==<br /> Найнижчий (&lt;b&gt;&lt;I&gt;рівень IV&lt;/I&gt;&lt;/b&gt;) відповідає фізичному і канальному рівням моделі OSI. Цей рівень у протоколах TCP/IP не регламентується, але підтримує всі популярні стандарти фізичного і канального рівня: для локальних мереж це Ethernet, Token Ring, FDDI, Fast Ethernet, 100VG-AnyLAN, для глобальних мереж - протоколи з'єднань &quot;крапка-крапка&quot; SLIP і PPP, протоколи територіальних мереж з комутацією пакетів X.25, frame relay. Розроблена також спеціальна специфікація, що визначає використання технології ATM як транспорт канального рівня. Звичайно з появою нової технології локальних або глобальних мереж вона швидко включається в стек TCP/IP за рахунок розробки відповідного [[RFC]], що визначає метод інкапсуляції пакетів IP у її кадри. <br /> <br /> Наступний рівень (&lt;b&gt;&lt;I&gt;рівень III&lt;/I&gt;&lt;/b&gt;) - це рівень межмережевої взаємодії, що займається передачею пакетів з використанням різних транспортних технологій локальних мереж, територіальних мереж, ліній спеціального зв'язку і т.п. <br /> <br /> Як основний протокол мережного рівня (у термінах моделі OSI) у стеку використовується протокол IP, що споконвічно проектувався як протокол передачі пакетів у складених мережах, що складаються з великої кількості локальних мереж, об'єднаних як локальними, так і глобальними зв'язками. Тому протокол IP добре працює в мережах зі складною топологією, раціонально використовуючи наявність у них підсистем і ощадливо витрачаючи пропускну здатність низькошвидкісних ліній зв'язку. Протокол IP є дейтаграмним протоколом, тобто він не гарантує доставку пакетів до вузла призначення, але намагається це зробити. <br /> <br /> До рівня міжмережевої взаємодії відносяться і всі протоколи, зв'язані зі складанням і модифікацією таблиць маршрутизації, такі як протоколи збору маршрутної інформації [[RIP]] (Routing Internet Protocol) і OSPF (Open Shortest Path First), а також протокол міжмережевих керуючих повідомлень ICMP (Internet Control Message Protocol). Останній протокол призначений для обміну інформацією про помилки між маршрутизаторами мережі і вузлом - джерелом пакета. За допомогою спеціальних пакетів ICMP повідомляється про неможливість доставки пакета, про перевищення часу життя або тривалості зборки пакета з фрагментів, про аномальні величини параметрів, про зміну маршруту пересилання і типу обслуговування, про стан системи і т.п. <br /> <br /> Наступний рівень (&lt;b&gt;&lt;I&gt;рівень II&lt;/I&gt;&lt;/b&gt;) називається основним. На цьому рівні функціонують протокол керування передачею TCP (Transmission Control Protocol) і протокол дейтаграм користувача UDP (User Datagram Protocol). Протокол TCP забезпечує надійну передачу повідомлень між вилученими прикладними процесами за рахунок утворення віртуальних з'єднань. Протокол UDP забезпечує передачу прикладних пакетів дейтаграмним способом, як і IP, і виконує тільки функції сполучної ланки між мережним протоколом і численними прикладними процесами. <br /> <br /> Верхній рівень (&lt;b&gt;&lt;I&gt;рівень I&lt;/I&gt;&lt;/b&gt;) називається прикладним. За довгі роки використання в мережах різних країн і організацій стік TCP/IP нагромадив велику кількість протоколів і сервісів прикладного рівня. До них відносяться такі широко використовувані протоколи, як протокол копіювання файлів FTP, протокол емуляції термінала telnet, поштовий протокол SMTP, використовуваний в електронній пошті мережі Internet, гіпертекстові сервіси доступу до вилученої інформації, такі як WWW і багато хто інші. <br /> ==Адресація у ІР-мережах==<br /> Міжмережна схема адресації, що застосовується у протоколі ІР, описана у документах RFC 990 i RFC 997. В її основі покладено принцип відокремлення адресації мереж від адресації пристроїв у цих мережах. Така схема полегшує маршрутизацію. При цьому адреси повинні призначатися упорядковано (послідовно), для того, щоб зробити маршрутизацію більш ефективною.<br /> <br /> При застосуванні у мережі стеку протоколів ТСР/ІР порти кінцевих пристроїв отримують унікальні адреси, тобто адресується не сам пристрій у мережі, а визначене з'єднання цього пристрою з мережею. Ця схема приводить до низки неподобств. Одним з них є необхідність заміни адреси пристрою при переміщенні його у іншу мережу. Другий недолік в тім, що для роботи з пристроєм, який має декілька підключень у розподіленій мережі, необхідно знати всі його адреси, які ідентифікують ці підключення. <br /> <br /> Отже для кожного пристрою у мережах ІР можна говорити про адреси трьох рівнів:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Фізична адреса пристрою (точніше - визначеного інтерфейсу). Для пристроїв у мережах Ethernet - це МАС-адреса мережної карти або порту маршрутизатора. Ці адреси призначаються виробниками обладнання. Фізична адреса має шість байтів: старші три байти - ідентифікатор фірми-виробника. Молодші три байти призначаються самим виробником;&lt;/li&gt;<br /> &lt;li&gt;ІР-адреса, що складається з чотирьох байтів. Ця адреса застосовується на мережному рівні еталонної моделі OSI;&lt;/li&gt;<br /> &lt;li&gt;Символьний ідентифікатор - ім'я. Цей ідентифікатор може призначатися адміністратором довільно.&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Коли протокол ІР був стандартизований у вересні 1981 року, його специфікація вимагала, щоб кожний пристрій, підключений до мережі, мав унікальну 32-бітну адресу. Ця адреса поділяється на дві частини. Перша частина адреси ідентифікує мережу, в якій розміщений пристрій. Друга частина однозначно ідентифікує самий пристрій у рамках мережі. Така схема приводить до дворівневої адресної ієрархії.<br /> <br /> Зараз поле номера мережі у адресі називається мережним префіксом, так як воно ідентифікує мережу. Всі робочі станції у мережі мають один і той же префікс. При цьому вони повинні мати унікальні номери пристроїв. Дві робочі станції, розміщені в різних мережах, повинні мати різні мережні префікси, але при цьому вони можуть мати однакові номери пристроїв. <br /> <br /> Для забезпечення гнучкості у привласнюванні адрес комп'ютерним мережам розробники протоколу визначили, що адресний простір повинен бути поділений на три різних класи - А, В і С. Знаючи клас, Ви знаєте, де у 32-бітовій адресі проходить межа між мережним префіксом і номером пристрою. На мал.1 показані формати адрес цих основних класів.<br /> &lt;center&gt;[[Image:1 419.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.1 Три класи ІР-адрес.&lt;/center&gt;<br /> <br /> Одна з основних переваг застосування класів є в тім, що по класу адреси можна визначити, де проходить межа між мережним префіксом і номером пристрою. <br /> <br /> Недоліком такого методу є необхідність зміни мережної адреси при підключенні додаткових пристроїв. Наприклад, якщо загальне число пристроїв у мережі класу С буде перевищувати 255, то вимагатиметься заміна її адреси на адресу класу В. Зміна мережних адрес потребує від адміністратора додаткових зусиль по налагодженню мережі. Крім того, введення класів адрес значно зменшує теоретично можливе число індивідуальних адрес. У поточній версії протоколу ІР (версія 4) загальне число адрес складає 4 294 967 296, так як протокол передбачає застосування 32 біт для задання адреси. Природньо, застосування частини бітів у службових цілях зменшує доступну кількість індивідуальних адрес.<br /> <br /> Клас А призначений для великих мереж. Кожна адреса класу А має 8-бітовий префікс мережі, у якому старший біт встановлений у 1, а наступні 7 використовуються для номера мережі. Для номера пристрою задіюються 24 біти, що залишилися. На сьогоднішній день всі адреси класу А вже виділені. Мережі класу А також позначаються як &quot;/8&quot;, поскільки адреси цього класу мають 8-бітовий префікс.<br /> <br /> Максимальне число мереж класу А складає 126 (2 адреси віднімаються, що складаються з одних нулів і одиниць). Кожна мережа цього класу підтримує до 16 777 214 пристроїв. Так як адресний блок класу А може містити максимум 2 147 483 648 (2 в степіні 31) індивідуальних адрес, а в протоколі ІР версіі 4 може підтримуватися максимум до 4 294 967 296 (2 в степіні 32) адрес, то клас А займає 50% загального адресного простору протоколу ІР.<br /> <br /> Клас В призначений для мереж середнього розміру. Кожна адреса класу В має 16-бітовий мережний префікс, у якому два старших біти дорівнюють 10, наступні 14 біт використовуються для номера мережі. Для номера пристрою надані 16 біт. Мережі класу В також позначаються як &quot;/16&quot;, поскільки адреса цього класу має 16-бітний мережний префікс.<br /> <br /> Максимальне число мереж класу В дорівнює 16 382 (2 в 14 степіні мінус 2). Кожна мережа цього класу підтримує до 65 534 (2 в 16 степіні мінус 2) пристроїв. Так як весь адресний блок класу В може містити максимум до 1 073 741 824 (2 в 30 степіні) індивідуальних адрес, він займає 25% загального простору протоколу ІР.<br /> <br /> Адреса класу С використовується у мережах з невеликим числом пристроїв. Кожна мережа класу С має 24-бітний префікс, в якому три старших біти дорівнюють 110, а наступні 21 біт використовуються для номера мережі. Під номери пристроїв виділені 8 біт, що залишилися. Мережі класу С також позначаються як &quot;/24&quot;, поскільки адреса цього класу має 24-бітний мережний префікс.<br /> <br /> Максимальне число мереж класу С складає 2 097 152 (2 в 21 степіні). Кожна мережа цього класу підтримує до 254 (2 у восьмій мінус 2) пристроїв. Клас С займає 12,5% загального адресного простору протоколу ІР.<br /> <br /> У доповнення до цих класів адрес надають ще два класи. У класі D старші чотири біти дорівнюють 1110. Цей клас використовується для групової передачі даних. У класі Е старші чотири біти дорівнюють 1111. Він зарезервований для проведення експериментів.<br /> <br /> Для зручності читання адрес у технічній літературі, прикладних програмах і т.д. ІР-адреси зображаються у вигляді чотирьох десяткових чисел, розділених точками. Кожне з цих чисел відповідає одному октету (8 бітам) ІР-адреси. Цей формат називають точечно-десятковим (Decimal-Point Notation) або точечно-десятковою нотацією.<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;2&quot;<br /> |+ ІР-адреса у точечно-десятковому форматі.<br /> |-<br /> ! 0... !! !! !! ...31<br /> |-<br /> ! 10010001 !! 00001010 !! 00100010 !! 00000011<br /> |-<br /> ! 145. !! 10. !! 34. !! 3.<br /> |}<br /> <br /> ==Особливі ІР-адреси==<br /> У протоколі ІР існує декілька домовленостей про особливу інтерпретацію ІР-адрес. <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Якщо вся ІР-адреса складається тільки з двійкових нулів, то вона означає адресу того вузла, який згенерував цей пакет; цей режим використовується тільки у деяких повідомленнях ІСМР. &lt;/li&gt;<br /> &lt;li&gt;Якщо в полі адреси мережі стоять тільки нулі, по домовленості вважається, що вузол призначення належить тій самій мережі, що і вузол , який відправив пакет. &lt;/li&gt;<br /> &lt;li&gt;Якщо всі двійкові розряди ІР-адреси дорівнюють 1, то пакет з такою адресою призначення повинен розсилатися всім вузлам, які знаходяться у тій самій мережі, що і відправник цього пакета. Така розсилка називається обмеженим широкомовним повідомленням (limited broadcast).&lt;/li&gt; <br /> &lt;li&gt;Якщо в полі номера вузла призначення стоять тільки одиниці, то пакет, який має таку адресу, розсилається всім вузлам мережі із заданим номером мережі. Наприклад, пакет з адресою 192.190.21.255 доставляється всім вузлам мережі 192.190.21.0. Таке розсилання називається широкомовним повідомленням (broadcast). &lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Особливий зміст має ІР-адреса, перший октет якої дорівнює 127. Вона використовується для тестування програм і взаємодії процесів у межах однієї машини. Коли програма посилає дані за адресою 127.0.0.1, то утворюється як би &quot;петля&quot;. Дані не передаються по мережі, а повертаються модулям верхнього рівня як тільки но прийняті. Тому в ІР-мережі забороняється привласнювати машинам ІР-адреси, які починаються із 127. Ця адреса має назву loopback.<br /> <br /> У протоколі ІР немає поняття широкомовності у тому понятті, в якому воно використовується у протоколах канального рівня локальних мереж, коли дані повинні бути доставлені абсолютно всім вузлам. Як обмежена широкомовна ІР-адреса, так і широкомовна ІР-адреса мають межі розповсюдження у інтермережі - вони обмежені або мережею, до якої належить вузол-джерело пакета, або мережею, номер якої вказаний у адресі призначення. Тому поділ мережі за допомогою маршрутизаторів на частини локалізує широкомовний шторм межами однієї з частин, що складають загальну мережу просто тому, що немає способа адресувати пакет одночасно всім вузлам всіх мереж складеної мережі.<br /> <br /> Форма групової адреси - multicast - означає, що даний пакет повинен бути доставлений відразу декільком вузлам, які утворюють групу з номером, вказаним у полі адреси. Вузли самі ідентифікують себе, тобто визначають, до якої з груп вони відносяться. Один і той самий вузол може входити до декількох груп. Члени будь-якої групи multicast не обов'язково повинні належати одній мережі. Групова адреса не поділяється на поля номера мережі і вузла і обробляється маршрутизатором особливим чином.<br /> <br /> Основне призначення multicast-адрес - розповсюдження інформації за схемою &quot;один-до-багатьох&quot;. Хост, який хоче передавати одну й ту саму інформацію багатьом абонентам, за допомогою спеціального протокола IGMP (Internet Group Management Protocol) повідомляє про створення в мережі нової мультімовної групи із визначеною адресою. Маршрутизатори, які підтримують мультімовність, розповсюджують інформацію про створення нової групи у мережах, підключених до портів цього маршрутизатора. Хости, які хотять під'єднатися до знов створюваної мультімовної групи, повідомляють про це своїм локальним маршрутизаторам і ті передають цю інформацію хосту, ініціатору створення нової групи.<br /> <br /> Щоб маршрутизатори мали можливість автоматично розповсюджувати пакети з адресою multicast по складній мережі, необхідно використовувати у кінцевих маршрутизаторах модифіковані протоколи обміну маршрутною інформацією, такі як, наприклад, MOSPF (Multicast OSPF, аналог OSPF).<br /> Групова адресація призначена для економічного розповсюдження у Internet або у великій корпоративній мережі аудіо- чи відеопрограм, призначених одразу великій аудиторії слухачів або глядачів. Якщо такі засоби знайдуть широке застосування, то Internet зможе створити серйозну конкурецію радіо і телебаченню.<br /> <br /> ==Використання масок у ІР-адресації==<br /> Традиційна схема поділу ІР-адреси на номер мережі і номер вузла базується на понятті класу, який визначається значеннями кількох перших біт адреси. Саме тому, що перший байт адреси 185.23.44.206 попадає у діапазон 128-191, ми можемо сказати, що ця адреса відноситься до класу В, а значить, номером мережі є перші два байти, доповнені двома нульовими байтами - 185.23.0.0, а номером вузла - 0.0.44.206.<br /> <br /> Для гнучкого встановлення межі між номером мережі і номером вузла використовують маску, Маска - це число, яке використовується у парі з ІР-адресою; двійковий запис маски містить одиниці у тих розрядах, які повинні у ІР-адресі інтерпретуватися як номер мережі. Поскільки номер мережі є цілою частиною адреси, одиниці у масці також повинні бути безперервною послідовністю. Для стандартних класів мереж маски мають такі значення:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;клас А - 11111111.00000000.00000000.00000000 (255.0.0.0); &lt;/li&gt;<br /> &lt;li&gt;клас В - 11111111.11111111.00000000.00000000 (255.255.0.0);&lt;/li&gt; <br /> &lt;li&gt;клас С - 11111111.11111111.11111111.00000000 (255.255.255.0).&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Для запису масок використовують і інші формати, наприклад, зручно інтерпретувати значення маски, записаної у шістнадцятьковому коді: FF.FF.00.00 - маска для адрес класу В. Часто зустрічається і таке позначення 185.23.44.206/16 - цей запис означає, що маска для цієї адреси містить 16 одиниць або що у вказаній адресі під номер адреси мережі відведено 16 двійкових розрядів.<br /> ==Підмережі==<br /> Як відомо, ІР-адреса складається з двох їєрархічних рівнів. Необхідність у введенні третього рівня їєрархії - рівня підмереж - була зумовлена виникненням дефіциту номерів мереж і стрімким зростанням таблиць маршрутизації маршрутизаторів у Internet. Після впровадження рівня підмережі номер пристрою поділяється на дві частини - номер підмережі та номер пристрою у цій підмережі.<br /> <br /> &lt;center&gt;[[Image:1 424.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.2 Формування трьохрівневої ієрархії.&lt;/center&gt;<br /> <br /> Збільшення кількості рівнів знімає проблему зростання таблиць маршрутизації завдяки тому, що інформація про топологію корпоративних мереж стає непотрібною магістральним маршрутизаторам Internet. Маршрути з мережі Internet до будь-якої конкретної підмережі, розташованої у мережі із заданою ІР-адресою, однакові і не залежать від того, у якій підмережі розташований отримувач. Це стало можливим завдяки тому, що всі підмережі мережі із заданим номером використовують один і той самий мережний префікс, хоч їх номери (номери підмереж) різні. Маршрутизаторам у приватній мережі потрібно відрізняти окремі підмережі, але для маршрутизаторів Internet всі підмережі відносяться до єдиного запису у таблиці маршрутизації. Це дозволяє адміністратору приватної мережі вносити будь-які зміни у логічну структуру всієї мережі, не впливаючи на розмір таблиць маршрутизації маршрутизаторів Internet.<br /> <br /> Крім того, легко розв'язується проблема виділення номерів при рості організації. Організація отримує номер мережі, а далі адміністратор довільно привласнює номери підмереж для кожної внутрішньої мережі. Це дозволяє організації розширювати свою мережу без необхідності отримання ще одного мережного номера.<br /> ==Маска підмережі==<br /> Якщо маршрутизатори у мережі Internet використовують тільки мережний префікс адреси отримувача для передачі трафіка у організацію, то марщрутизатори всередині приватної мережі організації розширений мережний префікс для передачі трафіка індивідуальним підмережам. Розширеним мережним префіксом називають префікс мережі і номер підмережі.<br /> <br /> &lt;center&gt;[[Image:1 425.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.3 Розширений мережний префікс.&lt;/center&gt;<br /> <br /> Поняття розширеного мережного префікса, по суті, еквівалентно поняттю маска підмережі (subnet mask). Маска підмережі - це двійкове число, яке містить одиниці у тих розрядах, які відносяться до розширеного мережного префікса. Маска підмережі дозволяє поділити ІР-адресу на дві частини: номер підмережі та номер пристрою у цій підмережі.<br /> <br /> Старші біти ІР-адреси використовуються робочими станціями і маршрутизаторами для визначення класу адреси. Після того, як клас визначений, пристрій може легко визначити межу між бітами, які використовувалися для ідентифікації номера мережі, і бітами номера пристрою у цій мережі. Однак для визначення межі бітів, які ідентифікують номер підмережі, така схема не підходить. Для цього саме і використовується 32-бітна маска підмережі, яка допомогає однозначно визначити необхідну межу.<br /> <br /> Біти у масці підмережі повинні бути усталені в одиницю, якщо система, яка перевіряє адресу, повинна розглядати відповідний біт у ІР-адресі як частину мережного префікса. Після визначення класу ІР-адреси, будь-який біт у номері пристрою, який має відповідний усталений біт у масці підмережі, використовується для ідентифікації номера підмережі. Частина номера пристрою, що залишилася, і якій відповідають нульові біти у масці підмережі, використовуються для задання номера пристрою. <br /> <br /> Документ RFC 1219 визначає основне правило, якому слід дотримуватися при привласнюванні номерів підмережам і пристроям. Номери підмереж призначаються таким чином, щоб старші біти у номері підмережі встановлювалися першими (тобто починаючи з крайньої лівої позиції). В той же час одиничні біти номериівпристроїв рекомендується встановлювати, починаючи з крайньої правої позиції. Отже, якщо дотримуватися цього правила, то на межі між номером підмережі і номером пристрою будуть існувати нульові невикористані біти. Це дозволяє змінити маску підмережі без зміни ІР-адреси, привласненої пристрою.<br /> <br /> У мережі із підмережами можна використовувати два види широкомовлення: направлене і обмежене. Направлене широкомовлення використовується для передавання дейтаграми всім пристроям визначеної підмережі. Для відправки дейтаграми всім пристроям у всіх підмережах необхідно використати обмежене широкомовлення із адресою 255.255.255.255. Необхідно, однак, врахувати, що маршрутизатори не пропускають дейтаграми з такою адресою (тому таке широкомовлення називається обмеженим).<br /> <br /> Номери мереж призначаються централізовано, якщо мережа є частиною Internet, або довільно, якщо мережа працює автономно. Номери вузлів і в тому і в іншому випадку адміністратор може призначати самостійно, не виходячи з дозволеного для цього класу мережі діапазону.<br /> <br /> Координуючу роль у централізованому розподілі ІР-адрес спочатку відігравала організація InterNIC, однак із зростанням мережі задача розподілу адрес стала дуже складною, і InterNIC делегувала частину своїх функцій іншим організаціям і крупним поставщикам послуг Internet.<br /> <br /> Якщо деяка ІР-мережа створена для роботи у &quot;автономному режимі&quot;, без зв'язку з Internet, в стандартах Internet визначено декілька діапазонів адрес, рекомендуємих для локального використання. Ці адреси не обробляються маршрутизаторами Internet ні за яких умов. Адреси, зарезервовані для локальних цілей, вибрані з різних класів: у класі А - це мережа 10.0.0.0, у класі В - це діапазон з 16 номерів мереж 172.16.0.0. - 172.31.0.0, у класі С - це діапазон з 255 мереж - 192.168.0.0. - 192.168.255.0.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/TCP/IP 2011-12-18T21:27:59Z

<p>Aleksey: </p> <hr /> <div>==Вступ (TCP/IP)==<br /> Протоколи мережної взаємодії TCP/IP є результатом еволюційного розвитку протоколів глобальної обчислювальної мережі ARPANET. <br /> Роботи зі створення мережі ARPANET були розпочаті рядом університетів США і фірмою [http://itc.ua/node/16632/ BBN] у 1968 р. У 1971 р. мережа була введена в регулярну експлуатацію і забезпечувала для усіх своїх вузлів три основні послуги: <br /> · інтерактивний вхід користувача на вилучений вузол; <br /> · передача файлів між вузлами мережі; <br /> · електронна пошта. <br /> Усі ці засоби базувалися на транспортних послугах, наданих програмою керування мережі NCP (Network Control Program), що реалізує свій внутрішній набір протоколів. <br /> Накопичений до 1974 р. досвід експлуатації мережі ARPANET виявив багато недоліків протоколів NCP і дозволив визначити основні вимоги до нового набору протоколів, що отримали назву TCP/IP: <br /> · незалежність від середовища передачі повідомлень; <br /> · можливість підключення до мережі ЕОМ будь-якої архітектури; <br /> · єдиний спосіб організації з'єднання між вузлами в мережі; <br /> · стандартизація прикладних протоколів. <br /> Широко використовувана нині версія 4 протоколів TCP/IP була стандартизована в 1981 р. у вигляді документів, названих RFC (Request For Comment). Повний перехід мережі ARPANET на нові протоколи був завершений у 1982 р. Ця мережа зіграла роль &quot;зародка&quot; всесвітньої мережі Internet, побудованої на базі протоколів TCP/IP. <br /> Реалізація протоколів TCP/IP виявилася найбільш вдалою у версіях BSD4.2 і BSD4.3 операційної системи UNIX. Ця реалізація є еталоном (стандартом &quot;de facto&quot;) для всіх наступних. <br /> <br /> ==Основи TCP/IP==<br /> TCP/IP - це засіб для обміну інформацією між комп'ютерами, об'єднаними в мережу. Не має значення, чи складають вони частину однієї і тієї ж мережі або підключені до окремих мереж. Не грає ролі і те, що один з них може бути комп'ютером Cray, а інший Macintosh. TCP/IP - це не залежний від платформи стандарт, що перекидає мости через прірву, що лежить між різнорідними комп'ютерами, операційними системами і мережами. Це протокол, що глобально керує Internet, і значною мірою завдяки мережі TCP/IP завоював свою популярність. <br /> <br /> Розуміння TCP/IP головним чином має на увазі здатність розбиратися в наборах таємничих протоколів, що використовуються головними комп'ютерами TCP/IP для обміну інформацією. <br /> '''''TCP/IP''''' – це абревіатура терміна Transmission Control Protocol/Internet Protocol (Протокол керування передачею/Протокол Internet). У термінології обчислювальних мереж ''протокол'' – це заздалегідь погоджений стандарт, що дозволяє двом комп'ютерам обмінюватися даними. Фактично TCP/IP не один протокол, а декілька. Саме тому ви часто чуєте, як його називають набором, або комплектом протоколів, серед яких TCP і IP - два основних. <br /> <br /> Програмне забезпечення для TCP/IP, на комп'ютері, являє собою специфічну для даної платформи реалізацію TCP, IP і інших членів сімейства TCP/IP. Звичайно в ньому також маються такі високорівневі прикладні програми, як FTP (File Transfer Protocol, Протокол передачі файлів), що дають можливість через командний рядок керувати обміном файлами по мережі. <br /> <br /> Причина, по якій TCP/IP настільки важливий сьогодні, полягає в тому, що він дозволяє самостійним мережам підключатися до Internet або поєднуватися для створення часток інтрамереж. Обчислювальні мережі, що складають інтрамережу, фізично підключаються через пристрої, що називаються маршрутизаторами або IP-маршрутизаторами. '''[[Маршрутизатор]]''' - це комп'ютер, що передає пакети даних з однієї мережі в іншу. В інтрамережі, що працює на основі TCP/IP, інформація передається у виді дискретних блоків, що називаються IP-пакетами (IP packets) або IP-дейтаграмами (IP datagrams). Завдяки програмному забезпеченню TCP/IP усі комп'ютери, підключені до обчислювальної мережі, стають &quot;близькими родичами&quot;. Власне кажучи воно ховає маршрутизатори і базову архітектуру мереж і робить так, що все це виглядає як одна велика мережа. Точно так само, як підключення до мережі Ethernet розпізнаються по 48-розрядних ідентифікаторах Ethernet, підключення до інтрамережі ідентифікуються 32-розрядними IP-адресами, що ми виражаємо у формі десяткових чисел, розділених крапками (наприклад, 128.10.2.3). Узявши IP-адресу вилученого комп'ютера, комп'ютер в інтрамережі або в Internet може відправити дані на нього, начебто вони складають частину однієї і тієї ж фізичної мережі. <br /> <br /> TCP/IP дає рішення проблеми обміну даними між двома комп'ютерами, підключеними до одній і тієї ж інтрамережі, але приналежним різним фізичним мережам. Рішення складається з декількох частин, причому кожен член сімейства протоколів TCP/IP вносить свою лепту в загальну справу.<br /> <br /> ==Структура стеку TCP/IP==<br /> &lt;center&gt;[[Image:777.PNG]]&lt;/center&gt;<br /> <br /> [[ARP]]. (Address Resolution Protocol, протокол визначення адрес): протокол для визначення фізичної адреси інтерфейсу. Ця адреса необхідна для формування заголовка пакета канального рівня (кадру). Пакети ARP протоколу не доповнюються IP-заголовком міжмережного рівня, а одразу пакуються в кадри (пакети канального рівня), бо вони циркулюють тільки в межах однієї мережі.<br /> <br /> [[ATM]] ( Asynchronous Transfer Mode ) – нова універсальна технологія побудови каналів зв’язку для глобальних і локальних мереж, що забезпечує гарантовану якість і терміновість передавання даних. За цією технологією створюють нові швидкісні магістральні мережі для передавання даних в Україні. Високі ціни на обладнання стримують процес розширення застосування технології ATM . <br /> <br /> [[DNS]] ( Domain Name System ) – доменна система імен, яка призначена для перетворення символьних імен мережних ресурсів у цифрові адреси серверів, де розміщено ці ресурси. <br /> <br /> Ethernet – найбільш розповсюджена технологія побудови каналів зв’язку у локальних мережах. <br /> <br /> Frame Relay – найбільш розповсюджена технологія побудови каналів зв’язку для глобальних мереж. <br /> <br /> [[FTP]] (File Transfer Protocol, протокол передачі файлів): дозволяє передавати файли з одного комп'ютера на іншій з використанням TCP-з'єднань. У схожому, але менш розповсюдженому протоколі передачі файлів - Trivial File Transfer Protocol (TFTP) - для пересилання файлів застосовується UDP, а не TCP. <br /> <br /> [[HTTP]] ( Hypertext Transfer Protocol ) – протокол для передавання Web -сторінок (гіпертексту). <br /> <br /> [[ICMP]] (Internet Control Message Protocol, протокол керуючих повідомлень Internet): дозволяє IP-маршрутизаторам посилати повідомлення про помилки і керуючу інформацію іншим IP-маршрутизаторам і головним комп'ютерам мережі. ICMP-повідомлення &quot;подорожують&quot; у вигляді полів даних IP-дейтаграм і обов'язково повинні реалізовуватися у всіх варіантах IP. <br /> <br /> [[IGMP]] (Internet Group Management Protocol, протокол керування групами Internet): дозволяє [[IP-дейтаграмам]] поширюватися в циркулярному режимі (multicast) серед комп'ютерів, що належать до відповідних груп. <br /> <br /> [[IP]] (Internet Protocol, протокол Internet): низькорівневий протокол, що направляє пакети даних по окремих мережах, зв'язаних разом за допомогою маршрутизаторів для формування Internet або інтрамережі. Дані &quot;подорожують&quot; у формі пакетів, називаних IP-дейтаграмами. <br /> <br /> [[Протокол ІРv6]]<br /> <br /> [[PPP]] ( Point - to - Point Protocol ) – протокол, що широко застосовують для побудови каналу зв’язку між двома віддаленими вузлами, що з’єднані між собою фізичною лінією зв’язку. <br /> <br /> [[RARP]] (Reverse Address Resolution Protocol, протокол зворотного перетворення адрес): перетворить фізичні мережні адреси в IP-адреси. <br /> <br /> [[SMTP]] (Simple Mail Transfer Protocol, простий протокол обміну електронною поштою): визначає формат повідомлень, що SMTP-клієнт, що працює на одному комп'ютері, може використовувати для пересилання електронної пошти на SMTP-сервер, запущений на іншому комп'ютері. <br /> <br /> [[TCP]] (Transmission Control Protocol, протокол керування передачею): протокол орієнтований на роботу з підключеннями і передає дані у вигляді потоків байтів. Дані пересилаються пакетами - TCP-сегментами, - які складаються з заголовків TCP і даних. TCP - &quot;надійний&quot; протокол, тому що в ньому використовуються контрольні суми для перевірки цілісності даних і відправлення підтверджень, щоб гарантувати, що передані дані прийняті без перекручувань. <br /> <br /> [[UDP]] (User Datagram Protocol, протокол користувацьких дейтаграм): протокол, що не залежить від підключень, що передає дані пакетами, називаними UDP-дейтаграмами. UDP - &quot;ненадійний&quot; протокол, оскільки відправник не одержує інформацію, що показує, чи була в дійсності прийнята [[дейтаграма]]. <br /> <br /> [[SNMP]] (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури TCP/IP.<br /> <br /> ==Рівні протоколів TCP/IP==<br /> Найнижчий (&lt;b&gt;&lt;I&gt;рівень IV&lt;/I&gt;&lt;/b&gt;) відповідає фізичному і канальному рівням моделі OSI. Цей рівень у протоколах TCP/IP не регламентується, але підтримує всі популярні стандарти фізичного і канального рівня: для локальних мереж це Ethernet, Token Ring, FDDI, Fast Ethernet, 100VG-AnyLAN, для глобальних мереж - протоколи з'єднань &quot;крапка-крапка&quot; SLIP і PPP, протоколи територіальних мереж з комутацією пакетів X.25, frame relay. Розроблена також спеціальна специфікація, що визначає використання технології ATM як транспорт канального рівня. Звичайно з появою нової технології локальних або глобальних мереж вона швидко включається в стек TCP/IP за рахунок розробки відповідного [[RFC]], що визначає метод інкапсуляції пакетів IP у її кадри. <br /> <br /> Наступний рівень (&lt;b&gt;&lt;I&gt;рівень III&lt;/I&gt;&lt;/b&gt;) - це рівень межмережевої взаємодії, що займається передачею пакетів з використанням різних транспортних технологій локальних мереж, територіальних мереж, ліній спеціального зв'язку і т.п. <br /> <br /> Як основний протокол мережного рівня (у термінах моделі OSI) у стеку використовується протокол IP, що споконвічно проектувався як протокол передачі пакетів у складених мережах, що складаються з великої кількості локальних мереж, об'єднаних як локальними, так і глобальними зв'язками. Тому протокол IP добре працює в мережах зі складною топологією, раціонально використовуючи наявність у них підсистем і ощадливо витрачаючи пропускну здатність низькошвидкісних ліній зв'язку. Протокол IP є дейтаграмним протоколом, тобто він не гарантує доставку пакетів до вузла призначення, але намагається це зробити. <br /> <br /> До рівня міжмережевої взаємодії відносяться і всі протоколи, зв'язані зі складанням і модифікацією таблиць маршрутизації, такі як протоколи збору маршрутної інформації RIP (Routing Internet Protocol) і OSPF (Open Shortest Path First), а також протокол міжмережевих керуючих повідомлень ICMP (Internet Control Message Protocol). Останній протокол призначений для обміну інформацією про помилки між маршрутизаторами мережі і вузлом - джерелом пакета. За допомогою спеціальних пакетів ICMP повідомляється про неможливість доставки пакета, про перевищення часу життя або тривалості зборки пакета з фрагментів, про аномальні величини параметрів, про зміну маршруту пересилання і типу обслуговування, про стан системи і т.п. <br /> <br /> Наступний рівень (&lt;b&gt;&lt;I&gt;рівень II&lt;/I&gt;&lt;/b&gt;) називається основним. На цьому рівні функціонують протокол керування передачею TCP (Transmission Control Protocol) і протокол дейтаграм користувача UDP (User Datagram Protocol). Протокол TCP забезпечує надійну передачу повідомлень між вилученими прикладними процесами за рахунок утворення віртуальних з'єднань. Протокол UDP забезпечує передачу прикладних пакетів дейтаграмним способом, як і IP, і виконує тільки функції сполучної ланки між мережним протоколом і численними прикладними процесами. <br /> <br /> Верхній рівень (&lt;b&gt;&lt;I&gt;рівень I&lt;/I&gt;&lt;/b&gt;) називається прикладним. За довгі роки використання в мережах різних країн і організацій стік TCP/IP нагромадив велику кількість протоколів і сервісів прикладного рівня. До них відносяться такі широко використовувані протоколи, як протокол копіювання файлів FTP, протокол емуляції термінала telnet, поштовий протокол SMTP, використовуваний в електронній пошті мережі Internet, гіпертекстові сервіси доступу до вилученої інформації, такі як WWW і багато хто інші. <br /> ==Адресація у ІР-мережах==<br /> Міжмережна схема адресації, що застосовується у протоколі ІР, описана у документах RFC 990 i RFC 997. В її основі покладено принцип відокремлення адресації мереж від адресації пристроїв у цих мережах. Така схема полегшує маршрутизацію. При цьому адреси повинні призначатися упорядковано (послідовно), для того, щоб зробити маршрутизацію більш ефективною.<br /> <br /> При застосуванні у мережі стеку протоколів ТСР/ІР порти кінцевих пристроїв отримують унікальні адреси, тобто адресується не сам пристрій у мережі, а визначене з'єднання цього пристрою з мережею. Ця схема приводить до низки неподобств. Одним з них є необхідність заміни адреси пристрою при переміщенні його у іншу мережу. Другий недолік в тім, що для роботи з пристроєм, який має декілька підключень у розподіленій мережі, необхідно знати всі його адреси, які ідентифікують ці підключення. <br /> <br /> Отже для кожного пристрою у мережах ІР можна говорити про адреси трьох рівнів:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Фізична адреса пристрою (точніше - визначеного інтерфейсу). Для пристроїв у мережах Ethernet - це МАС-адреса мережної карти або порту маршрутизатора. Ці адреси призначаються виробниками обладнання. Фізична адреса має шість байтів: старші три байти - ідентифікатор фірми-виробника. Молодші три байти призначаються самим виробником;&lt;/li&gt;<br /> &lt;li&gt;ІР-адреса, що складається з чотирьох байтів. Ця адреса застосовується на мережному рівні еталонної моделі OSI;&lt;/li&gt;<br /> &lt;li&gt;Символьний ідентифікатор - ім'я. Цей ідентифікатор може призначатися адміністратором довільно.&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Коли протокол ІР був стандартизований у вересні 1981 року, його специфікація вимагала, щоб кожний пристрій, підключений до мережі, мав унікальну 32-бітну адресу. Ця адреса поділяється на дві частини. Перша частина адреси ідентифікує мережу, в якій розміщений пристрій. Друга частина однозначно ідентифікує самий пристрій у рамках мережі. Така схема приводить до дворівневої адресної ієрархії.<br /> <br /> Зараз поле номера мережі у адресі називається мережним префіксом, так як воно ідентифікує мережу. Всі робочі станції у мережі мають один і той же префікс. При цьому вони повинні мати унікальні номери пристроїв. Дві робочі станції, розміщені в різних мережах, повинні мати різні мережні префікси, але при цьому вони можуть мати однакові номери пристроїв. <br /> <br /> Для забезпечення гнучкості у привласнюванні адрес комп'ютерним мережам розробники протоколу визначили, що адресний простір повинен бути поділений на три різних класи - А, В і С. Знаючи клас, Ви знаєте, де у 32-бітовій адресі проходить межа між мережним префіксом і номером пристрою. На мал.1 показані формати адрес цих основних класів.<br /> &lt;center&gt;[[Image:1 419.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.1 Три класи ІР-адрес.&lt;/center&gt;<br /> <br /> Одна з основних переваг застосування класів є в тім, що по класу адреси можна визначити, де проходить межа між мережним префіксом і номером пристрою. <br /> <br /> Недоліком такого методу є необхідність зміни мережної адреси при підключенні додаткових пристроїв. Наприклад, якщо загальне число пристроїв у мережі класу С буде перевищувати 255, то вимагатиметься заміна її адреси на адресу класу В. Зміна мережних адрес потребує від адміністратора додаткових зусиль по налагодженню мережі. Крім того, введення класів адрес значно зменшує теоретично можливе число індивідуальних адрес. У поточній версії протоколу ІР (версія 4) загальне число адрес складає 4 294 967 296, так як протокол передбачає застосування 32 біт для задання адреси. Природньо, застосування частини бітів у службових цілях зменшує доступну кількість індивідуальних адрес.<br /> <br /> Клас А призначений для великих мереж. Кожна адреса класу А має 8-бітовий префікс мережі, у якому старший біт встановлений у 1, а наступні 7 використовуються для номера мережі. Для номера пристрою задіюються 24 біти, що залишилися. На сьогоднішній день всі адреси класу А вже виділені. Мережі класу А також позначаються як &quot;/8&quot;, поскільки адреси цього класу мають 8-бітовий префікс.<br /> <br /> Максимальне число мереж класу А складає 126 (2 адреси віднімаються, що складаються з одних нулів і одиниць). Кожна мережа цього класу підтримує до 16 777 214 пристроїв. Так як адресний блок класу А може містити максимум 2 147 483 648 (2 в степіні 31) індивідуальних адрес, а в протоколі ІР версіі 4 може підтримуватися максимум до 4 294 967 296 (2 в степіні 32) адрес, то клас А займає 50% загального адресного простору протоколу ІР.<br /> <br /> Клас В призначений для мереж середнього розміру. Кожна адреса класу В має 16-бітовий мережний префікс, у якому два старших біти дорівнюють 10, наступні 14 біт використовуються для номера мережі. Для номера пристрою надані 16 біт. Мережі класу В також позначаються як &quot;/16&quot;, поскільки адреса цього класу має 16-бітний мережний префікс.<br /> <br /> Максимальне число мереж класу В дорівнює 16 382 (2 в 14 степіні мінус 2). Кожна мережа цього класу підтримує до 65 534 (2 в 16 степіні мінус 2) пристроїв. Так як весь адресний блок класу В може містити максимум до 1 073 741 824 (2 в 30 степіні) індивідуальних адрес, він займає 25% загального простору протоколу ІР.<br /> <br /> Адреса класу С використовується у мережах з невеликим числом пристроїв. Кожна мережа класу С має 24-бітний префікс, в якому три старших біти дорівнюють 110, а наступні 21 біт використовуються для номера мережі. Під номери пристроїв виділені 8 біт, що залишилися. Мережі класу С також позначаються як &quot;/24&quot;, поскільки адреса цього класу має 24-бітний мережний префікс.<br /> <br /> Максимальне число мереж класу С складає 2 097 152 (2 в 21 степіні). Кожна мережа цього класу підтримує до 254 (2 у восьмій мінус 2) пристроїв. Клас С займає 12,5% загального адресного простору протоколу ІР.<br /> <br /> У доповнення до цих класів адрес надають ще два класи. У класі D старші чотири біти дорівнюють 1110. Цей клас використовується для групової передачі даних. У класі Е старші чотири біти дорівнюють 1111. Він зарезервований для проведення експериментів.<br /> <br /> Для зручності читання адрес у технічній літературі, прикладних програмах і т.д. ІР-адреси зображаються у вигляді чотирьох десяткових чисел, розділених точками. Кожне з цих чисел відповідає одному октету (8 бітам) ІР-адреси. Цей формат називають точечно-десятковим (Decimal-Point Notation) або точечно-десятковою нотацією.<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;2&quot;<br /> |+ ІР-адреса у точечно-десятковому форматі.<br /> |-<br /> ! 0... !! !! !! ...31<br /> |-<br /> ! 10010001 !! 00001010 !! 00100010 !! 00000011<br /> |-<br /> ! 145. !! 10. !! 34. !! 3.<br /> |}<br /> <br /> ==Особливі ІР-адреси==<br /> У протоколі ІР існує декілька домовленостей про особливу інтерпретацію ІР-адрес. <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Якщо вся ІР-адреса складається тільки з двійкових нулів, то вона означає адресу того вузла, який згенерував цей пакет; цей режим використовується тільки у деяких повідомленнях ІСМР. &lt;/li&gt;<br /> &lt;li&gt;Якщо в полі адреси мережі стоять тільки нулі, по домовленості вважається, що вузол призначення належить тій самій мережі, що і вузол , який відправив пакет. &lt;/li&gt;<br /> &lt;li&gt;Якщо всі двійкові розряди ІР-адреси дорівнюють 1, то пакет з такою адресою призначення повинен розсилатися всім вузлам, які знаходяться у тій самій мережі, що і відправник цього пакета. Така розсилка називається обмеженим широкомовним повідомленням (limited broadcast).&lt;/li&gt; <br /> &lt;li&gt;Якщо в полі номера вузла призначення стоять тільки одиниці, то пакет, який має таку адресу, розсилається всім вузлам мережі із заданим номером мережі. Наприклад, пакет з адресою 192.190.21.255 доставляється всім вузлам мережі 192.190.21.0. Таке розсилання називається широкомовним повідомленням (broadcast). &lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Особливий зміст має ІР-адреса, перший октет якої дорівнює 127. Вона використовується для тестування програм і взаємодії процесів у межах однієї машини. Коли програма посилає дані за адресою 127.0.0.1, то утворюється як би &quot;петля&quot;. Дані не передаються по мережі, а повертаються модулям верхнього рівня як тільки но прийняті. Тому в ІР-мережі забороняється привласнювати машинам ІР-адреси, які починаються із 127. Ця адреса має назву loopback.<br /> <br /> У протоколі ІР немає поняття широкомовності у тому понятті, в якому воно використовується у протоколах канального рівня локальних мереж, коли дані повинні бути доставлені абсолютно всім вузлам. Як обмежена широкомовна ІР-адреса, так і широкомовна ІР-адреса мають межі розповсюдження у інтермережі - вони обмежені або мережею, до якої належить вузол-джерело пакета, або мережею, номер якої вказаний у адресі призначення. Тому поділ мережі за допомогою маршрутизаторів на частини локалізує широкомовний шторм межами однієї з частин, що складають загальну мережу просто тому, що немає способа адресувати пакет одночасно всім вузлам всіх мереж складеної мережі.<br /> <br /> Форма групової адреси - multicast - означає, що даний пакет повинен бути доставлений відразу декільком вузлам, які утворюють групу з номером, вказаним у полі адреси. Вузли самі ідентифікують себе, тобто визначають, до якої з груп вони відносяться. Один і той самий вузол може входити до декількох груп. Члени будь-якої групи multicast не обов'язково повинні належати одній мережі. Групова адреса не поділяється на поля номера мережі і вузла і обробляється маршрутизатором особливим чином.<br /> <br /> Основне призначення multicast-адрес - розповсюдження інформації за схемою &quot;один-до-багатьох&quot;. Хост, який хоче передавати одну й ту саму інформацію багатьом абонентам, за допомогою спеціального протокола IGMP (Internet Group Management Protocol) повідомляє про створення в мережі нової мультімовної групи із визначеною адресою. Маршрутизатори, які підтримують мультімовність, розповсюджують інформацію про створення нової групи у мережах, підключених до портів цього маршрутизатора. Хости, які хотять під'єднатися до знов створюваної мультімовної групи, повідомляють про це своїм локальним маршрутизаторам і ті передають цю інформацію хосту, ініціатору створення нової групи.<br /> <br /> Щоб маршрутизатори мали можливість автоматично розповсюджувати пакети з адресою multicast по складній мережі, необхідно використовувати у кінцевих маршрутизаторах модифіковані протоколи обміну маршрутною інформацією, такі як, наприклад, MOSPF (Multicast OSPF, аналог OSPF).<br /> Групова адресація призначена для економічного розповсюдження у Internet або у великій корпоративній мережі аудіо- чи відеопрограм, призначених одразу великій аудиторії слухачів або глядачів. Якщо такі засоби знайдуть широке застосування, то Internet зможе створити серйозну конкурецію радіо і телебаченню.<br /> <br /> ==Використання масок у ІР-адресації==<br /> Традиційна схема поділу ІР-адреси на номер мережі і номер вузла базується на понятті класу, який визначається значеннями кількох перших біт адреси. Саме тому, що перший байт адреси 185.23.44.206 попадає у діапазон 128-191, ми можемо сказати, що ця адреса відноситься до класу В, а значить, номером мережі є перші два байти, доповнені двома нульовими байтами - 185.23.0.0, а номером вузла - 0.0.44.206.<br /> <br /> Для гнучкого встановлення межі між номером мережі і номером вузла використовують маску, Маска - це число, яке використовується у парі з ІР-адресою; двійковий запис маски містить одиниці у тих розрядах, які повинні у ІР-адресі інтерпретуватися як номер мережі. Поскільки номер мережі є цілою частиною адреси, одиниці у масці також повинні бути безперервною послідовністю. Для стандартних класів мереж маски мають такі значення:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;клас А - 11111111.00000000.00000000.00000000 (255.0.0.0); &lt;/li&gt;<br /> &lt;li&gt;клас В - 11111111.11111111.00000000.00000000 (255.255.0.0);&lt;/li&gt; <br /> &lt;li&gt;клас С - 11111111.11111111.11111111.00000000 (255.255.255.0).&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Для запису масок використовують і інші формати, наприклад, зручно інтерпретувати значення маски, записаної у шістнадцятьковому коді: FF.FF.00.00 - маска для адрес класу В. Часто зустрічається і таке позначення 185.23.44.206/16 - цей запис означає, що маска для цієї адреси містить 16 одиниць або що у вказаній адресі під номер адреси мережі відведено 16 двійкових розрядів.<br /> ==Підмережі==<br /> Як відомо, ІР-адреса складається з двох їєрархічних рівнів. Необхідність у введенні третього рівня їєрархії - рівня підмереж - була зумовлена виникненням дефіциту номерів мереж і стрімким зростанням таблиць маршрутизації маршрутизаторів у Internet. Після впровадження рівня підмережі номер пристрою поділяється на дві частини - номер підмережі та номер пристрою у цій підмережі.<br /> <br /> &lt;center&gt;[[Image:1 424.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.2 Формування трьохрівневої ієрархії.&lt;/center&gt;<br /> <br /> Збільшення кількості рівнів знімає проблему зростання таблиць маршрутизації завдяки тому, що інформація про топологію корпоративних мереж стає непотрібною магістральним маршрутизаторам Internet. Маршрути з мережі Internet до будь-якої конкретної підмережі, розташованої у мережі із заданою ІР-адресою, однакові і не залежать від того, у якій підмережі розташований отримувач. Це стало можливим завдяки тому, що всі підмережі мережі із заданим номером використовують один і той самий мережний префікс, хоч їх номери (номери підмереж) різні. Маршрутизаторам у приватній мережі потрібно відрізняти окремі підмережі, але для маршрутизаторів Internet всі підмережі відносяться до єдиного запису у таблиці маршрутизації. Це дозволяє адміністратору приватної мережі вносити будь-які зміни у логічну структуру всієї мережі, не впливаючи на розмір таблиць маршрутизації маршрутизаторів Internet.<br /> <br /> Крім того, легко розв'язується проблема виділення номерів при рості організації. Організація отримує номер мережі, а далі адміністратор довільно привласнює номери підмереж для кожної внутрішньої мережі. Це дозволяє організації розширювати свою мережу без необхідності отримання ще одного мережного номера.<br /> ==Маска підмережі==<br /> Якщо маршрутизатори у мережі Internet використовують тільки мережний префікс адреси отримувача для передачі трафіка у організацію, то марщрутизатори всередині приватної мережі організації розширений мережний префікс для передачі трафіка індивідуальним підмережам. Розширеним мережним префіксом називають префікс мережі і номер підмережі.<br /> <br /> &lt;center&gt;[[Image:1 425.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.3 Розширений мережний префікс.&lt;/center&gt;<br /> <br /> Поняття розширеного мережного префікса, по суті, еквівалентно поняттю маска підмережі (subnet mask). Маска підмережі - це двійкове число, яке містить одиниці у тих розрядах, які відносяться до розширеного мережного префікса. Маска підмережі дозволяє поділити ІР-адресу на дві частини: номер підмережі та номер пристрою у цій підмережі.<br /> <br /> Старші біти ІР-адреси використовуються робочими станціями і маршрутизаторами для визначення класу адреси. Після того, як клас визначений, пристрій може легко визначити межу між бітами, які використовувалися для ідентифікації номера мережі, і бітами номера пристрою у цій мережі. Однак для визначення межі бітів, які ідентифікують номер підмережі, така схема не підходить. Для цього саме і використовується 32-бітна маска підмережі, яка допомогає однозначно визначити необхідну межу.<br /> <br /> Біти у масці підмережі повинні бути усталені в одиницю, якщо система, яка перевіряє адресу, повинна розглядати відповідний біт у ІР-адресі як частину мережного префікса. Після визначення класу ІР-адреси, будь-який біт у номері пристрою, який має відповідний усталений біт у масці підмережі, використовується для ідентифікації номера підмережі. Частина номера пристрою, що залишилася, і якій відповідають нульові біти у масці підмережі, використовуються для задання номера пристрою. <br /> <br /> Документ RFC 1219 визначає основне правило, якому слід дотримуватися при привласнюванні номерів підмережам і пристроям. Номери підмереж призначаються таким чином, щоб старші біти у номері підмережі встановлювалися першими (тобто починаючи з крайньої лівої позиції). В той же час одиничні біти номериівпристроїв рекомендується встановлювати, починаючи з крайньої правої позиції. Отже, якщо дотримуватися цього правила, то на межі між номером підмережі і номером пристрою будуть існувати нульові невикористані біти. Це дозволяє змінити маску підмережі без зміни ІР-адреси, привласненої пристрою.<br /> <br /> У мережі із підмережами можна використовувати два види широкомовлення: направлене і обмежене. Направлене широкомовлення використовується для передавання дейтаграми всім пристроям визначеної підмережі. Для відправки дейтаграми всім пристроям у всіх підмережах необхідно використати обмежене широкомовлення із адресою 255.255.255.255. Необхідно, однак, врахувати, що маршрутизатори не пропускають дейтаграми з такою адресою (тому таке широкомовлення називається обмеженим).<br /> <br /> Номери мереж призначаються централізовано, якщо мережа є частиною Internet, або довільно, якщо мережа працює автономно. Номери вузлів і в тому і в іншому випадку адміністратор може призначати самостійно, не виходячи з дозволеного для цього класу мережі діапазону.<br /> <br /> Координуючу роль у централізованому розподілі ІР-адрес спочатку відігравала організація InterNIC, однак із зростанням мережі задача розподілу адрес стала дуже складною, і InterNIC делегувала частину своїх функцій іншим організаціям і крупним поставщикам послуг Internet.<br /> <br /> Якщо деяка ІР-мережа створена для роботи у &quot;автономному режимі&quot;, без зв'язку з Internet, в стандартах Internet визначено декілька діапазонів адрес, рекомендуємих для локального використання. Ці адреси не обробляються маршрутизаторами Internet ні за яких умов. Адреси, зарезервовані для локальних цілей, вибрані з різних класів: у класі А - це мережа 10.0.0.0, у класі В - це діапазон з 16 номерів мереж 172.16.0.0. - 172.31.0.0, у класі С - це діапазон з 255 мереж - 192.168.0.0. - 192.168.255.0.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%BE%D1%80%D1%96%D0%B2%D0%BD%D1%8F%D0%BB%D1%8C%D0%BD%D0%B8%D0%B9_%D0%B0%D0%BD%D0%B0%D0%BB%D1%96%D0%B7_%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D1%96%D0%B2_%D0%9D.323_%D1%96_SIP 2011-12-18T21:00:03Z

<p>Aleksey: </p> <hr /> <div>&lt;div style=&quot;background: #33ccff&quot;&gt; <br /> '''[[Технологія VoIP]]''' &gt;&gt; <br /> '''[[Розділ_7._Протокол_ініціювання_сеансів_зв'язку_-_SIP|Розділ 7. Протокол ініціювання сеансів зв'язку - SIP]]'''<br /> &lt;center&gt;<br /> ----<br /> [ [[Алгоритми_встановлення_з'єднання|&lt;&lt; 7.6 Алгоритми встановлення з'єднання]] ]<br /> ----<br /> &lt;/center&gt;<br /> &lt;/div&gt;<br /> '''7.8 Порівняльний аналіз протоколів Н.323 і SIP'''&lt;br&gt;<br /> Перш ніж розпочати порівняння функціональних можливостей протоколів SIP і Н.323, нагадаємо, що протокол SIP значно молодший за свого суперника, і досвід його використання в мережах зв'язку непорівнянний з досвідом використання протоколу Н.323. Існує ще один момент, на який слід звернути увагу. Інтенсивне впровадження технології передачі мовної інформації по IP-мереж зажадало постійного нарощування функціональних можливостей як протоколу Н.323 (до цього часу затверджена вже третя версія протоколу), так і протоколу SIP (затверджена друга версія протоколу). Цей процес призводить до того, що достоїнства одного з протоколів переймають іншим.&lt;br&gt;<br /> І останнє. Обидва протоколу є результатом розв'язання одних і тих же завдань фахівцями ITU-T і комітету IETF. Природно, що рішення ITU-T виявилося ближче до традиційних телефонних мереж, а рішення комітету IETF базується на принципах, що становлять основу мережі Internet.&lt;br&gt;<br /> Перейдемо безпосередньо до порівняння протоколів, яке будемо проводити за кількома критеріями.&lt;br&gt;<br /> Додаткові послуги. Набір послуг, що надаються обома протоколами, приблизно однаковий.&lt;br&gt;<br /> Додаткові послуги, що надаються протоколом Н.323, стандартизовані в серії рекомендацій ITU-T H.450.X. Протоколом SIP правила надання додаткових послуг не визначені, що є його серйозним недоліком, тому що викликає проблеми при організації взаємодії обладнання різних фірм-виробників. Деякі фахівці пропонують вирішення названих проблем, але ці рішення поки не стандартизовані.&lt;br&gt;<br /> Приклади послуг, що надаються обома протоколами:&lt;br&gt;<br /> • Переклад з'єднання в режим утримання (Call hold);&lt;br&gt;<br /> • Перемикання зв'язку (Call Transfer);&lt;br&gt;<br /> • Переадресація (Call Forwarding);&lt;br&gt;<br /> • Повідомлення про новий виклик під час зв'язку (Call Waiting);&lt;br&gt;<br /> • Конференція.&lt;br&gt;<br /> Розглянемо останню послугу кілька більш докладно. Протокол SIP передбачає три способи організації конференції: з використанням пристрою управління конференціями MCU, режиму під LGPL і з'єднань учасників один з одним. В останніх двох випадках функції управління конференціями можуть бути розподілені між терміналами, тобто центральний контролер конференцій не потрібен. Це дозволяє організовувати конференції з практично необмеженою кількістю учасників.&lt;br&gt;<br /> Рекомендація Н.323 передбачає ті ж три способи, але управління конференцією у всіх випадках проводиться централізовано контролером конференцій МС (Multipoint Controller), який обробляє всі сигнальні повідомлення. Тому для організації конференції, по-перше, необхідна наявність контролера МС у одного з терміналів, по-друге, учасник з активним контролером МС не може вийти з конференції / Крім того, при великому числі учасників конференції МС може стати «вузьким місцем». Правда, в третій версії рекомендації ITU-T Н.323 прийнято положення про каскадному з'єднанні контролерів, однак виробники цю версію в своєму обладнанні поки не реалізували. Перевагою протоколу Н.323 в частині організації конференцій є більш потужні засоби контролю конференцій.&lt;br&gt;<br /> Протокол SIP початку орієнтований на використання в IP-мережах з підтримкою режиму під LGPL інформації (прикладом може бути мережу Mbone, що має тисячі постійних користувачів). Цей механізм використовується в протоколі SIP не тільки для доставки мовної інформації (як у протоколі Н.323), але і для перенесення сигнальних повідомлень. Наприклад, в режимі під LGPL може передаватися повідомлення INVITE, що полегшує визначення місця розташування користувача і є дуже зручним для центрів обслуговування викликів (Call-center) при організації групових оповіщень.&lt;br&gt;<br /> У той же час, протокол Н.323 надає більше можливостей управління послугами, як у частині аутентифікації та обліку, так і в частині контролю використання мережевих ресурсів. Можливості протоколу SIP у цій частині біднішими, і вибір оператором цього протоколу може служити ознакою того, що для оператора важливіше технічна інтеграція послуг, ніж можливості управління послугами.&lt;br&gt;<br /> Протокол SIP передбачає можливість організації зв'язку третьою стороною (third-party call control). Ця функція дозволяє реалізувати такі послуги, як набір номера секретарем для менеджера та супровід виклику оператором центру обслуговування викликів. Подібні послуги передбачені і протоколом Н.323, але реалізація їх трохи складніше.&lt;br&gt;<br /> У протоколі SIP є можливість вказувати пріоритети в обслуговуванні викликів, оскільки в багатьох країнах існують вимоги надавати переваги деяким користувачам. У протоколі Н.323 такої можливості немає. Крім того, користувач SIP-мережі може реєструвати декілька своїх адрес і вказувати пріоритетність кожного з них.&lt;br&gt;<br /> Персональна мобільність користувачів. Протокол SIP має гарний набір засобів підтримки персональної мобільності користувачів, до числа яких входить переадресація виклику до нового місця розташування користувача, одночасний пошук по нескільком напрямами (з виявленням зациклення маршрутів) і т.д. У протоколі SIP це організується шляхом реєстрації на сервері визначення місця розташування, взаємодія з яким може підтримуватися будь-яким протоколом. Персональна мобільність підтримується і протоколом Н.323, але менш гнучко. Так, наприклад, одночасний пошук користувача по декількох напрямках обмежений тем. що воротар, отримавши запит визначення місця розташування користувача LRQ, не транслює його до інших придверничі.&lt;br&gt;<br /> Розширюваність протоколу. Необхідною і важливою в умовах еволюціонує ринку є можливість введення нових версій протоколів та забезпечення сумісності різних версій одного протоколу. Розширюваність (extensibility) протоколу забезпечується:&lt;br&gt;<br /> - Узгодженням параметрів;&lt;br&gt;<br /> - Стандартизацією кодеків;&lt;br&gt;<br /> - Модульність архітектури.&lt;br&gt;<br /> Протокол SIP досить просто забезпечує сумісність різних версій. Поля, які не зрозумілі обладнанню, просто ігноруються. Це зменшує складність протоколу, а також полегшує обробку повідомлень та впровадження нових послуг. Клієнт може запросити будь-яку послугу за допомогою заголовка Require. Сервер, що отримав запит з таким заголовком, перевіряє, чи підтримує він цю послугу, і якщо не підтримує, то повідомляє про це у своїй відповіді, що містить список підтримуваних послуг.&lt;br&gt;<br /> У разі необхідності, в організації IANA (Internet Assigned Numbers Authority) можуть бути зареєстровані нові заголовки. Для реєстрації в IANA відправляється запит з ім'ям заголовка і його призначенням. Назва заголовка вибирається таким чином, щоб воно говорило про його призначення. Зазначеним чином розробник може впроваджувати нові послуги.&lt;br&gt;<br /> Для забезпечення сумісності версій протоколу SIP визначено шість основних видів запитів і 6 класів відповідей на запити. Так як визначальної в кодах відповідей є перша цифра, те обладнання може вказувати і інтерпретувати тільки її. а інші цифри коду тільки доповнюють зміст і їх аналіз не є обов'язковим.&lt;br&gt;<br /> Пізніші версії протоколу Н.323 повинні підтримувати більш ранні версії. Але можлива ситуація, коли виробники підтримують тільки одну версію, щоб зменшити розмір повідомлень і полегшити їх декодування.&lt;br&gt;<br /> Нові функціональні можливості вводяться в протокол Н.323 за допомогою поля NonStandardParameter. Воно містить код виробника і, слідом за ним, код послуги, який дійсний тільки для цього виробника. Це дозволяє виробникові розширювати послуги, але пов'язане з деякими обмеженнями. По-перше, неможливо вимагати від викликається сторони інформацію про підтримувані нею послугах, по-друге, неможливо додати нове значення вже існуючого параметра. Існують також проблеми, пов'язані із забезпеченням взаємодії устаткування різних виробників.&lt;br&gt;<br /> На розширення можливостей протоколу, як і на сумісність обладнання, його реалізує, робить вплив і набір кодеків, підтримуваний протоколом. У протоколі SIP для передачі інформації про функціональні можливості терміналу використовується протокол SDP. Якщо виробник підтримує якийсь особливий алгоритм кодування, то цей алгоритм просто реєструється в організації IANA, неодноразово згадуваної в цій главі.&lt;br&gt;<br /> У протоколі Н.323 всі кодеки повинні бути стандартизовані. Тому програми з нестандартними алгоритмами кодування можуть зіткнутися з проблемами при реалізації їх на базі протоколу Н.323.&lt;br&gt;<br /> Протокол SIP складається з набору закінчених компонентів (модулів), які можуть замінюватися в залежності від вимог і можуть працювати незалежно один від одного. Цей набір включає в себе модулі підтримки сигналізації для базового з'єднання, для реєстрації та для визначення місця розташування користувача, які не залежать від модулів підтримки якості обслуговування (QoS). роботи з директоріями, опису сеансів зв'язку, розгортання послуг (service discovery) та управління конфігурацією.&lt;br&gt;<br /> Архітектура протоколу Н.323 монолітна і являє собою інтегрований набір протоколів для одного застосування. Протокол складається з трьох основних складових, і для створення нової послуги може знадобитися модифікація кожної з цих складових.&lt;br&gt;<br /> Масштабованість мережі (scalablllty). Сервер SIP, за замовчуванням, не зберігає відомостей про поточні сеанси зв'язку і тому може обробити більше викликів, ніж воротар Н.323, який зберігає ці відомості (statefull). Разом з тим, відсутність таких відомостей, на думку деяких фахівців, може викликати труднощі при організації взаємодії мережі IP-телефонії з ТМЗК.&lt;br&gt;<br /> Необхідно також мати на увазі зонову архітектуру мережі Н.323, що дозволяє забезпечити розширюваність мережі шляхом збільшення кількості зон.&lt;br&gt;<br /> Час встановлення з'єднання. Наступною істотною характеристикою протоколів є час, що потрібно, щоб встановити з'єднання. У запиті INVITE протоколу SIP міститься вся необхідна для встановлення з'єднання інформація, включаючи опис функціональних можливостей терміналу. Таким чином, у протоколі SIP для встановлення з'єднання потрібна одна транзакція, а в протоколі Н.323 необхідно проводити обмін повідомленнями кілька разів. З цих причин витрати часу на встановлення з'єднання в протоколі SIP значно менше затрат часу в протоколі Н.323. Правда, при використанні інкапсуляції повідомлень Н.245 в повідомлення Н.225 або процедури Fast Connect час встановлення з'єднання значно зменшується.&lt;br&gt;<br /> Крім того, на час встановлення з'єднання впливає також і нижележащий транспортний протокол, який переносить сигнальну інформацію. &lt;br&gt;Ранні версії протоколу Н.323 передбачали використання для перенесення сигнальних повідомлень Н.225 і Н.245 тільки протокол TCP, і лише третя версія протоколу передбачає можливість використання протоколу UDP. Протоколом SIP використання протоколів TCP і UDP передбачалося з самого початку.&lt;br&gt;<br /> Оцінка часу встановлення з'єднання проводиться в умовних одиницях - RTT (round trip time) - і становить для протоколу SIP 1,5 2,5 RTT, а для протоколу Н .323 6-7 RTT&lt;br&gt;<br /> Адресація. До числа системних характеристик, безсумнівно, і передбачена протоколами адресація. Використання URL є сильною стороною протоколу SIP і дозволяє легко інтегрувати його в існуючу систему DNS-серверів і впроваджувати в устаткування, що працює в IP-мережах. Користувач отримує можливість переправляти виклики на Web-сторінки або використовувати електронну пошту. Адресою в SIP може також служити телефонний номер з адресою використовуваного шлюзу.&lt;br&gt;<br /> У протоколі Н.323 використовуються транспортні адреси і alias-адреси. У якості останнього може використовуватися телефонний номер, ім'я користувача або адресу електронної пошти. Для перетворення alias-адреси в транспортний адресу обов'язково участь воротаря.<br /> Складність протоколу. Протокол Н.323, безсумнівно, складніше протоколу SIP. Загальний обсяг специфікацій протоколу Н.323 становить приблизно 700 сторінок. Обсяг специфікацій протоколу SIP становить 150 сторінок. Протокол Н.323 використовує велику кількість інформаційних полів в повідомленнях (до 100), при декількох десятках таких же полів в протоколі SIP. При цьому для організації базового з'єднання в протоколі SIP досить використовувати всього три типи запитів (INVITE, BYE і АСК) і кілька полів (Те, From, Call-ID, CSeq).&lt;br&gt;<br /> Протокол SIP використовує текстовий формат повідомлень, подібно протоколу HTTP. Це полегшує синтаксичний аналіз і генерацію коду, дозволяє реалізувати протокол на базі будь-якої мови програмування, полегшує експлуатаційне управління, дає можливість ручного введення деяких полів, полегшує аналіз повідомлень. Назва заголовків SIP-повідомлень ясно вказує їх призначення.&lt;br&gt;<br /> Протокол Н.323 використовує двійкове представлення своїх повідомлень на базі мови [[ASN.1]], тому їх безпосереднє читання важко. Для кодування і декодування повідомлень необхідно використовувати компілятор ASN. 1. Але, в той же час, обробка повідомлень, представлених в двійковому вигляді, виробляється швидше.&lt;br&gt;<br /> Досить складним є взаємодія протоколу Н.323 з міжмережевим екраном (firewall). Крім того, в протоколі Н.323 існує дублювання функцій. Так, наприклад, обидва протоколи Н.245 і RTCP мають засоби управління конференцією і здійснення зворотного зв'язку.&lt;br&gt;<br /> Висновки. На основі проведеного вище порівняння можна зробити висновок про те, що протокол SIP більше підходить для використання Internet-постачальниками, оскільки вони розглядають послуги IP-телефонії лише як частина набору своїх послуг.&lt;br&gt;<br /> Оператори телефонного зв'язку, для яких послуги Internet не є першорядними, швидше за все, будуть орієнтуватися на протокол Н.323, оскільки мережа, побудована на базі рекомендації Н.323, представляється їм добре знайомої мережею ISDN, накладеної на IP-мережу.<br /> Не варто також забувати, що до теперішнього часу багато фірм-виробники і постачальники послуг вже вклали значні кошти в обладнання Н.323, яке успішно функціонує в мережах.&lt;br&gt;<br /> Таким чином, відповідь на питання, який з протоколів краще використовувати, буде залежати від цілей бізнесу та необхідних функціональних можливостей. Швидше за все, ці варіанти не слід розглядати як конкуруючі, а як призначені для різних областей ринку послуг, оскільки вони можуть працювати паралельно і взаємодіяти через спеціальний шлюз. Проілюструємо це твердження таким прикладом. В даний час ринок послуг все більше націлюється на послуги з доплатою за додаткові можливості (value added), і простота їх надання дає реальні переваги. Так, використання SIP в будь-якому приватному домені дає можливість більш гнучкого надання послуг, а наявність засобів, що забезпечують перехід від протокола SIP до протоколу Н.323, гарантує взаємодія з областями, які використовують інші рішення. У таблиці 7.6 наведено варіант можливого обміну повідомленнями.&lt;br&gt;<br /> '''Таблиця 7.6''' Алгоритм встановлення з'єднання з участю шлюзу H.323/SIP&lt;br&gt;&lt;br&gt;<br /> Якщо протягом розмовної фази обладнанню Н.323 необхідно відкрити нові логічні канали, шлюз передає нове повідомлення INVITE терміналу SIP, як це показано у таблиці 7.7.&lt;br&gt;&lt;br&gt;<br /> '''Таблиця 7.7''' Відкриття нових логічних каналів&lt;br&gt;<br /> &lt;div style=&quot;background: #33ccff&quot;&gt; <br /> &lt;center&gt;<br /> ----<br /> [ [[Алгоритми_встановлення_з'єднання|&lt;&lt; 7.6 Алгоритми встановлення з'єднання]] ]<br /> ----<br /> &lt;/center&gt;<br /> &lt;/div&gt;<br /> ----<br /> --[[Користувач:Козінцев Олексій|Козінцев Олексій 36 гр.]] 16:46, 29 листопада 2010 (EET)</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%93%D0%BB%D0%BE%D1%81%D0%B0%D1%80%D1%96%D0%B9_%D0%B4%D0%BE_%D1%81%D1%82%D0%B0%D1%82%D1%82%D1%96 2011-12-18T20:59:32Z

<p>Aleksey: </p> <hr /> <div>&lt;div style=&quot;background: #cccccc&quot;&gt; <br /> &lt;center&gt;<br /> ----<br /> [ '''[[Технологія VoIP]]''' ]<br /> ----<br /> &lt;/center&gt;<br /> &lt;/div&gt;<br /> <br /> '''ACELP''' &lt;br&gt;<br /> Algebraic Code-Excited Linear Prediction. Популярний алгоритм компресії мовного сигналу (швидкість передачі 8 Кбіт / с) &lt;br&gt;<br /> '''ADPCM'''&lt;br&gt;<br /> Adaptive Differential РСМ. Адаптивна диференціальна ІКМ &lt;br&gt;<br /> '''API''' &lt;br&gt;<br /> Application Programming Interface. Інтерфейс прикладного програмування. Це набір функцій, за допомогою яких програми взаємодіють з операційною системою для виконання завдань &lt;br&gt;<br /> '''ARP''' &lt;br&gt;<br /> Adress Resolution Protocol. Протокол, що забезпечує динамічне перетворення адрес Інтернет у фізичні (апаратні) адреси обладнання локальної мережі &lt;br&gt;<br /> '''ARPA''' &lt;br&gt;<br /> Advanced Research Projects Agency. Спеціальне агентство при Міністерстві оборони США (Department of Defense - DoD), яка створила мережу ARPANET &lt;br&gt;<br /> '''ASCII''' &lt;br&gt;<br /> American Standard Code for Information Interchange. Американський стандартний код для обміну інформацією &lt;br&gt;<br /> '''[[ASN.1]]''' &lt;br&gt;<br /> Abstract Syntax Notation One. Слеціфікація абстрактної синтаксичної нотації, версія 1. Служить для опису інформаційних об'єктів прикладного рівня &lt;br&gt;<br /> '''BQP''' &lt;br&gt;<br /> Border Gateway Protocol. Однорівневий багатопунктового протокол динамічної міждоменної маршрутизації. При виборі маршруту враховує число пересилань, пропускну здатність каналів і ін Виявляє закольцовиваніе маршрутів. &lt;br&gt;<br /> '''CBQ''' &lt;br&gt;<br /> Class Based Queuing. Організація черг з урахуванням класу траф-ка. Кожен клас має свою чергу, і йому гарантується деяка частка пропускної здатності каналу. Якщо якийсь клас не використовує весь відведений йому ресурс, частка кожного з інших класів пропорційно збільшується. &lt;br&gt;<br /> '''CNG''' &lt;br&gt;<br /> Comfort Noise Generator. Генератор комфортного шуму. Використовується в системах з компресією мовного сигналу для усунення ефекту «гробової тиші» у паузах, коли передача сигналу припиняється, і у слухача створюється ілюзія, що зв'язок перерваний. &lt;br&gt;<br /> '''CS-ACELP''' &lt;br&gt;<br /> Conjugate Structure - Algebraic Code - Excited Linear Prediction. Технологія CS-ASELP застосовується в кодеках G.729, використовуваних для передачі мови по мережах Frame Relay. Забезпечує швидкість передачі 8 Кбіт / с при тривалості кадру 10 мс. &lt;br&gt;<br /> '''CSRC''' &lt;br&gt;<br /> Contributing Source Identifier. Список полів з ідентифікаторами джерел, мовна інформація яких змішується при створенні RTP-пакета. Під час мовленнєвої конференції кожен RTP-пакет містить свій SSRC. &lt;br&gt;<br /> '''DDS'''&lt;br&gt;<br /> DiffServ Differentiated Services. Система диференційованого обслуговування графіка різних класів, розроблена комітетом IETF &lt;br&gt;<br /> '''DNS''' &lt;br&gt;<br /> Domain Name System. Сервер імен доменів в Інтернет, що перетворює ці імена в IP-адреси. &lt;br&gt;<br /> '''DSP''' &lt;br&gt;<br /> Digital Signal Processor. Процесор цифрової обробки сигналів. &lt;br&gt;<br /> '''DTMF''' &lt;br&gt;<br /> Dual Tone Multi-Freqency. Багаточастотна система кодування цифр номера. Є дві групи частот, і цифра кодується двома частотами з різних груп.&lt;br&gt; <br /> '''DTX'''&lt;br&gt;<br /> Discontinuous Transmission. Переривається передача. Кодек припиняє передачу пакетів, коли детектор мовної активності виявляє паузу в мові. &lt;br&gt;<br /> '''DVMRP''' &lt;br&gt;<br /> Distance Vector Multicast Routing Protocol. Один з основних протоколів, на базі яких реалізується багатоадресна розсилка в IP-мережах. <br /> &lt;br&gt;<br /> '''Е1''' &lt;br&gt;<br /> Цифрова система передачі зі швидкістю 2.048 Мбіт / с, використовувана в Росії та інших європейських країнах. &lt;br&gt;<br /> '''ЕСМА''' &lt;br&gt;<br /> European Computer Manufacturer's Association. Асоціація європейських виробників комп'ютерів. &lt;br&gt;<br /> '''Е1А''' &lt;br&gt;<br /> Electronic Industries Association. Асоціація електронної промисловості. Група, яка розробляє стандарти передачі даних. Розробник ряду комунікаційних стандартів, в тому числі, стандарти Е1А/Т1А-232 і Е1А/Т1А-449. &lt;br&gt;<br /> '''ETSI''' &lt;br&gt;<br /> European Telecommunication Standards Institute. Європейський інститут стандартів у галузі зв'язку. &lt;br&gt;<br /> '''FIFO''' &lt;br&gt;<br /> First In, First Out. Дисципліна обслуговування, при якій перший обслуговується та заявка, яка першою вступила в чергу. &lt;br&gt;<br /> '''FTP'''&lt;br&gt; <br /> File Transfer Protocol. Протокол передачі файлів. GCP Gateway Control Protocol. Протокол управління шлюзом.&lt;br&gt; <br /> '''GK''' &lt;br&gt;<br /> Gatekeeper. Сторож. Виконує функції управління зоною мережі Н.323. &lt;br&gt;<br /> '''GW''' &lt;br&gt;<br /> Gateway. Шлюз. Апаратно-програмний комплекс, що забезпечує обмін даними між мережами різних типів. &lt;br&gt;<br /> '''Н.323''' &lt;br&gt;<br /> Рекомендація ITU-T, яка визначає системи мультимедійного зв'язку в мережах з пакетною комутацією, що не забезпечують гарантовану якість обслуговування &lt;br&gt;<br /> '''ICMP''' &lt;br&gt;<br /> Internet Control Message Protocol Протокол керуючих повідомлень в Інтернет. Надає програмного забезпечення робочої станції або маршрутизатора можливість обмінюватися з іншими пристроями інформацією, що відноситься до маршрутизації пакетів. Є необхідною частиною стека протоколів TCP / IP. &lt;br&gt;<br /> '''IDCP''' &lt;br&gt;<br /> IP Device Control Protocol. Протокол управління обладнанням, що реалізують технологію маршрутизації пакетів IP. Запропоновано фірмою Level 3.&lt;br&gt;<br /> '''IEEE''' &lt;br&gt;<br /> Institute of Electrical and Electronics Engineers. Інститут інженерів електротехнічної та електронної галузей. Веде дослідження в галузі зв'язку та розробляє комунікаційні та мережеві стандарти. &lt;br&gt;<br /> '''IETF''' &lt;br&gt;<br /> Internet Engineering Task Force. Група інженерних проблем Інтернет. Включає в себе більше 80 самостійних підгруп, відповідає за розробку стандартів для Інтернет. Встановлює пріоритети і виробляє рішення по короткострокових питань і проблем, включаючи протоколи, архітектуру та експлуатацію. Працює під егідою ISO. &lt;br&gt;<br /> '''IP''' &lt;br&gt;<br /> Internet Protocol. Протокол міжмережевої взаємодії. &lt;br&gt;<br /> '''IPOP''' &lt;br&gt;<br /> Internet Point of Presence. Точка присутності постачальника послуг Інтернет в комутаційному обладнанні. &lt;br&gt;<br /> '''ISO''' &lt;br&gt;<br /> International Organization for Standardization. ISO - це не просто абревіатура: грецьке слово / so означає «рівний». ISO Заснована в 1946 р. і являє собою міжнародну організацію, що об'єднує більше 75 національних бюро різних країн. Розробила найважливіші стандарти, в тому числі і комп'ютерні. &lt;br&gt;<br /> '''ISP''' &lt;br&gt;<br /> Internet Service Provider. Постачальник послуг Інтернет. Компанія, що надає доступ в Інтернет іншим компаніям або приватним особам. &lt;br&gt;<br /> '''ГГО-Т''' &lt;br&gt;<br /> International Telecommunications Union Telecommunication Standardization Sector. Сектор Міжнародного Союзу Електрозв'язку, розробляє рекомендації у сфері телекомунікацій. Виконує функції колишнього CCITT (МККТТ). &lt;br&gt;<br /> '''LDP''' &lt;br&gt;<br /> Label Distribution Protocol. Протокол розподілу міток. Підтримує процедури «роздачі» та погодження міток між маршрутизаторами мережі MPLS. &lt;br&gt;<br /> '''LER''' &lt;br&gt;<br /> Label Edge Router. Прикордонний маршрутизатор мережі MPLS. &lt;br&gt;<br /> '''LPC''' &lt;br&gt;<br /> Linear Prediction Coding. Кодування з лінійним передбаченням. &lt;br&gt;<br /> '''LSP''' &lt;br&gt;<br /> Label Switched Path. Комутований по мітках тракт. &lt;br&gt;<br /> '''LSR''' &lt;br&gt;<br /> Label Switching Router. Маршрутизатор комутації по мітках. &lt;br&gt;<br /> '''MCU''' &lt;br&gt;<br /> Multipoint Control Unit. Пристрій управління конференцією. Забезпечує узгодження функціональних можливостей учасників конференції, тобто алгоритмів, використовуваних кожним з них для кодування мови, відеоінформації та даних; може транскодіровать інформацію будь-якого виду, якщо термінали, які беруть участь у конференції, використовують різні алгоритми кодування; в процесі узгодження вибирає режим конференції. Виробляє змішування чи комутацію інформації, прийнятої від учасників, і його розподіл. &lt;br&gt;<br /> '''MEGACO/Н.248''' &lt;br&gt;<br /> Протокол керування транспортним шлюзом. Створений робочою групою MEGACO комітету IETF. &lt;br&gt;<br /> '''MG''' &lt;br&gt;<br /> Media Gateway. Транспортний шлюз. &lt;br&gt;<br /> '''MGCP''' &lt;br&gt;<br /> Media Gateway Control Protocol. Протокол управління шлюзами. &lt;br&gt;<br /> '''MOS''' &lt;br&gt;<br /> Mean Opinion Score. Характеристика якості передачі мови із застосуванням кодека того чи іншого типу, одержувана як середнє значення результатів оцінки якості великою групою експертів за п'ятибальною шкалою. &lt;br&gt;<br /> '''МР''' &lt;br&gt;<br /> Multipoint processor. Процесор для обробки інформації користувачів при централізованих конференціях. &lt;br&gt;<br /> '''MPLS''' &lt;br&gt;<br /> Multi-Protocol Label Switching. Багатопротокольна комутація по мітках. Заснована на тому, що пакети, що надходять у прикордонний маршрутизатор мережі MPLS ззовні, поділяються на «класи еквівалентності пересилки». Кожному класу призначається система міток - коротких заголовків, що використовуються для маршрутизації пакетів всередині мережі MPLS замість довгих заголовків мережевого рівня.&lt;br&gt; <br /> '''Multicasting'''&lt;br&gt;<br /> Багатоадресна розсилка інформації (аудіо, відео або даних). &lt;br&gt;<br /> '''OPWA''' &lt;br&gt;<br /> One Path With Advertising. Варіант алгоритму, який підтримується протоколом RSVP. За допомогою OPWA інформація керуючих пакетів RSVP може бути використана для передбачення «наскрізного» QoS усього маршруту. &lt;br&gt;<br /> '''OSI''' &lt;br&gt;<br /> Open System Interconnection. Взаємодія відкритих систем. Створена ISO і ITU-T міжнародна програма розробки стандартів мережевої передачі даних. &lt;br&gt;<br /> '''POTS''' &lt;br&gt;<br /> Plain Old Telephone Service. Послуги традиційної телефонії. &lt;br&gt;<br /> '''РРР''' &lt;br&gt;<br /> Point-to-Point Protocol. Протокол двостороннього зв'язку. Використовується при зв'язку через Інтернет. Реалізує обмін пакетами між комп'ютерами або іншими пристроями &lt;br&gt;<br /> '''PSTN''' &lt;br&gt;<br /> Public Switched Telephone Network. Телефонна мережа загального користування (ТФОП ^. Загальний термін, використовуваний для позначення телефонних мереж в усьому світі. &lt;br&gt;<br /> '''QCIF''' &lt;br&gt;<br /> Quarter-Common Intermediate Format. Обов'язковий формат зображень, який повинні забезпечувати кодеки. &lt;br&gt;<br /> '''QoS''' &lt;br&gt;<br /> Quality of Service. Якість обслуговування (послуги). &lt;br&gt;<br /> '''Router''' &lt;br&gt;<br /> Маршрутизатор. Програмно-апаратний пристрій, який направляє інформацію користувача за маршрутом, ведучому до адресата. Веде статистику використання ресурсів мережі, забезпечує певний рівень захисту інформації. &lt;br&gt;<br /> '''RADIUS''' &lt;br&gt;<br /> Remote Authentication Dial-In User Service. Протокол аутентифікації та авторизації абонентів, а також убета обсягу наданих їм послуг. &lt;br&gt;<br /> '''RAS''' &lt;br&gt;<br /> Registration Admission and Status. Протокол взаємодії термінального обладнання з воротарем. Входить в сімейство протоколів Н.323. &lt;br&gt;<br /> '''RSVP''' &lt;br&gt;<br /> Resource Reservation Protocol. Протокол резервування ресурсів. &lt;br&gt;<br /> '''RTCP''' &lt;br&gt;<br /> Real-time Transport Control Protocol. Протокол контролю транспортування інформації в реальному часі. Організовує зворотний зв'язок одержувача інформації з її відправником, використовувану для обміну відомостями про кількість переданих і втрачених пакетів, про затримку, її джиттера і т.д. Ці відомості відправник може використовувати для зміни параметрів передачі з метою поліпшити QoS (наприклад, зменшити коефіцієнт стиснення інформації). &lt;br&gt;<br /> '''RTP''' &lt;br&gt;<br /> Real Time Transport Protocol. Протокол транспортування в реальному часі. Служить базисом практично для всіх додатків, пов'язаних з інтерактивним обміном мовної і відео у IP-мережі. Дозволяє компенсувати негативний вплив джитер на якість передачі такої інформації, але не гарантує своєчасну доставку пакетів (за це відповідають нижележащие протоколи) і не виконує функцій виправлення помилок і управління потоком. Зазвичай базується на протоколі UDP і використовує його можливості, але може працювати і поверх інших транспортних протоколів. &lt;br&gt;<br /> '''SGSP''' &lt;br&gt;<br /> Simple Gateway Control Protocol. Простий протокол керування шлюзами. Розроблено компанією Telecordia (колишня компанія Bellcore). &lt;br&gt;<br /> '''SIP''' &lt;br&gt;<br /> Session Initiation Protocol. Протокол ініціювання сеансів зв'язку. Є протоколом прикладного рівня і призначається для організації, зміни та припинення сеансів зв'язку - мультимедійних конференцій, телефонних з'єднань і з'єднань користувачів з різноманітними програмами. &lt;br&gt;<br /> '''SNMP''' &lt;br&gt;<br /> Simple Network Management Protocol. Простий протокол експлуатаційного управління мережею. &lt;br&gt;<br /> '''TAPI''' &lt;br&gt;<br /> Telephony Applications Programming Interface. Інтерфейс для програмування телефонних додатків. Це - стандартний програмний інтерфейс для створення додатків комп'ютерної телефонії в середовищі Windows, що визначає набір функцій, які необхідні програмі для взаємодії з телефонами, лініями і комутаторами. Стандарт TAPI використовується при розробці програм для робочих станцій, що виконують усі інтелектуальні дії. &lt;br&gt;<br /> '''TCP''' &lt;br&gt;<br /> Transmission Control Protocol. Протокол управління передачею (даних). Основний транспортний протокол у стеку протоколів TCP / IP. Встановлює зв'язок між двома комп'ютерами та організовує надійний обмін даними в дуплексному режимі. &lt;br&gt;<br /> '''TCP/IP''' &lt;br&gt;<br /> Transmission Control Protocol / Internet Protocol. Стек протоколів, які забезпечують організацію зв'язку між комп'ютерами в мережі Інтернет. Вбудований в операційну систему UNIX і широко використовується при операціях в мережі Інтернет, будучи de facto мережевим стандартом для передачі даних. Навіть ті мережеві операційні системи, які мають власні протоколи, підтримують також і TCP / IP. &lt;br&gt;<br /> '''TIPHON''' &lt;br&gt;<br /> Telecommunications and Internet Protocol Harmonisation Over Networks. Проект під егідою ETSI (розпочато в 1997 р), в якому бере участь понад 40 великих компаній. Мета проекту - підтримка ринку, що передбачає поєднання телекомунікаційних послуг мереж з комутацією каналів і мереж з комутацією пакетів. &lt;br&gt;<br /> '''Т8АР1''' &lt;br&gt;<br /> Telephony Services Application Programming Interface. API для створення телефонних послуг. Розроблено Novell і AT &amp; T. Дозволяє програмістам конструювати телефонні і CTI-додатки. Аналогічний TAPI, але, на відміну від нього, функціонує на платформах Netware. Інша відмінність - TAPI використовується як для клієнтських, так і для серверних додатків, a TSAPI призначений виключно для сервера. &lt;br&gt;<br /> '''UAC''' &lt;br&gt;<br /> User Agent Client. Агент користувача - клієнт. Прикладна програма, яка ініціює SIP-запит. &lt;br&gt;<br /> '''UAS''' &lt;br&gt;<br /> User Agent Server. Агент користувача - сервер. Прикладна програма, яка приймає запит і від імені користувача повертає відповідь з інформацією про те, що запит приймається, не приймається або переадресується. &lt;br&gt;<br /> '''UDP''' &lt;br&gt;<br /> User Datagram Protocol. Протокол передачі дейтаграм користувача. Подібно TCP, використовує для доставки даних протокол IP. На відміну від TCP / IP, передбачає обмін дейтаграммами без підтвердження (тобто доставка не гарантується). &lt;br&gt;<br /> '''VAD''' &lt;br&gt;<br /> Voice Activity Detector. Детектор мовної активності. Використовується в кодеках із стискуванням мовної інформації для визначення моменту закінчення паузи в мові. &lt;br&gt;<br /> '''VolP''' &lt;br&gt;<br /> Voice over Internet Protocol. Технологія, що дозволяє використовувати IP-мережу для передачі мовної інформації. &lt;br&gt;<br /> '''WFQ''' &lt;br&gt;<br /> Weighted Fair Queuing. Зважена справедлива черга. Один з алгоритмів керування обслуговуванням черг.&lt;br&gt;<br /> &lt;div style=&quot;background: #cccccc&quot;&gt; <br /> &lt;center&gt;<br /> ----<br /> [ '''[[Технологія VoIP]]''' ]<br /> ----<br /> &lt;/center&gt;<br /> &lt;/div&gt;<br /> <br /> ----<br /> --[[Користувач:Козінцев Олексій|Козінцев Олексій 36 гр.]] 13:11, 29 листопада 2010 (EET)</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A0%D1%96%D0%B2%D0%BD%D1%96_%D0%B0%D1%80%D1%85%D1%96%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B8_%D0%86%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82 2011-12-18T20:58:16Z

<p>Aleksey: </p> <hr /> <div>&lt;div style=&quot;background: #33ccff&quot;&gt; <br /> '''[[Технологія VoIP]]''' &gt;&gt; <br /> '''[[Розділ_4._Протоколи_мережі_Інтернет|Розділ 4. Протоколи мережі Інтернет]]'''<br /> &lt;center&gt;<br /> ----<br /> [ [[Адресація|&lt;&lt; 4.3 Адресація]] ]<br /> [ [[Протокол_IP_версії 4|4.5 Протокол IP версії 4 &gt;&gt;]] ]<br /> ----<br /> &lt;/center&gt;<br /> &lt;/div&gt;<br /> '''4.4 Рівні архітектури Інтернет'''&lt;br&gt;<br /> Функціонування мережі Інтернет засноване на складному комплексі протоколів, які забезпечують виконання різних функцій - від безпосередньо передачі даних до управління конфігурацією устаткування мережі.&lt;br&gt;<br /> Для того, щоб класифікувати різні протоколи і зрозуміти їх місце в загальній структурі технології міжмережевого взаємодії, зручно скористатися так званим «багаторівневим поданням мережевих протоколів». У рамках такого подання мається на увазі, що протоколи більш високого рівня використовують функції протоколів більш низького рівня. Класичною, хоча і представляє зараз, швидше, академічний інтерес, моделлю такого роду є семирівнева модель взаємодії відкритих систем (Open Systems Interconnection - OSI), розроблена ITU-T в рамках невдалої спроби створити міжнародний стандарт сімейства мережевих протоколів. Разом з тим, деякі результати даного проекту є гарним матеріалом для підручників, чим ми і скористаємося.&lt;br&gt;<br /> Рис. 4.1 ілюструє взаємини архітектури Інтернет, визначеної ARPA, з моделлю OSI, а також пояснює функції кожного з рівнів.&lt;br&gt;<br /> Архітектура Інтернет була розроблена агентством ARPA для з'єднання комп'ютерів в державних, військових, академічних та інших організаціях, в основному, на території США, що зумовило її практичний характер. З іншого боку, модель OSI охоплювала більш широке коло питань передачі інформації, і в її рамках не був конкретизований тип взаємодіючих систем, що породило більш «дробове» розбиття на рівні. Однак між тією і іншою архітектурою є очевидне відповідність.&lt;br&gt;<br /> Перший рівень моделі ARPA - рівень мережевого інтерфейсу-підтримує фізичний перенесення інформації між пристроями в мережі, тобто поєднує функції двох рівнів OSI - фізичного і ланки даних. Рівень мережевого інтерфейсу забезпечує фізичне з'єднання з середовищем передачі, забезпечує, якщо це необхідно, дозвіл конфліктів, що виникають у процесі організації доступу до середовища (наприклад, використовуючи технологію CSMA / CD в мережі Ethernet), упаковує дані в пакети. Пакет2-це протокольна одиниця, яка містить інформацію верхніх рівнів, і службові поля (апаратні адреси, порядкові номери, підтвердження і т.д.), необхідні для функціонування протоколів цього рівня.&lt;br&gt;<br /> &lt;center&gt;<br /> [[Файл:VoIP_4.1.png]]&lt;br&gt;<br /> '''Рис. 4.1.''' Рівні моделі OSI та архітектури Інтернет<br /> &lt;/center&gt;&lt;br&gt;<br /> <br /> Мережевий рівень відповідає за передачу інформації, упакованої в дейтаграми (datagram), від одного комп'ютера до іншого. Дейтаграмма - це протокольна одиниця, якою оперують протоколи сімейства TCP / IP. Вона містить адресну інформацію, необхідну для перенесення дейтаграми через мережу, а не тільки в рамках однієї ланки даних. Поняття дейтаграми ніяк не пов'язано з фізичними характеристиками мереж і каналів зв'язку, що підкреслює незалежність протоколів TCP / IP від апаратури. Основним протоколом, реалізує функції мережевого рівня, є протокол IP. Цей протокол відповідає за маршрутизацію, фрагментацію і збірку дейтаграм у робочій станції.&lt;br&gt;<br /> Обмін між мережними вузлами інформацією про стан мережі, необхідної для формування оптимальних маршрутів слідування дейтаграм, забезпечують протоколи маршрутизації - RIP, EGP, BGP, OSPF та ін&lt;br&gt;<br /> 2 Іноді при розгляді протоколів цього рівня (Ethernet, HDLC) вживається також термін кадр (frame).&lt;br&gt;<br /> Протокол перетворення адрес (Address Resolution Protocol-ARP) перетворить IP-адреси в адреси, що використовуються в локальних мережах (наприклад, Ethernet). На деяких малюнках, що зображають архітектуру і взаємозв'язок протоколів, ARP розміщують нижче IP, щоб показати його тісний взаємозв'язок з Рівнем Мережевого Інтерфейсу.&lt;br&gt;<br /> Протокол контрольних повідомлень - Internet Control Message Protocol (ICMP) надає можливість програмного забезпечення робочої станції або маршрутизатора обмінюватися інформацією про проблеми маршрутизації пакетів з іншими пристроями в мережі. Протокол ICMP - необхідна частина реалізації стека протоколів TCP / IP.&lt;br&gt;<br /> Коли шлюзу проходить по мережі, вона може бути втрачена або спотворена. Транспортний рівень вирішує цю проблему і забезпечує надійну передачу інформації від джерела до приймача. Крім того, реалізації протоколів цього рівня утворюють універсальний інтерфейс для додатків, що забезпечує доступ до послуг мережевого рівня. Найбільш важливими протоколами транспортного рівня є TCP і UDP.&lt;br&gt;<br /> Кінцеві користувачі взаємодіють з комп'ютером на рівні додатків. Розроблено безліч протоколів, використовуваних відповідними додатками. Наприклад, програми передачі файлів використовують протокол FTP. Web-додатки використовують протокол HTTP. Обидва протоколу FTP і HTTP базуються на протоколі TCP. Додаток Telnet забезпечує підключення віддалених терміналів. Протокол експлуатаційного управління мережею [[SNMP]] дозволяє керувати конфігурацією обладнання в мережі і збирати інформацію про його функціонуванні, у тому числі, і про аварійних ситуаціях. Програми, створені для організації мовного зв'язку і відеозв'язку, використовують протокол Rтр для передачі інформації, чутливої до затримок. Х Window - популярний протокол для підключення до інтелектуального графічному терміналу. Цей список можна продовжувати практично нескінченно.&lt;br&gt;<br /> Таким чином, IP-мережі використовують для передачі інформації різноманітні протоколи, причому функції протоколів не залежать від того, які дані передаються. Іншими словами, IP, ARP, ICMP, TCP, UDP і інші елементи стека протоколів TCP / IP надають універсальні засоби передачі інформації, якою б вона не була природи (файл по FTP, Web - сторінка або аудіодані).&lt;br&gt;<br /> &lt;div style=&quot;background: #33ccff&quot;&gt; <br /> &lt;center&gt;<br /> ----<br /> [ [[Адресація|&lt;&lt; 4.3 Адресація]] ]<br /> [ [[Протокол_IP_версії 4|4.5 Протокол IP версії 4 &gt;&gt;]] ]<br /> ----<br /> &lt;/center&gt;<br /> &lt;/div&gt;<br /> --[[Користувач:Козінцев Олексій|Козінцев Олексій 36 гр.]] 05:11, 20 листопада 2010 (EET)</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A0I%D0%A5_Firewall 2011-12-18T20:57:42Z

<p>Aleksey: </p> <hr /> <div>== Міжмережевий екран РIХ Firewall ==<br /> <br /> '''Міжмережевій екран''' ''Cisco Private Internet Exchange (PIX) Firewall'' дозволяє реалізовувати захист корпоративних мереж на недосяжному раніше рівні, маючи при цьому високу простоту в експлуатації. PIX Firewall може забезпечувати абсолютну безпеку внутрішньої мережі, повністю приховати її від зовнішнього світу. На відмінну від загальних proxy-серверів, які виконують обробку кожного мережевого пакету окремо від суттєвого заваниаження центрального процесора, PIX Firewall використовує спеціальну не UNIX-подібну операційну систему реального часу, забезпечуючу більш високу продуктивність.<br /> <br /> Основою високої продуктивності міжсіткового екрану PIX Firewall є схема захисту, базуючись на використанні алгоритму адаптивної безпеки (''adaptive security algorithm - ASA''), який ефективно приховує адреси користувачів від хакерів. Цей стійкий алгоритм забезпечує безпеку на рівні з'єднання на основі контролю інформації про адреси відправника і одержувача, послідовності нумерації пакетів TCP, номери портів і додаткові флаги TCP. Ця інформація зберігається в таблиці, перевірку на відповідність з записами якої проходят всі вхідні пакети. Доступ через PIX дозволено тільки в том випадку, якщо з'єднання успішно пройшло ідентифікацію. Цей метод забезпечує прозорий доступ для внутрішніх користувачів і авторизованих зовнішніх користувачів, повністю захищаючи внутрішню мережу від несанкціонованого доступу.<br /> <br /> Завдяки технології &quot;наскрізного посередника&quot; (''Cut-Through Proxy'') міжмережевий екран ''Cisco PIX Firewall'' також забезпечує сутєві переваги в використанні порівняно з екранами-&quot;посередниками&quot; на базі ОС UNIX. Як і прості proxy-сервера, PIX контролює установку з'єднання на рівні додатка. Після успішного проходження користувачем авторизації доступу відповідно з принятими правилами безпеки PIX забезпечує контроль потоку даних між абонентами на рівні сессії. Така технологія дозволяє міжмережевому екранові PIX працювати набагато швидше, ніж прості proxy-екрани.<br /> <br /> Завдяки підвищенню продуктивності, додаток спеціалізованої вмонтованої операційної системи реального часу також забезпечує піднімання рівня безпеки. На відміну від операційних систем сімейства UNIX, даний текст яких широко доступний, Cisco PIX - власна розробка компанії, створена спеціально для рішення задач забезпечення безпеки.<br /> <br /> Для підняття надійності міжмережевий екран ''PIX Firewall'' передбачає можливість встановлення в здвоєній конфігурації в режимі &quot;гарячого резервування&quot;, за рахунок чого в мережі виключається наявнысть єдиної точки можливого збою. Якщо два PIX-екрани будуть працювати в паралельному режимі й один з них вийде з ладу, то другий у прозорому режимі &quot;підхоплюючого&quot; виконання всіх функцій забезпечення безпеки.<br /> <br /> ==Висока продуктивність==<br /> <br /> Міжмережевий екран ''Cisco PIX Firewall'' підтримує більше 256 тисяч одночасних з'єднань і, відповідно, забезпечує підтримку сотень і тисяч користувачів без зниження продуктивності. Повністю завантажений FIX Firewall забезпечує пропускну здатність до 240 Мбіт/с, тобто набагато вище за любий міжмережевий екран, на базі ОС UNIX або ОС Microsoft Windows NT.<br /> <br /> ==Низька вартість використання і впровадження==<br /> <br /> Користувачі, що не мають спеціальної підготовки, можуть настроїти PIX менш ніж за 5 хвилин. Для спрощеня подальшої настройки, в комплект поставки PIX Firewall входит проста у використані графічна оболонка Security Manager. Cisco також пропонує адаптер шифрування Cisco PIX Private Link encryption card. При встановлені цього адаптера в PIX Firewall забезпечується можливість передачі через IP-мережі загального користування, наприклад, Інтернет, закодованих IP-пакетів із використанням стандартної технології IPSec і протоколів IETF, наприклад, АН (Authentication Header) і ESP (Encapsulating Security Payload).<br /> <br /> ==Рішення проблеми недостачі IP-адрес==<br /> <br /> Міжмережевий екран Cisco PIX Firewall також дозволяє уникнути проблеми недостачі адрес при розширенні і зміні IP-мереж. Технологія трансляції мережевих адрес Network Address Translation (NAT) робить можливим використання в приватній мережі як існуючих адрес, так і резервних адресних просторів. PIX також можна налаштувати для загального використання транслюючих і не транслюючих адрес, дозволючи використовувати як адресний простір приватної IP-мережі, так і зареєстровані IP-адреси.<br /> <br /> ==Основні можливості==<br /> <br /> Чітка система захисту від несанкціонованого доступу на рівні з'єднання забезпечує безпеку ресурсів внутрішньої мережі.<br /> <br /> Технологія Cut Through Proxy дозволяє контролювати як вхідні, так і вихидні з'єднання на базі таких протоколів безпеки, як Terminal Access Controller Access Control System (TACACS) або Remote Access Dial-In User Service(RADIUS).<br /> <br /> До шести мережевих інтерфейсів для розширення правил захисту.<br /> <br /> Графічний інтерфейс адміністратора Security Manager презначений, для настройки до 100 міжмережевих екранів PIX з єдиною консолі.<br /> <br /> Динамічна і статична трансляції адрес.<br /> <br /> Підтримка протоколу мережевого управління [[SNMP]].<br /> <br /> Текуча інформація з використанням ведення журналу системних подій (syslog).<br /> <br /> Прозора підтримка всіх основних мережевих послуг, таких як World Wide Web (WWW), File Transfer Protocol (FTP), Telnel, Archie, Gopher.<br /> <br /> Підтримка мультимедіа додатків, включаючи Progressive Networks RealAudio &amp; Read-Video, Xing StreamWorks, White Pines CU-SeeMe, Vocal Tec Internet Phone, VDOnet VDOLive, Microsoft NetShow і VXtreme Web Theater.<br /> <br /> Безпечна вмонтована операційна система реального часу.<br /> <br /> Відсутня необхідність обновлення ПЗ на робочих станціях і маршрутизаторах.<br /> <br /> Повний доступ до ресурсів мережі Інтернет для незареєстрованих користувачів внутрішньої мережі.<br /> <br /> Сумісність з маршрутизаторами, працюючими під управлінням Cisco IOS™.<br /> <br /> Підтримка відеоконференцій по протоколу Н.323, включаючи Microsoft NetMeeting, Intel Internet Video Phone и White Pine Meeting Point.<br /> <br /> Декілька можливих варіантів програмної та апаратної комплектації.<br /> <br /> Засоби централізованого адміністрування.<br /> <br /> Повідомлення про важливі події на пейджер або по електронній пошті.<br /> <br /> Підтримка інтерфейсів Ethernet, Fast Ethernet, Token Ring и FDDI.<br /> <br /> Підтримка віртуальних власних мереж (VirTual Private Network) із використанням стан-дартної технології IPSec.<br /> <br /> Висока продуктивність.<br /> <br /> Інтеграція з іншими рішеннями компанії Cisco, наприклад, із сервером ідентифіка-ції користувачів CiscoSeсure.</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%9F%D0%B5%D1%80%D0%B5%D0%B2%D0%B0%D0%B3%D0%B8_%D1%96_%D0%BD%D0%B5%D0%B4%D0%BE%D0%BB%D1%96%D0%BA%D0%B8 2011-12-18T20:57:22Z

<p>Aleksey: </p> <hr /> <div>'''Переваги'''<br /> <br /> Надійність<br /> <br /> o Подвійна кільцева конфігурація забезпечує надмірність.<br /> <br /> o Система здатна справлятися з одиничними і множинними обривами, сегментуючи ділянки.<br /> <br /> Відмовостійкість<br /> <br /> o Подвійне підключення (Dual Homing): враховує надмірне з'єднання з FDDI мережею в топології дерева. DAS станція може мати подвійне підключення, для цього А і B порти підключають до різних концентраторів. Якщо виникають збої головного порту, активізується резервний зв'язок.<br /> <br /> o Оптичний обхід: ця можливість гарантує, проходження світлового сигналу при збоях в живленні DAS станції. Дані просто обходять неактивну станцію, проходячи через оптичний обхід.<br /> <br /> o Глобальне зберігання: якщо обидва логічні кільця робочі і в системі обнаружевается несправність в одному з логічних кілець, то поточні дані без втрати прямують по резервному кільцю.<br /> <br /> <br /> Вбудоване управління<br /> <br /> o Кожен вузол має об'єкт управління, надаючи велике число служб.<br /> <br /> o Завдяки наявності обширної [[MIB]] є можливість [[SNMP]] управління.<br /> <br /> '''Недоліки'''<br /> <br /> Ціна<br /> <br /> Висока ціна обумовлена дорогими трансиверами, що перетворюють електричний сигнал в оптичний і навпаки.<br /> <br /> Оптоволоконна технологія: ~ 700 $ / порт<br /> <br /> UTP: ~ 450 $ / порт</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A2%D0%B8%D0%BF%D0%BE%D0%B2%D1%96_%D0%BF%D0%BE%D0%BC%D0%B8%D0%BB%D0%BA%D0%BE%D0%B2%D1%96_%D1%81%D0%B8%D1%82%D1%83%D0%B0%D1%86%D1%96%D1%97:_%D0%B2%D0%BF%D0%BB%D0%B8%D0%B2_%D0%BD%D0%B0_%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D1%96%D1%81%D1%82%D1%8C_%D1%82%D0%B0_%D0%B4%D1%96%D0%B0%D0%B3%D0%BD%D0%BE%D1%81%D1%82%D0%B8%D0%BA%D0%B0 2011-12-18T20:56:56Z

<p>Aleksey: </p> <hr /> <div>=== Типові помилки в кадрах ===<br /> Помилки у роботі програмного і апаратного забезпечення мережі зазвичай надають безпосередній та значний вплив на продуктивність мережі, оскільки час, затрачуваний на ліквідацію наслідків помилок, є втраченим для виконання нормальних операцій.<br /> ==== Помилки в кадрах, зв'язані з колізіями ====<br /> Нижче наведені типові помилки, викликані колізіями, для кадрів протоколу Ethernet: <br /> <br /> * ''Локальна колізія (LocalCollision)''. Є результатом одночасної передачі двох або більше вузлів, які належать до того сегменту, в якому проводяться виміри. Якщо мережевий аналізатор не генерує кадри, то в мережі 10Base-T (на скручений парі) локальні колізії не фіксуються. Занадто високий рівень локальних колізій є наслідком проблем із кабельної системою.<br /> <br /> *''Віддалена колізія (RemoteCollision)''. Ці колізії відбуваються на інщій стороні повторювача. Оскільки концентратор 10Base-T є багатопортовим повторювачем, в якому кожен сегмент закріплений за одним вузлом, то всі вимірювані колізії в мережі 10Base-T є видаленими (крім тих випадків, коли аналізатор сам генерує кадри і може бути винуватцем колізії). Не всі аналізатори протоколів і моніторингу однаковим чином фіксують віддалені колізії. Це відбувається через те, що деякі вимірювальні засоби і системи не фіксують колізії, що відбуваються при передачі преамбули.<br /> <br /> *''Пізня колізія (Late Collision)''. Це колізія, що відбувається після передачі перших 64 байт кадру. Результатом пізньої колізії буде пакет, який має довжину понад 64 байт і містить неправильне значення контрольної суми. Цей пакет обов'язково був згенерований в локальному сегменті. Найчастіше це вказує на те, що мережевий адаптер, який є джерелом конфлікту, виявляється не в змозі правильно прослуховувати лінію і не може вчасно зупинити свою передачу.<br /> <br /> ==== Діагностика колізій ====<br /> Середня інтенсивність колізій в нормально працюючій мережі має бути менше 5%. Великі сплески (понад 20%) можуть бути індикатором кабельних проблем.<br /> <br /> Якщо інтенсивність колізій більше 10%, то уже треба проводити дослідження мережі.<br /> <br /> Рекомендується наступний порядок дослідження:<br /> <br /> *Якщо це можливо, розділіть мережу на функціонально незалежні частини і досліджуйте кожну частина за допомогою аналізатора протоколів. <br /> *З допомогою генератора трафіка створіть фоновий трафік невеликої інтенсивності (100 кадрів в секунду) і спостерігайте за результатами вимірів. <br /> *Плавно збільшуйте среднню інтенсивність трафіку та одночасно заміряйте рівень помилок і колізій.<br /> <br /> Рішення проблем, пов'язаних з колізіями є досить складним завданням, оскільки результати спостережень залежать від точки підключення мережного аналізатора. Тому потрібно робити багато вимірів різних точках.<br /> <br /> У мережі Ethernet на основі коаксіального кабелю в якості причин колізій можуть виступати:<br /> <br /> *Занадто велика довжина сегментів (понад 185 метрів для тонкого коаксиала і понад 500 метрів для товстого); <br /> *Занадто багато підключень до сегменту (понад 30 для тонкого коаксиала); <br /> *Занадто багато заглушок - необхідно перевірити, щоб сегмент завершувався заглушкою в 50 Ом лише в одному місці (багатопортові повторювачі для коаксіального кабелю зазвичай мають внутрішні заглушки, тому установка зовнішньої заглушки для них є зайвою); *Неправильное заземлення - кожен коаксіальний сегмент має заземлення лише в одній точці.<br /> <br /> Причинами колізій в мережі Ethernet на кручений парі можуть бути:<br /> <br /> *Занадто велика довжина сегментів (понад 100 метрів); <br /> *Порушення правил 4-х хабів; <br /> *Неправильне з'єднання контактів пар кабелю; <br /> *Некоректно працюють порти концентратора чи мережні адаптери; <br /> *Погані з'єднання в кросових секціях.<br /> <br /> ==== Помилки кадрів Ethernet, пов'язані з довжиною і неправильною контрольною сумою ====<br /> *Укорочені кадри (Shortframes). Це кадри, які мають довжину, менше допустимої, тобто менше 64 байт. Іноді цей тип кадрів диференціюють на два класи - просто короткі кадри (short), в яких є коректна контрольна сума, і &quot;коротишки&quot; (runts), що не мають коректної контрольної суми. Найімовірнішими причинами появи коротких кадрів є несправні мережні адаптери та драйвери.<br /> <br /> *Подовжені кадри (Jabbers). Це кадри, які мають довжину, що перевищує дозволене значення в 1518 байт з хорошою або поганою контрольною сумою. Подовжені кадри є наслідком затяжної передачі, яка з'являється через несправність мережевих адаптерів. <br /> <br /> *Кадри нормальних розмірів, але з поганою контрольною сумою (BadFCS чи BadCRC) і кадри з помилками вирівнювання (alignment). Кадри з поганою контрольної сумою наслідком великої кількості причин - поганих адаптерів, перешкод на кабелях, поганих контактів, які працюють некоректно, портів повторювачів, мостів, комутаторів і маршрутизаторів. Помилка вирівнювання завжди супроводжується помилкою по контрольної сумі, тому деякі кошти аналізу трафіка не роблять між ними відмінностей.<br /> <br /> *Кадри-привиди (ghosts) - є результатом электро-магнітних наводок на кабелі. Вони сприймаються мережними адаптерами як кадри, що не мають нормальної ознаки початку кадру - 10101011. Кадри-привиди мають довжину понад 72 байт, в іншому разі вони класифікуються як віддалені колізії. Кількість виявлених кадрів-привидів значною мірою залежить від точки підключення мережного аналізатора. Причинами їх виникнення є петлі заземлення й інші проблеми з кабельної системою<br /> <br /> === Типові помилки при роботі протоколів ===<br /> Крім явних помилок у роботі мережі, які проявляються у появі кадрів з некоректними значеннями полів, існують помилкові ситуації, які є наслідком неузгодженої установки параметрів протоколів в різних вузлах чи портах мережі. Через велику кількость протоколів, застосовуваних у локальних мережах на різноманітних рівнях стека, а також великої кількості їх параметрів, неможливо описати всі ситуації неузгодженості. Нижче наводяться тільки деякі з них.<br /> <br /> Іншою причиною некоректної роботи протоколів може бути неузгодженість протоколів різного рівня в одному і тому самомущо вузлі, наприклад, протоколів FDDI і IPX, що розроблені у розрахунку на різні інтерфейси міжрівневої взаємодії в стеку, FDDI - а інтерфейс NDIS, а IPX - на інтерфейс ODI. <br /> [[Файл:98769876.gif]]<br /> <br /> ==== Невідповідність форматів кадрів Ethernet ====<br /> Ethernet - одна з найстаріших технологій локальних мереж, має тривалу історію розвитку, в яку зробили внесок різні компанії і організації. У результаті цього існує кілька модифікацій навіть такого основного будівельного блоку протоколу, як формат кадру. Використання різних форматів кадрів може привести до повної відсутності взаємодії між вузлами.<br /> <br /> Усього є чотири популярних стандарти формату кадру Ethernet: <br /> *Кадр Ethernet DIX (або кадр Ethernet II);<br /> *Кадр стандарта 802.3(або кадр Novell 802.2);<br /> *Кадр Novell 802.3 (або кадр Raw 802.3);<br /> *Кадр Ethernet SNAP.<br /> <br /> Кадр стандарту EthernetDIX, званий також кадром EthernetII, розроблений компаніями Digital, Xerox і Intel (перші літери назви компаній і дали назву цьому варіанту Ethernet) при створенні перших мереж Ethernet. Всього було випущено дві версії фірмового стандарту Ethernet, тому остання, друга версія цього стандарту також іноді вказується при позначенні варіанту протоколу Ethernet і відповідно його формату кадру. Часто в літературі саме цей варіант формату кадру називають кадром Ethernet, залишаючи для міжнародного стандарту технології EthernetIEEE 802.3 позначення 802.3.<br /> <br /> Кадр стандарту EthernetDIX має наступний формат:<br /> [[Файл:987789.jpg]]<br /> <br /> Поля Destination і Source містять 6-ти байтним МАС-адреси вузла призначення і джерела, а поле Type - двухбайтного ідентифікатор протоколу верхнього рівня, який помістив свої дані в полі даних Data. Для поля Type існують стандартні значення числових ідентифікаторів для всіх популярних протоколів, що використовуються в локальних мережах. Наприклад, протокол IP має числовий ідентифікатор 0800 і т.п. Ці значення можна знайти у постійно оновлюваному RFC (наприклад, в RFC 1700), в якому Уаза всі конкретні числові значення, що застосовуються в протоколах мережі Internet.<br /> <br /> У стандарті IEEEEthernet 802.3 визначений формат кадру Ethernet, близький до формату EthernetDIX, але має деякі відмінності:<br /> [[Файл:9877890.jpg]]<br /> <br /> Одне з принципових відмінностей полягає в тому, що замість поля Type у ньому використовується поле Length (Довжина), також має розмір 2 байти, але містить довжину поля даних в байтах.<br /> <br /> Поле Type встандарте 802.3 замененодвумядополнительнымиполями - DSAP (Destination Service Access Point) і SSAP (Source Service Access Point). Поле DSAP вказує сервіс (протокол), якому призначаються дані, а поле SSAP позначають сервіс (протокол), який відправив ці дані. Призначення цих полів те ж, що і поля Type, але наявність двох полів дозволяє організувати передачу даних між протоколами різного типу (правда, на практиці ця властивість ніколи не використовується). Однобайтовий формат полів SAP не дозволив використовувати в них ті ж числові позначення ідентифікаторів протоколів, які прижилися для кадрів EthernetDIX, тому кожен протокол верхнього рівня має зараз два ідентифікатора - один використовується при інкапсуляції пакета протоколу в кадр EthernetDIX, а другий - при інкапсуляції в кадр Ethernet 802.3.<br /> <br /> Ще однією відмінністю кадру IEEE 802.3 є однобайтове поле Control (Управління), яке призначене для реалізації режиму роботи з встановленням соедінененія. У поле Control повинні міститися номери кадрів квитанцій підтвердження доставки даних, необхідні для відпрацювання процедур відновлення загублених або перекручених кадрів. На практиці більшість операційних систем не використовує цих можливостей кадру 802.3, обмежуючись роботою в дейтаграмному режимі (при цьому значення поля Control завжди дорівнює 03).<br /> <br /> Так як стандарт IEEE ділить канальний рівень на два підрівня - MAC і LLC, то іноді кадр Ethernet 802.3 також представляють як композиції двох кадрів. Кадр МАС-рівня включає поля преамбули, адрес призначення і джерела, поле довжини і поле контрольної суми, а кадр LLC містить поля DSAP, SSAP, Control і поле даних (яке через введення нових трьох однобайтових полів має максимальну довжину на 3 байти менше ).<br /> <br /> Кадр Novell 802.3, який також називають кадром Raw 802.3 (тобто &quot;грубий&quot; або &quot;очищений&quot; варіант стандарту 802.3) являє собою кадр МАС-рівня без полів рівня LLC:<br /> <br /> [[Файл:98778900.jpg]]<br /> <br /> Цей тип кадру тривалий час успішно застосовувався компанією Novell в її мережах NetWare. Відсутність поля типу протоколу верхнього рівня не створювало труднощів, так як в мережах Novell довгий час використовувався лише один протокол мережевого рівня - протокол IPX. Надалі при переході до багатопротокольним мереж компанія Novell стала використовувати як основного стандартний кадр IEEE 802.3 (який в документації Novell називається кадром 802.2 - номер стандарту на підрівень LLC).<br /> <br /> Кадр EthernetSNAP (SubNetworkAccessProtocol) активно використовується в мережах TCP / IP для досягнення сумісності числових ідентифікаторів протоколів з тими, які використовуються в кадрі EthernetDIX. Кадр EthernetSNAP визначений у стандарті 802.2H і являє собою розширення кадру IEEE 802.3 шляхом введення двох додаткових полів: 3-х байтового поля OUI (OrganizationUnitIdentifier) ​​і двухбайтового поля Type. Поле Type має той же формат і те ж призначення, що і поле Type кадру EthernetDIX. Тому числові значення ідентифікаторів протоколів, що поміщаються в це поле кадру EthernetSNAP, збігаються зі значеннями, що використовуються в кадрах EthernetDIX, і в цьому весь сенс введення додаткових полів заголовка SNAP. У полі OUI вказується код організації, яка определеяется стандартні значення для поля Type. Для протоколу Ethernet такою організацією є комітет IEEE 802.3, і його код дорівнює 00 00 00. Наявність поля OUI дозволяє використовувати заголовок SNAP не тільки для протоколу Ethernet, а й для інших протоколів, які контролюються іншими організаціями.<br /> <br /> Якщо обладнання або операційна система налаштовані на підтримку якогось одного формату кадру Ethernet, то вони можуть не знайти взаєморозуміння з іншим вузлом, який в свою чергу підтримує також один формат кадру Ethernet, але іншого типу. Результатом спроб взаємодії таких вузлів буде відкидання вступників кадрів, так як невірна інтерпретація формату призведе до невірної контрольної сумі кадру.<br /> <br /> Багато сучасні операційні системи та комунікаційне обладнання вміють одночасно працювати з різними типами кадрів, розпізнаючи їх автоматично. Розпізнавання йде за значенням 2-х байтового поля, розташованого за адресою джерела. Це поле може бути полем Type або Length. Числові ідентифікатори протоколів вибрані так, що значення поля Type буде завжди більше 1500, в той час як поле Length завжди містить значення менше або рівне 1500. Подальше відділення кадрів EthernetSNAP від ​​IEEE 802.3 проводиться на підставі значення полів DSAP і SSAP. Якщо присутній заголовок SNAP, то поля DSAP і SSAP завжди містять цілком певний числовий ідентифікатор, зарезервований за протоколом SNAP.<br /> <br /> Автоматичне розпізнавання типу кадру позбавляє користувачів мережі від неприємних проблем, проте та ж ОС або маршрутизатор можуть бути налаштовані на підтримку тільки одного типу протоколів, і в цьому випадку проблема несумісності може проявлятися.<br /> <br /> Мережеві аналізатори та засоби моніторингу вміють автоматично розрізняти формати кадрів Ethernet. Для завдання умов захоплення кадрів, що містять пакети певних протоколів верхнього рівня, аналізатори дозволяють користуватися як числовими ідентифікаторами цих протоколів для полів SAP (DSAP і SSAP), так і числовими ідентифікаторами для поля Type (які мають також назву EtherType).<br /> <br /> У мережах TokenRing і FDDI завжди використовуються кадри стандартного формату, тому в цих мережах не виникають проблеми, пов'язані з несумісністю форматів кадрів.<br /> <br /> ==== Втрати пакетів та квитанцій ====<br /> Регулярні втрати пакетів чи кадрів можуть мати дуже тяжкі наслідки для локальних мереж, оскільки протоколи нижнього рівня (канальні протоколи) розраховані на якісні кабельні канали зв'язку та працюють у дейтаграммном режимі, залишаючи роботу відновленню втрачених пакетів протоколів верхнього рівня.<br /> <br /> До значного зниження продуктивності можуть наводити також втрати службових повідомлень - квитанцій підтвердження доставки, повідомлень типу keepalive тощо. Зазвичай протоколи більш чутливі до таких втрат і навіть разові ситуації такого роду можуть викликати серйозні наслідки. <br /> <br /> Прикладом може служити протокол NCP в режимі burstmode, коли позитивна квитанція посилається не на кожен пакет, а на цілу пачку пакетів. Якщо пакети з цієї пачки з користувальницькими даними дійшли благополучно, а квитанція з доставки з якихось причин була спотворена і тим самим відкинута передавальним вузлом, то цей вузол по закінченні тайм-ауту повторно пошле велику порцію інформації, що міститься в цій пачці. Повторні передачі пакетів можуть істотно знизити корисну пропускну здатність мережі.<br /> <br /> ==== Помилки кадрів Ethernet у стандарті RMON====<br /> Стандарт RMON визначає такі типи помилок кадрів Ethernet:<br /> <br /> etherStatsCRCAlignErrors - загальне число отриманих пакетів, які мали довжину (виключаючи преамбулу) між 64 і 1518 байтами, не містили ціле число байт (alignmenterror) або мали невірну контрольну суму (FCSerror).<br /> <br /> etherStatsUndersizePkts - загальне число пакетів, які мали довжину, менше, ніж 64 байта, але були правильно сформовані.<br /> <br /> etherStatsOversizePkts - загальне число отриманих пакетів, які мали довжину більше, ніж 1518 байт, але були тим не менш правильно сформовані.<br /> <br /> etherStatsFragments - загальне число отриманих пакетів, які не перебували з цілого числа байт або мали невірну контрольну суму, і мали до того ж довжину, меншу, ніж 64 байта.<br /> <br /> etherStatsJabbers - загальне число отриманих пакетів, які не перебували з цілого числа байт або мали невірну контрольну суму, і мали до того ж довжину, більшу, ніж 1518 байт.<br /> <br /> etherStatsCollisions - наілучщая оцінка числа колізій на даному сегменті Ethernet.<br /> <br /> ==== Невідповідність різних способів маршрутизації в складеній мережі====<br /> Маршрутні таблиці, використовуються маршрутизаторами для просування пакетів певного мережевого протоколу, завжди мають однакову структуру, проте спосіб їх отримання може бути різним - ручний, за протоколом RIP, за протоколом OSPF або ж ще по якомусь іншому протоколу динамічного обміну інформацією. Якщо в різних частинах складовою мережі використовуються різні протоколи обміну маршрутною інформацією, то це може призводити до неузгодженої роботі маршрутизаторів і, отже, до відсутності досяжності деяких мереж для користувачів.<br /> <br /> Кожен протокол обміну маршрутної інформації використовує свій формат службових повідомлень для поширення своїх знань про топологію мережі. Тому, якщо не вживати додаткових заходів, то частини мережі, що використовують різні протоколи маршрутизації, взагалі не зможуть автоматично взаємодіяти.<br /> <br /> Для забезпечення сумісності протоколів маршрутизації розроблені спеціальні протоколи, які передають маршрутні дані між різними частинами мережі в уніфікованому форматі. До таких протоколів відносяться протокол EGP (ExteriorgatewayProtocol) і його пізніша модифікація BGP (BorderGatewayProtocol), розроблені і вживані в мережі Internet. Вони можуть переносити знання про мережі між протоколами RIP, OSPF, NLSP, IS-IS та іншими.<br /> <br /> Однак, тільки застосування протоколів типу EGP або BGP не вирішує проблем роботи гетерогенної щодо протоколів маршрутизації мережі. Знання про будь-якої мережі можуть надійти від різних частин мережі, і, відповідно, від різних протоколів. У таких випадках для стійкої роботи мережі потрібно віддавати пріоритет більш надійно працюють в умовах зміни топології протоколах типу &quot;стан зв'язків&quot;, таких як OSPF, NLSP і IS-IS. Багато маршрутизатори дозволяють задавати пріоритети одних протоколів маршрутизації перед іншими.<br /> <br /> Для того, щоб адміністратор міг &quot;підправляти&quot; таблиці маршрутизації, отримані автоматичним способом, найвищий пріоритет зазвичай віддається маршрутами, заданим вручну. Однак, такі маршрути можуть бути і причиною недосяжності деяких мереж, тому що ймовірність внесення людиною помилки завжди існує, причому вона швидко підвищується при збільшенні розміру мережі. Використанні в мережі масок нерівної довжини - також типова причина недосяжності підмереж в результаті недостатньо всебічного аналізу можливих маршрутів в мережі.<br /> <br /> У мережах TCP / IP помилкові ситуації, що фіксуються маршрутизатором при неможливості передати пакет в мережу призначення, повідомляються кінцевому вузлу службовим протоколом ICMP, пакети якого обов'язково потрібно аналізувати у великих мережах, що використовують маршрутизатори.<br /> ====Неіснуюча адреса і дублювання адрес ====<br /> Відправлення пакета за неіснуючим адресою природно не може привести до нормального взаємодії вузлів в мережі. Неіснуючі адреси можуть з'явитися в мережі тільки в тому випадку, коли вони зберігаються постійно в базі даних стека протоколів (наприклад, в базi служби DNS стека TCP / IP або служби NDS мереж NetWarе). При цьому може наступити момент, коли зберігається адреса застаріє і не буде відповідати дійсності.<br /> <br /> У випадку, коли адреси вивчаються динамічно, шляхом аналізу пакетів службового протоколу, подібного SAP, використання несществующего адреси практично виключається, тому що інформація про адресу щойно надійшла від вузла, якому ця адреса присвоєний.<br /> <br /> Серйозні проблеми в мережі створює дублювання адрес, тобто наявність у мережі двох вузлів з одним і тим ж адресою. Така ситуація найчастіше призводить до недосяжності обох вузлів з однаковою адресою, або ж до порушення нормальної роботи всієї мережі, якщо дублюються не адреси вузлів, а адреси мереж (IP або IPX). Проблема дублювання адрес характерна більшою мірою для адрес верхніх рівнів, починаючи з мережевого, де адреси призначаються адміністратором і тому можуть повторюватися в результаті людських помилок. Адреси канального рівня (МАС-адреси) присвоюються мережевим адаптерам, портам маршрутизаторів і агентам [[SNMP]]-управління компаніями-виробниками, тому їх дублювання малоймовірно (тільки у випадку перепризначення адреси, що можливо шляхом його програмування).<br /> <br /> Для виявлення повторюваних адрес в мережах необхідно використовувати аналізатор протоколів, налаштувавши його на захоплення пакетів з певним адресою мережі та / або вузла. Деякі протоколи локальних мереж використовують спеціальну процедуру для перевірки дублювання адрес на канальному рівні (наприклад, TokenRing, FDDI).<br /> <br /> ==== Перевищення значень тайм-ауту і неузгоджені значення тайм-аутів====<br /> Тайм-аути - дуже важливі параметри багатьох протоколів, так як їх непередбачене перевищення зазвичай призводить до серйозних наслідків. Наприклад, перевищення тайм-ауту може привести до розриву логічного з'єднання між сервером і клієнтом, або ж до непотрібних повторним передачам даних, які і так вже благополучно дійшли до одержувача. Розрив логічного з'єднання призводить до великих втрат часу, а значить і до значного зниження пропускної здатності мережі, так як процедура встановлення з'єднання може включати обмін сотнями пакетів, що передають аутентифікаційні та іншу службову інформацію.<br /> <br /> Найбільш чутливим до перевищення тайм-ауту протоклом канального рівня є протокол SDLC стека SNA компанії IBM. Через це до територіальних мереж, що передає трафік SDLC, пред'являються підвищені вимоги до величини і стабільності часу реакції.<br /> <br /> Однак, не тільки протокол SDLC чутливий до тимчасових затримок передачі пакетів. Багато протоколів, що працюють в режимі логічного з'єднання, мають таку властивість. Наприклад, протокол TCP стежить за цілісністю логічного з'єднання шляхом встановлення спеціального таймера, який встановлюється під час поселення чергового TCP-повідомлення. Якщо таймер минає раніше, то сесія TCP розривається, що призводить до розриву сесії протоколу прикладного рівня, наприклад, FTP. Так як протокол FTP не володіє властивістю продовження передачі файла з перерваного місця після розриву і повторного встановлення з'єднання, то розриви сесії TCP можуть призводити до того, що файл обсягом у кілька мегабайт, який був переданий майже повністю, доведеться передавати заново. Подібна ситуація іноді зустрічається в мережі Internet, коли завантаженість FTP-сервера або маршрутизаторів призводить до значних затримок відправки чергового TCP-повідомлення. Для запобігання розривів у протоколі TCP передбачена можливість генерації пакетів keepalive в той час, коли відсутні дані користувача для передачі, проте цей режим є опціональним і не всі реалізації стека TCP / IP його підтримують.<br /> <br /> У локальних мережах перевищення тайм-ауту спостерігається набагато рідше, ніж у глобальних, але при великому завантаженні мережі може також мати місце.<br /> <br /> Нестабільний характер прояву помилок закінчення тайм-аутів ускладнює діагностику, тому що помилка проявляється у випадкових втрати зв'язку користувачів з серверами і може спостерігатися лише в періоди великого навантаження мережі, ніяк не проявляючи себе в решту часу.<br /> <br /> До аналогічних наслідків призводять неузгоджені значення тайм-аутів у взаємодіючих вузлів або комунікаційних пристроїв. Прикладом такої неузгодженості можуть служити різні значення тайм-ауту у прикордонних маршрутизаторів при спуфінга широкомовного трафіку. Іншим прикладом може бути різний період оновлення бази маршрутної інформації у маршрутизаторів.<br /> <br /> Перейти до [[Засоби аналізу та оптимізації мереж]]<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/IP 2011-12-18T20:56:12Z

<p>Aleksey: </p> <hr /> <div>Міжмережевий протокол '''IP''' специфікований у RFC 791. Це самий фундаментальний протокол з комплекту TCP/IP - передає IP-дейтаграми по інтрамережі і виконує важливу функцію, що називається маршрутизацією, по суті справи це вибір маршруту, по якому дейтаграма буде випливати з пункту А в пункт B, і використання маршрутизаторів для &quot;стрибків&quot; між мережами. <br /> <br /> Його ''основні характеристики'' перераховані нижче: <br /> - реалізує обмін інформації пакетами, які будемо називати IP-сегментами (максимальний розмір IP-сегмента - 65535 байт); <br /> - є протоколом взаємодії без установлення логічного з'єднання; <br /> - для адресації вузлів мережі використовується адреса довжиною 4 байти; <br /> - забезпечує в разі потреби фрагментацію IP-сегментів; <br /> - IP-сегменти мають кінцевий час життя в мережі; <br /> - не гарантує надійність доставки IP-сегментів адресату; <br /> - не має засобів керування інтенсивністю передачі IP-сегментів стороною, що посилає, (flow control); <br /> - не гарантує правильну послідовність IP-сегментів на приймаючій стороні.<br /> <br /> Отже, IP - ''ненадійний протокол, що надає сервіс доставки датаграм без з'єднання''. <br /> <br /> Під словом ''ненадійний'' ми маємо на увазі те, що не існує гарантії того, що IP датаграма успішно досягне пункту призначення. Однак IP надає визначений сервіс обробки деяких подій. Коли що-небудь йде не так як хотілося б, як наприклад, тимчасове переповнення буфера в маршрутизатора, IP застосовує простий алгоритм обробки помилок: він відкидає датаграму і намагається послати ICMP повідомлення відправникові. Будь-яка необхідна надійність повинна бути забезпечена верхніми рівнями (наприклад TCP). <br /> <br /> Термін ''без з'єднання'' (connectionless) означає, що IP не містить ніякої інформації про просування датаграм. Кожна датаграма обробляється незалежно від інших. Це також означає, що може бути доставлена зіпсована датаграма. Якщо джерело відправляє дві послідовні датаграми (перша A, потім B) в один і те ж пункт призначення, кожна з них маршрутизується незалежно і може пройти по різних маршрутах, датаграма B може прибути раніше за A.<br /> <br /> '''''IP заголовок'''''.На малюнку показаний формат IP датаграми. Стандартный розмір IP заголовка складає 20 байт, якщо нема опцій.<br /> &lt;center&gt;[[Image:T3_1.jpg]]&lt;/center&gt;<br /> <br /> Старший значущий біт має номер 0 (ліворуч), а молодший значущий біт з 32-х біт має номер 31 і показаний праворуч. <br /> <br /> 4 байти з 32-бітного значення передаються в наступному порядку: спочатку біти 0 - 7, потім біти 8 - 15, потім 16 - 23 і, нарешті, 24 - 31. Такий порядок руху байтів називається big endian (метод збереження або передачі даних, при якому старший значущий біт або байт стоїть першим) і обов'язковий для всіх двійкових цілих чисел у TCP заголовках при їхній передачі по мережі. Це називається порядок мережних байтів (network byte order). Машини, що зберігають двійкові цілі в інших форматах, як наприклад у форматі little endian (little endian - метод збереження або передачі даних, при якому молодший значущий біт або байт стоїть першим), повинні конвертувати значення заголовків у відповідний порядок мережних байтів перед передачею даних. <br /> <br /> Довжина ''заголовка'' (header length) це кількість 32-бітних слів у заголовку, включаючи будь-які опції. Тому що це 4-бітне поле, воно обмежує розмір заголовка в 60 байт. Це обмеження сильно впливає на деякі опції, такі як опція запису маршруту. Звичайна величина в цьому полі (коли відсутні опції) - 5. <br /> <br /> Поле ''типу сервісу'' (TOS - type-of-service) складається з 3-бітного поля приставки (яке в даний час ігнорується), 4 біт TOS і невикористовуваного біта, що повинен дорівнювати 0.<br /> 4 біта TOS наступні: мінімальна затримка, максимальна пропускна здатність, максимальна надійність і мінімальна вартість. Тільки один з цих 4 біт може бути встановлений в одиницю одночасно. Якщо всі 4 біти рівні 0, це означає звичайний сервіс. RFC 1340 [Reynolds and Postel 1992] указує, як ці біти повинні бути встановлені для всіх стандартних додатків. RFC 1349 [Almquist 1992] містить деякі корекції для цього RFC і більш детальний опис характеристики TOS.<br /> <br /> ''Діалогові додатки'', Telnet і Rlogin, вимагають звести до мінімуму затримку, тому що вони використовуються людиною інтерактивно і здійснюють невелику передачу даних. Передача файлів з використанням FTP, з іншого боку, вимагає максимальної пропускної здатності. Максимальна надійність необхідна для мережного керування ([[SNMP]]) і для протоколів маршрутизації. Новини Usenet (NNTP) - це єдиний додаток, що вимагає мінімізації вартості. <br /> <br /> ''Поле повної довжини'' (total length) містить повну довжину IP датаграми в байтах. Завдяки цьому полю і полю довжини заголовка, ми знаємо, з якого місця починаються дані в IP датаграмі і їхню довжину. Тому що це поле складається з 16 біт, максимальний розмір IP датаграми складає 65535 байт. Це поле змінюється в момент фрагментації і повторної зборки датаграми. <br /> <br /> Незважаючи на то що існує можливість відправити датаграму розміром 65535 байт, більшість канальних рівнів поділять подібну датаграму на фрагменти. Більш того, від хоста не потрібно приймати датаграму розміром більше за 576 байт. TCP поділяє користувацькі дані на частині, тому це обмеження звичайно не робить впливу на TCP. Що стосується UDP, послугами якого користуються багато додатків (RIP, TFTP, BOOTP, DNS, [[SNMP]]), те він обмежує себе 512 байтами користувацьких даних, що навіть менше обмеження в 576 байт. Більшість додатків у даний час (особливо ті, котрі підтримують NFS - Network File System) дозволяють використовувати IP датаграму розміром 8192 байта. <br /> <br /> Однак, поле повної довжини потрібно в IP заголовку для деяких каналів (як наприклад, Ethernet), що доповнює маленькі фрейми до мінімальної довжини. Незважаючи на те що мінімальний розмір фрейму Ethernet складає 46 байт (малюнок 2.1), IP датаграма може бути ще менше. Якщо поле повної довжини не було представлено, IP рівень не буде знати, скільки 46-байтных фреймів Ethernet вийде з IP датаграми. <br /> <br /> ''Поле ідентифікації'' (identification) унікально ідентифікує кожну датаграму, відправлену хостом. Значення, що зберігається в полі, звичайно збільшується на одиницю з посилкою кожної датаграми. <br /> Поле часу життя (TTL - time-to-live) містить максимальну кількість пересилань (маршутизаторів), через які може пройти датаграма. Це поле обмежує час життя датаграми. Значення установлюється відправником (як правило 32 або 64) і зменшується на одиницю кожним маршрутизатором, що обробляє датаграму. Коли значення в полі досягає 0, датаграма видаляється, а відправник повідомляється про це за допомогою ICMP повідомлення. Подібний алгоритм запобігає зацикленню пакетів у петлях маршрутизації. <br /> <br /> ''Поле протоколу'' (protocol) вказує, який протокол відправив дані через IP. <br /> <br /> ''Контрольна сума заголовка'' (header checksum) розраховується тільки для IP заголовка. Вона не містить у собі дані, що слідують за заголовком. ICMP, IGMP, UDP і TCP мають контрольні суми у своїх власних заголовках, що охоплюють їхні заголовки і дані. <br /> <br /> Щоб розрахувати контрольну суму IP для вихідної датаграмми, поле контрольної суми спочатку встановлюється в 0. Потім розраховується 16-бітна сума з пірозрядним доповненням (One's complement - порозрядне доповнення до двійкової системи.) (заголовок цілком сприймається як послідовність 16-бітних слів). 16-бітне порозрядне доповнення цієї суми зберігається в поле контрольної суми. Коли IP датаграма приймається, обчислюється 16-бітна сума з порозрядним доповненням. Контрольна сума, розрахована приймачем, містить у собі контрольну суму, збережену відправником, контрольна сума приймача складається з бітів рівних 1, якщо в заголовку нічого не було змінено при передачі. Якщо в результаті не вийшли всі одиничні біти (помилка контрольної суми), IP відкидає прийняту датаграму. Повідомлення про помилку не генерується. Тепер задача верхніх рівнів яким-небудь образом визначити, що датаграма відсутнія, і забезпечити повторну передачу. <br /> <br /> Кожна IP датаграмма містить IP ''адреса джерела'' (source IP address) і IP ''адреса призначення'' (destination IP address). Це 32-бітні значення, що ми описали в розділі &quot;Адресація Internet&quot; глави 1. <br /> <br /> І останнє поле - ''поле опцій'' (options), це список додаткової інформації змінної довжини. В даний час опції визначені в такий спосіб: <br /> - безпека й обробка обмежень (для військових додатків, описане в RFC 1108 [Kent 1991]), <br /> - запис маршруту (запис кожного маршруту і його IP адреса, глава 7, розділ &quot;Опція запису IP маршруту&quot;), <br /> - тимчасова марка (запис кожного маршруту, його IP адреса і час, глава 7, розділ &quot;IP опція тимчасової марки&quot;), <br /> - вільна маршрутизація від джерела (указує список IP адрес, через які повинна пройти датаграма), і тверда маршрутизація від джерела (те ж саме, що й у попередньому пункті, однак IP датаграма повинна пройти тільки через зазначені в списку адреси).<br /> <br /> Ці опції рідко використовуються і не всі хости або маршрутизатори підтримують всі опції. <br /> <br /> Поле опцій завжди обмежено 32 бітами. Байти заповнення, значення яких дорівнює 0, додаються по необхідності. Завдяки цьому IP заголовок завжди кратний 32 биткам (як це потрібно для поля довжини заголовка).<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/AppleTalk 2011-12-18T20:55:41Z

<p>Aleksey: </p> <hr /> <div>==Вступ==<br /> <br /> {|<br /> |[[Файл:2.png|200 px]]<br /> <br /> |'''Appletalk''' - це стек протоколів, розроблених Apple Computer для комп'ютерної мережі. Він був спочатку включений в Macintosh (1984), зараз компанія відмовилася від нього на користь [[TCP/IP|TCP/IP]].Існує дві версії AppleTalk: AppleTalk Phase I і AppleTalk Phase II.<br /> <br /> <br /> Версія '''AppleTalk Phase I''' розроблена для невеликих робочих груп і не має можливостей для роботи з великою мережею. Кількість хостів, які може підтримувати мережу AppleTalk Phase I, обмежується 135.<br /> <br /> <br /> У версії '''AppleTalk Phase II''' це число розширюється до 253 на одному сегменті, що дозволяє підтримувати мережу великих розмірів.<br /> <br /> <br /> Як і стек протоколів Інтернет, стек протоколів AppleTalk охоплює більшу частину семирівневої OSI-моделі, що показано на рис.3.10. Знаючи функції кожного рівня OSI-моделі, можна оцінити, які типи функцій виконуються кожним з протоколів AppleTalk.<br /> |}<br /> <br /> ==Мережева модель==<br /> <br /> {| border=1<br /> !Модель OSI<br /> !Відповідні рівні Appletalk<br /> |-<br /> |Прикладний рівень<br /> |[[Apple Filing Protocol (AFP)]]<br /> <br /> |-<br /> |Рівень представлення<br /> |[[Apple Filing Protocol (AFP)]]<br /> |-<br /> |Сеансовий рівень<br /> | <br /> Zone Information Protocol (ZIP)&lt;br /&gt;<br /> AppleTalk Session Protocol (ASP)&lt;br /&gt;<br /> [[AppleTalk Data Stream Protocol (ADSP)]]&lt;br /&gt;<br /> AppleTalk Update-Based Routing Protocol (AURP)&lt;br /&gt;<br /> Printer Access Protocol (PAP)<br /> |-<br /> |[[Транспортний рівень]]<br /> |<br /> [[AppleTalk Transaction Protocol (ATP)]]&lt;br /&gt;<br /> AppleTalk Echo Protocol (AEP)&lt;br /&gt;<br /> Name Binding Protocol (NBP)&lt;br /&gt;<br /> [[Routing Table Maintenance Protocol (RTMP)]]<br /> |-<br /> |''Мережевий рівень''<br /> |[[Datagram Delivery Protocol (DDP)]]<br /> |-<br /> |''Канальний рівень''<br /> |<br /> EtherTalk Link Access Protocol (ELAP)&lt;br /&gt;LocalTalk Link Access Protocol (LLAP) &lt;br /&gt; TokenTalk Link Access Protocol (TLAP) &lt;br /&gt;Fiber Distributed Data Interface (FDDI)<br /> |-<br /> |''Фізичний рівень''<br /> |<br /> LocalTalk driver&lt;br /&gt;<br /> Ethernet driver&lt;br /&gt;<br /> Token Ring driver&lt;br /&gt;<br /> FDDI driver<br /> |}<br /> <br /> == Бібліографічна довідка ==<br /> <br /> На початку 1980 р. Apple Computer готувалася до випуску комп'ютера Macintosh. Інженери компанії знали, що незабаром мережі стануть насущною необхідністю, а не просто цікавою новинкою. Вони хотіли також добитися того, щоб що базується на комп'ютерах Macintosh мережа була безшовним розширенням інтерфейсу користувача Macintosh, що зробило справжню революцію в цій області. Маючи на увазі ці два чинники, Apple вирішила вбудувати мережевий інтерфейс в кожен Macintosh і інтегрувати цей інтерфейс в оточення настільної обчислювальної машини. Нова мережева архітектура Apple отримала назву Apple Talk.<br /> Хоча Apple Talk є патентованою мережею, Apple опублікувала характеристики Apple Talk, намагаючись заохотити розробку за участю третьої сторони. В даний час велике число компаній успішно збувають на ринку що базуються на Apple Talk вироби; у їх числі Novell, Inc. і Мicrosoft Corparation.<br /> Оригінальну реалізацію Apple Talk, розроблену для локальних робочих груп, в даний час зазвичай називають Apple Talk Phase I. Проте після установки понад 1.5 млн. комп'ютерів Macintosh протягом перших п'яти років існування цього виробу, Apple виявила, що деякі крупні корпорації перевищують вбудовані можливості Apple Talk Phase I, тому протокол був модернізований. Розширені протоколи стали известнны під назвою Apple Talk Phase II. Oни розширили можливості маршрутизації Apple Talk, забезпечивши їх успішне застосування в крупніших мережах.<br /> <br /> <br /> Мережа AppleTalk розроблена компанією apple computer inc. (1987 р) Ці мережі можуть працювати в середовищі Ethernet, Token Ring, FDDI і LocalTalk (власна мережа apple, що використовує скручені пари). У AppleTalk специфікований власний стек протоколів, які управляють потоком даних у мережі. Для цілей маршрутизації AppleTalk використовує модифіковану версію внутрішнього протоколу маршрутизації IGRP.<br /> <br /> == Основи технології ==<br /> <br /> Apple Talk була розроблена як система розподіленої мережі клієнт-сервер. Іншими словами, користувачі спільно користуються мережевими ресурсами (такими, як файли і принтери). Комп'ютери, що забезпечують ці ресурси, називаються службовими пристроями (servers); комп'ютери, що використовують мережеві ресурси службових пристроїв, називаються клієнтами (clients). Взаємодія із службовими пристроями в значній мірі є прозорою для користувача, оскільки сам комп'ютер визначає місцеположення запрошуваного матеріалу і звертається до нього без отримання подальшої інформації від користувача. На додаток до простоти використання, розподілені системи також мають економічні переваги в порівнянні з системами, де всі важливі матеріали можуть бути поміщені в декількох, а не в багатьох місцеположеннях.<br /> <br /> == Протокoл розширення адреси AppleTalk (AARP) ==<br /> <br /> Фактичні механізми вибору адреси AppleTalk залежать від носія. Для встановлення зв'язку адрес AppleTalk з конкретними адресами носій використовується протокoл дозволу адреси AppleTalk (AARP). AARP також встановлює зв'язки між адресами інших протоколів і апаратними адресами. Якщо пакет протоколів AppleTalk або будь-який інший пакет протоколів повинен відправити пакет даних у інший мережний вузол, то адреса протоколу передається в AARP. AARP спочатку перевіряє адресний кеш, щоб визначити, чи є вже встановленої зв'язок між адресою цього протоколу і апаратним адресою. Якщо це так, то цей зв'язок передається в запитуючий пакет протоколів. Якщо це не так, то AARP ініціює широкомовне або багатопунктове повідомлення, яке звертається із запитом про апаратні адреси даного протокольного адреса. Якщо широкомовне повідомлення доходить до вузла з цією протокольною адресою, то цей вузол у відповідному повідомленні вказує свою апаратну адресу. Ця інформація передається в запитуючий пакет протоколів, який використовує цю апаратна адреса для зв'язку з цим вузлом.<br /> <br /> == Протокол доставки дейтаграм (DDP) ==<br /> <br /> Основним протоколом мережевого рівня AppleTalk є протокол DDP. DDP забезпечує обслуговування без встановлення з'єднання між мережевими гніздами. Гнізда можуть призначатися або статично, або динамічно. Адреси AppleTalk, що призначаються DDP, складаються з 2 компонентів: 16-бітового номера мережі (network number) і 8-бітового номера вузла (node ​​number). Ці два компоненти зазвичай записуються у вигляді десяткових номерів, розділених крапкою (наприклад, 10.1 означає мережу 10, вузол 1). Якщо номер мережі і номер вузла доповнені 8-бітовим гніздом (socket), що позначає який-небудь особливий процес, то це означає, що в мережі заданий який-небудь унікальний процес.<br /> AppleTalk Phase II робить відмінність між нерозширеними (nоnextended) і розширеними (extended) мережами. У нерозширених мережах, таких як LocalTalk, номер кожного вузла AppleTalk унікальний. Нерозширені мережі були єдиним типом мережі, визначеним у AppleTalk Phase I. У розширених мережах, таких як EtherTalk і TokenTalk, унікальною є комбінація номер кожної мережі / номер вузла.<br /> Зони визначаються керуючим мережі AppleTalk в процесі конфігурації роутера. Кожен вузол AppleTalk належить до окремої конкретної зони. Розширені мережі можуть мати кілька зон, які асоціюються з ними. Вузли в розширених мережах можуть належати до будь-якої окремої зони, яка асоціюється з цією розширеною мережею.<br /> <br /> == Протокол підтримки маршрутної таблиці (RTMP) ==<br /> <br /> Протокол, який організовує і підтримує маршрутні таблиці AppleTalk, називається Протоколом підтримки маршрутної таблиці (RTMP). Маршрутні таблиці RTMP містять дані про кожну мережі, до якої може дійти дейтаграмма. У ці дані входить порт роутера, який веде до мережі пункту призначення, ID вузла наступного роутера, який приймає цей пакет, відстань до мережі призначення, виражене числом пересилань, і поточний стан цих даних (хороше, підозріле або погане). Періодичний обмін маршрутними таблицями дозволяє роутеру об'єднаних мереж гарантувати забезпечення несуперечливою поточною інформацією. На малюнку представлений зразок таблиці RTMP і відповідна архітектура мережі.<br /> [[Файл:110.jpg]]<br /> <br /> == Протокол прив'язки за іменами AppleTalk (NBP) ==<br /> <br /> Протокол прив'язки за іменами AppleTalk (Name Binding Protocol - NBP) встановлює зв'язок імен AppleTalk (які виражаються як об'єкти, видимі для мережі - network-visible entities, або NVE) з адресами. NVE асоціюються з більш, ніж одним ім'ям об'єктів і переліком атрибутів. Імена об'єктів представляють собою послідовність символів, наприклад таку: printer @ net1, в той час як перелік атрибутів визначає характеристики NVE.<br /> Зв'язок між NVE з присвоєними іменами і мережевими адресами встановлюється через процес прив'язки імені. Прив'язка імені може бути зроблена в момент запуску сайту або динамічно, безпосередньо перед першим використанням. NBP керує процесом прив'язки імені, до якого входять реєстрація імені, підтвердження імені, стирання імені та пошук імені.<br /> <br /> == Протокол транзакцій AppleTalk (ATP) ==<br /> <br /> ATP є одним з протоколів транспортного рівня Appletalk. У транзакції АТР входять запити (від клієнтів) (requests) і відповіді (від службових пристроїв) (replies). Кожна пара запит / відповідь має окремий ID транзакції. Транзакції мають місце між двома гніздами клієнтів. АТР використовує транзакції &quot;тільки-один раз&quot; (exactly once - XO) і &quot;принаймні один раз&quot; (at least--once - ALO), Транзакції ХО потрібні в тих ситуаціях, коли випадкове виконання транзакції більше одного разу неприйнятно. Банківські транзакції є прикладом таких неідемпотентних (nonidempotent) ситуацій (ситуацій, коли повторення якоїсь транзакції викликає проблеми, що досягається тим, що робляться недійсними дані, які беруть участь в даній транзакції).<br /> АТР здатний виконувати найбільш важливі функції транспортного рівня, в тому числі підтвердження про прийом даних та повторну передачу, встановлення послідовності пакетів, а також фрагментованість та повторну збірку. АТР обмежує сегментування повідомлень до 8 пакетів; пакети АТР не можуть містити більше 578 інформаційних байтів.<br /> <br /> == Протокол потоку даних AppleTalk (ADSP) ==<br /> <br /> ADSP є важливим протоколом транспортного рівня Apple Talk. Як видно з його назви, ADSP є орієнтованим по потоку даних, а не по транзакціях. Він організовує і підтримує повністю дубльований потік даних між двома гніздами в об'єднаній мережі AppleTalk.<br /> ADSP є надійним протоколом в тому плані, що він гарантує доставку байтів в тому ж порядку, в якому вони були відправлені, а також те, що вони не будуть дубльовані. ADSP нумерує кожен байт, щоб відстежувати окремі елементи потоку даних. ADSP також визначає механізм управління потоком. Пункт призначення може в значній мірі уповільнювати передачі джерела, шляхом скорочення розміру оголошеного вікна на прийом.<br /> ADSP також забезпечує механізм повідомлень управління &quot;виходу зі смуги&quot; (out-of-band) між двома об'єктами AppleTalk. Як засіб для переміщення повідомлень управління виходу зі смуги між двома об'єктами AppleTalk використовуються пакети &quot;уваги&quot; (attention packets). Ці пакети використовують окремий потік номерів послідовностей, щоб можна було відрізняти їх від звичайних пакетів даних ADSP.<br /> <br /> == Протоколи вищих рівнів ==<br /> <br /> AppleTalk забезпечує декілька протоколів вищого рівня. Протокол сеансів AppleTalk (AppleTalk Session Protocol - ASP) організовує та підтримує сеанси (логічні діалоги) між клієнтом AppleTalk і службовим пристроєм. Протокол доступу до принтера (Printer Access Protocol - РАР) AppleTalk є орієнтованим по зв'язку протоколом, який організує і підтримує зв'язки між клієнтами і службовими пристроями (використання терміну printer в заголовку цього протоколу є просто історичною традицією). Ехо-протокол AppleTalk (AppleTalk Echo Protocol - AEP) є дуже простим протоколом, що генерує пакети, які можуть бути використані для перевірки спроможності різних вузлів мережі створювати повторне луна. І нарешті, Протокол ведення картотеки AppleTalk (AppleTalk Filing Protocol - AFP) допомагає клієнтам колективно використовувати службові файли в мережі.<br /> {|<br /> [[Файл:Image221.JPG]]<br /> |З діаграми видно, що стек протоколів appletalk повністю узгоджується з семирівневою схемою OSI. DDP являє собою протокол передачі даних, не орієнтований на з'єднання. Дейтограмма DDP використовує 13-байтовий заголовок, який включає в себе:<br /> поле числа маршрутизаторів (число кроків), через які пройшов пакет; поле довжини дейтограмми; поле контрольної суми; поля мережі призначення і відправника і т.д.<br /> Слідом за заголовком йде інформація, яка може містити до 586 байт. Максимальний розмір пакета (MTU) дорівнює 599 байтам. Число вузлів в мережі може досягати 16 мільйонів.<br /> Протокол adsp дозволяє двом програмам обмінюватися потоками інформації в повному дуплексному режимі з гарантією доставки. Протоколи TLAP, ELAP і LLAP служать для забезпечення сполучення з відповідними фізичними протоколами (Token Ring, Ethernet і Arcnet), приховуючи від програм інших рівнів специфічні особливості використовуваного мережного обладнання.<br /> Протокол ATP надійно передає запити і відгуки, детектирует помилки і організовує пакетний обмін. Цей протокол використовується в свою чергу протоколами ZIP, ASP і PAP, що видно з діаграми. Протокол AFP є протоколом підтримки додатків і дозволяє користувачам ЕОМ Macintosh працювати з загальними файлами.<br /> |}<br /> Програмне забезпечення Netware для Macintosh включає в себе файл AFP NLMtm, який забезпечує підтримку Netware-серверів. Протокол AURP (appletalk update-based routing protocol) служить для цілей маршрутизації, але на відміну від деяких інших протоколів передає маршрутну інформацію тільки у разі зміни ситуації. Він підтримує також IP-тунелі.<br /> <br /> &lt;center&gt;[[Файл:Image222.gif|400px]]&lt;/center&gt;<br /> <br /> &lt;center&gt; '''Формат пакетів в мережі Apple Talk Phase II (в дужках вказані розміри полів в байтах)'''&lt;/center&gt;<br /> <br /> Адреса відправника і одержувача мають по 24 біта, з них 16 біт складає адресу мережі. Ідентифікатор вузла призначення (локальна частина адреси) вибирається довільно самої робочої станції при встановленні зв'язку. ЕОМ бере випадкове 8-бітове число в якості локального адреси і посилає його в мережу. Якщо якась ЕОМ використовує цю адресу, вона відгукується, тоді код змінюється і робиться повторна спроба. Процес триває поки не буде знайдений вільний адрес.На малюнку - процес вибору адреси AppleTalk.<br /> <br /> &lt;center&gt;[[Файл:Процесс_выбора_адреса_AppleTalk.gif]]&lt;/center&gt;<br /> <br /> Протокол RTMP є протоколом маршрутизації, де в якості метрики використовується вектор відстані до адресата, цей протокол збирає маршрутну інформацію і надає її протоколу DDP для забезпечення транспортування пакетів по мережі. Маршрутні таблиці RTMP зберігаються в кожному з маршрутизаторів AppleTalk і базуються на номерах мереж адресатів. Таблиця містить у собі відстань до адресата, виміряний у кроках (hop), ідентифікатор порту маршрутизатора, через який досяжний адресат, і статус маршруту.<br /> <br /> Маршрутизатори AppleTalk формують і актуалізують маршрутні таблиці, посилаючи регулярно (раз на 10 сек) широкомовні RTMP-пакети сусіднім вузлам і мережам. Запис в маршрутній таблиці, своєчасно не підтверджена, через певний час стирається. Записи в маршрутній таблиці потрапляють в розряд &quot;підозрюваних&quot; за відсутності відгуку від них протягом 20 сек, в розряд &quot;вмираючих&quot; - через 40 сек, в категорію &quot;померлих&quot; - через 60 сек. Запис видаляється з таблиці, якщо відгук не вдається отримати протягом 80 сек.<br /> <br /> Адреси мережевого рівня ставляться у відповідність адресами MAC-рівня за допомогою адресного протоколу AARP. Вузли мережі Apple Talk зберігають цю інформацію в спеціальних таблицях (AMT - Address Mapping Table). Таблиця проглядається всякий раз, коли AppleTalk посилає пакет. Якщо пошук не увінчався успіхом, вузол-відправник посилає широкомовний AARP-запит. При отриманні відгуку на цей запит вносяться корективи в AMT-таблицю. Особливістю мережі AppleTalk є узгодження при присвоєнні локальних адрес об'єктам мережі. При ініціалізації вузла йому присвоюється тимчасова адреса. Протокол AARP перевіряє, чи не належить дана адреса комусь ще, для цього він посилає 10 AARP-запитів. Якщо ця тимчасова адреса вже використовується, вузлу, що ініціалізується, присвоюється нова тимчасова адреса і процедура перевірки повторюється до тих пір, поки вузлу не буде надано унікальний адресу. Протокол NBP перетворює локальні AppleTalk адреси в імена, присвоєні мережному об'єкту користувачем і навпаки. Це позбавляє користувача від необхідності пам'ятати повну мережеву адресу принт-або файл-сервера, поштового сервера і т.д.<br /> {|<br /> |[[Файл:Образец_ZIT.jpg|200px]]<br /> |Протокол ZIP допускає логічне групування кінцевих мережевих вузлів до деяких об'єднаннь, так званих зон, що дозволяє ЕОМ, що належать до одного відділу, але розташовані в різних будівлях, перебувати в одній зоні . Зона може бути комбінацією локальних мереж, а в разі EtherTalk Phase II - частина локальної мережі. Інформація про зони зберігається в маршрутизаторах у вигляді спеціальних таблиць (ZIT - Zone Information Table). Таблиця містить по одному запису на мережевий сегмент. Запис включає в себе номер мережевого сегменту і список об'єктів, що входять в зону. Протокол ZIP відстежує зміни в RTMP-таблицях і при появі в них записів, що відносяться до нових об'єктів або мереж, маршрутизатор посилає ZIP-запит і на основі отриманої інформації коригує ZIT-табліцу.ZIT зберігаються в роутерах, які є основними користувачами ZIP, проте кінцеві вузли використовують ZIP в процесі запуску для вибору своїх зон і отримання міжмережевий інформації про зонах.На малюнку - приклад ZIT.<br /> |}<br /> <br /> Протокол AEP виконує налагоджувальні і діагностичні функції, надаючи можливість виконання процедур ping (до якоїсь міри це аналог протоколу ICMP). При необхідності перевірити стан мережі або якого-небудь вузла надсилається AEP-дейтограмма. Протокол дозволяє перевірити час поширення пакетів між вузлами мережі. Протокол може використовуватися на початку будь-якої сесії для перевірки доступності того або іншого мережевого об'єкта.<br /> <br /> Протокол AURP є зовнішнім протоколом мережевої маршрутизації і служить для взаємодії мереж AppleTalk з Інтернет. Протокол підтримує технологію IP-тунелів з використанням UDP / IP інкапсуляції. Розсилка мережевої інформації здійснюється AURP тільки при виникненні будь-яких змін в стані мережі. Протокол AURP підтримує гнучку систему переадресацій, виключаючи конфлікти адрес при підключенні нових мереж AppleTalk, і виявляє маршрутні петлі. Існують спеціальні фільтри, які дозволяють розділяти пакети по пріоритетам, що буває важливо, наприклад, при передачі мультимедіа інформації. Мережі AppleTalk добре узгоджуються з іншими мережами, наприклад, NetWare. Слід мати на увазі, що ЕОМ, що працюють з протоколами Phase I і Phase II, можуть працювати один з одним тільки через спеціальні мости, так як формати пакетів для цих протоколів не сумісні.<br /> <br /> Управління мережами AppleTalk здійснюється за допомогою протоколу [[SNMP]] і керуючої бази даних [[MIB]] Віддалений доступ AppleTalk підтримується відповідно до AppleTalk Remote Access Protocol (Протокол віддаленого доступу AppleTalk, ARAP) і AppleTalk Control Protocol (Протокол керування AppleTalk, ATCP). ARAP - протокол комутованого з'єднання для комп'ютерів Apple Macintosh. Користувачі Macintosh з допомогою ARAP можуть віддалено підключатися до комп'ютера з підтримкою AppleTalk під управлінням Windows 2000, отримувати доступ до файлових томів Macintosh і принтерів АppleTalk. Підтримуються клієнти видаленого доступу AppleTalk (AppteTalk Remote Access client) версій 1.0, 2.x і 3.x. За допомогою ATCP клієнти Macintosh можуть працювати з мережевим протоколом AppleTalk поверх РРР, а віддалений користувач може отримати доступ до веб-серверам поверх TCP / IP, друкувати документи на принтерах AppleTalk, а також з'єднуватися з файловим сервером Macintosh (по TCP / IP або AppleTalk) по одному комутованому РРР-з'єднання.<br /> <br /> ==Особливості AppleTalk ==<br /> <br /> Подібно TCP/IP, AppleTalk використовує 32-розрядні адреси. Подібно до IP-адресу, адреса AppleTalk складається з двох компонентів: адреси мережі і адреси комп'ютера. На відміну від IP, довжина кожного з компонентів фіксована: 16 з 32 бітів виділені для представлення адреси мережі, а останні 16 бітів — для ідентифікації комп'ютера. У мережах AppleTalk підтримується процедура переговорів, що робляться для отримання комп'ютером мережевої адреси. Завдяки наявності такої процедури адміністратор позбавлений від необхідності явно указувати адреси. (Якщо ви захочете, можете задати адресу явно або запитати його з певного діапазону, але зазвичай в цьому немає потреби.)<br /> <br /> Окрім адрес для ідентифікації комп'ютерів в AppleTalk-сетях існує система імен, призначена для того, щоб спростити роботу користувачів. Кожному комп'ютеру привласнюється ім'я, крім того, для цього комп'ютера визначається приналежність до локальної групи машин, яка називається зоною. Повне ім'я складається з імені комп'ютера і імені зони. У невеликих мережах інформація про зону може не використовуватися, в цьому випадку комп'ютери ідентифікуються тільки за допомогою імені. [[Netatalk]] (основний пакет, призначений для підтримки AppleTalk в Linux) за умовчанням генерує AppleTalk-імена на базі доменних імен TCP/IP. Так, наприклад, якщо комп'ютеру відповідає доменне ім'я larch. threeroomco. com, Nettalk призначить йому ім'я larch. Інформація про домен при цьому буде загублена. Двокомпонентні імена істотно обмежують розміри AppleTalk-мереж, зокрема, створити мережу, що налічує більше декількох тисяч комп'ютерів, скрутно.<br /> <br /> Основне призначення AppleTalk - забезпечення сумісного використання файлів і принтерів. Багато мережевих принтерів можуть безпосередньо взаємодіяти за допомогою протоколу AppleTalk, а засоби розділення файлів підтримуються в MACOS, Windows NT і 2000, Linux, BEOS і інших операційних системах. Для вирішення інших завдань AppleTalk використовується лише в мережах, що складаються з комп'ютерів, які працюють під управлінням MACOS. У мережах, компоненти яких використовують інші операційні системи, доцільніше застосовувати інші стеки протоколів. Якщо до складу мережі входять різні машини, на комп'ютерах Macintosh встановлюють систему MACOS X, що забезпечує роботу з NFS.<br /> <br /> При маршрутизації пакетів AppleTalk за допомогою звичайних маршрутизаторів виникають серйозні труднощі. Щоб виключити можливість злому ззовні, можна заборонити підтримку TCP/IP на сервері Netatalk. Очевидно, що цей захід забезпечення безпеки не є єдино можливим.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A1%D1%82%D0%B5%D0%BA_%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D1%96%D0%B2 2011-12-18T20:55:00Z

<p>Aleksey: </p> <hr /> <div>'''Протокол''' (''protocols'') - це правила і технічні процедури, що дозволяють декільком комп'ютерам при об'єднанні в мережу спілкуватися один з одним.<br /> <br /> '''Стек комунікаційних протоколів''' - це комбінація протоколів. Кожен рівень визначає різні протоколи для управління функціями зв'язку або її підсистемами. Кожному рівню властивий свій набір правил.<br /> <br /> [[Мережеві протоколи]]<br /> <br /> Найважливішим напрямом стандартизації в області обчислювальних мереж є [[стандартизація]] комунікаційних протоколів. У наш час в мережах використовується велика кількість стеків комунікаційних протоколів. Найбільш популярними є стеки: [[TCP/IP]], [[IPX/SPX]], [[NetBIOS/SMB]], [[DECnet]], [[SNA]] і [[OSI]]. Всі ці стеки, крім SNA на нижніх рівнях фізичному і канальному, використовують одні і ті ж добре стандартизовані протоколи Ethernet, Token Ring, FDDI і деякі інші, які дозволяють використати у всіх мережах одну і ту ж апаратуру. Поте на верхніх рівнях всі стеки працюють по своїх власних протоколах. Ці протоколи часто не відповідають розбиттю, що рекомендується моделлю OSI на рівні. Зокрема, функції сеансового і представницького рівня, як правило, об'єднані з прикладним рівнем. Така невідповідність пов'язана з тим, що модель OSI з'явилася як результат узагальнення вже існуючих і стеків, що реально використовуються, а не навпаки.<br /> <br /> ----<br /> Стек [[OSI]]<br /> <br /> ----<br /> Стек [[TCP/IP]]<br /> <br /> ----<br /> Стек [[IPX/SPX]]<br /> <br /> ----<br /> Стек [[NetBIOS/SMB]]<br /> <br /> ----<br /> Стек [[SNA]]<br /> <br /> ----<br /> Стек [[DECnet]]<br /> <br /> ----<br /> Стек [[AppleTalk]]<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;2&quot;<br /> |+Відповідність популярних стеків протоколів моделі OSI<br /> |-<br /> ! Модель OSI !! IBM /Microsoft !! TCP/IP !! Novell !! Стек OSI<br /> <br /> |-<br /> ! Прикладний<br /> |rowspan=2| SMB <br /> |rowspan=2| <br /> {| bgcolor=#ABCDEF border=0<br /> |Telnet<br /> |-<br /> |bgcolor=#ABCDEF border=1 |FTP<br /> |-<br /> |bgcolor=#ABCDEF border=1 |[[SNMP]]<br /> |-<br /> |www<br /> |}<br /> |rowspan=3| <br /> {| bgcolor=#ABCDEF border=0<br /> |NCP<br /> |-<br /> | SAP<br /> |}<br /> ||<br /> {| bgcolor=#ABCDEF border=0<br /> |X.400<br /> |-<br /> |bgcolor=#ABCDEF border=1 |X.500<br /> |-<br /> | FTMA<br /> |}<br /> <br /> |-<br /> ! Представницький<br /> | Представницький протокол OSI<br /> |-<br /> ! Сеансовий<br /> |rowspan=2| NetBios || TCP || Сеансовий протокол OSI<br /> |-<br /> <br /> ! Транспортний<br /> | TCP || SPX || Транспортний протокол OSI<br /> <br /> |-<br /> ! Мережевий<br /> | || <br /> {| bgcolor=#ABCDEF border=0<br /> |IP<br /> |-<br /> |bgcolor=#ABCDEF border=1 |RIP<br /> |-<br /> | OSPF<br /> |}<br /> ||<br /> {| bgcolor=#ABCDEF border=0<br /> |IP<br /> |-<br /> |bgcolor=#ABCDEF border=1 |RIP<br /> |-<br /> | NLSP<br /> |}<br /> || <br /> {| bgcolor=#ABCDEF border=0<br /> |ES-TS<br /> |-<br /> | IS-IS<br /> |}<br /> <br /> |-<br /> ! Канальний<br /> |colspan=4| 802.3 (Ethernet), 802.5 (Token Ring), FDDI, Fast Ethernet, SLIP, 100VG-AnyLAN, X.25, ATM, LAP-B, LAP-D, PPP <br /> |-<br /> ! Фізичний<br /> |colspan=4| Коаксіальний, екранована і неекранована вита пара, оптичневолокно, радіохвилі<br /> |}<br /> <br /> <br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/IPX/SPX 2011-12-18T20:54:18Z

<p>Aleksey: </p> <hr /> <div>= Стек IPX/SPX =<br /> <br /> '''Стек IPX/SPX''' є оригінальним стеком протоколів фірми Novell, розробленим для мережевої операційної системи NetWare ще на початку 80-х років. Протоколи мережевого і сеансового рівнів Internetwork Packet Exchange (IPX) і Sequenced Packet Exchange (SPX), які й дали назву стеку, є прямою адаптацією протоколів XNS фірми Xerox, поширених набагато менше, ніж стек IPX/SPX. Популярність стека IPX/SPX безпосередньо пов'язана з операційною системою Novell NetWare, що ще зберігає світове лідерство за числом встановлених систем, хоча останнім часом її популярність дещо знизилася і за темпами росту вона відстає від Microsoft Windows NT.<br /> Багато особливостей стека IPX/SPX обумовлені орієнтацією ранніх версій ОС NetWare (до версії 4.0) на роботу в локальних мережах невеликих розмірів, що складаються з персональних комп'ютерів із скромними ресурсами. Зрозуміло, що для таких комп'ютерів компанії Novell потрібні були протоколи, для реалізації яких потрібна була б мінімальна кількість оперативної пам'яті (обмеженої в IBM-сумісних комп'ютерах під керуванням MS-DOS обсягом 640 Кбайт) і які б швидко працювали на процесорах невеликої обчислювальної потужності. У результаті, протоколи стека IPX/SPX донедавна добре працювали в локальних мережах, і не дуже – у великих корпоративних мережах, тому що вони занадто перевантажували повільні глобальні зв'язки широкомовними пакетами, що інтенсивно використовуються декількома протоколами цього стека (наприклад, для встановлення зв'язку між клієнтами і серверами). Ця обставина, а також той факт, що стек IPX/SPX є власністю фірми Novell і на його реалізацію потрібно одержувати ліцензію (тобто відкриті специфікації не підтримувалися), довгий час обмежували поширеність його тільки мережами NetWare. Проте з моменту випуску версії NetWare 4.0 Novell внесла і продовжує вносити у свої протоколи серйозні зміни, спрямовані на їхню адаптацію для роботи в корпоративних мережах. Зараз стек IPX/ SPX реалізований не тільки в NetWare, але й у декількох інших популярних мережевих ОС, наприклад SCO UNIX, Sun Solaris, Microsoft Windows NT.<br /> <br /> Сімейство протоколів фірми Novell і їх відповідність моделі ISO / OSI представлено на Мал 1. <br /> <br /> &lt;center&gt;[[Image:1 005.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt;Мал 1. Стек IPX/SPX&lt;/center&gt;<br /> <br /> На фізичному і канальном рівнях в мережах Novell використовуються всі популярні протоколи цих рівнів (Ethernet, Token Ring, FDDI та інші). <br /> <br /> На мережевому рівні в стеке Novell працює протокол IPX, а також протоколи обміну маршрутною інформацією RIP і NLSP (аналог протоколу OSPF стека TCP / IP). IPX є протоколом, який займається питаннями адресації і маршрутизації пакетів в мережах Novell. Маршрутні рішення IPX засновані на адресних полях в заголовку його пакету, а також на інформації, що надходить від протоколів обміну маршрутною інформацією. Наприклад, IPX використовує інформацію, що поставляється або протоколом RIP, або протоколом NLSP (NetWare Link State Protocol) для передачі пакетів комп'ютера призначення або наступного маршрутизатора. Протокол IPX підтримує тільки дейтаграммний спосіб обміну повідомленнями, за рахунок чого економно споживає обчислювальні ресурси. Отже, протокол IPX забезпечує виконання трьох функцій: завдання адреси, встановлення маршруту та розсилку дейтаграмм. <br /> <br /> Транспортному рівню моделі OSI в стеке Novell відповідає протокол SPX, який здійснює передачу повідомлень з встановленням сполук. <br /> <br /> На верхніх прикладному, представницькому і сеансовом рівнях працюють протоколи NCP і SAP. Протокол NCP (NetWare Core Protocol) є протоколом взаємодії сервера NetWare і оболонки робочої станції. Цей протокол прикладного рівня реалізує архітектуру клієнт-сервер на верхніх рівнях моделі OSI. За допомогою функцій цього протоколу робоча станція проводить підключення до сервера, відображає каталоги сервера на локальні букви дисководів, переглядає файлову систему сервера, копіює вилучені файли, змінює їх атрибути і т.п., а також здійснює розподіл мережевого принтера між робочими станціями. <br /> <br /> SAP (Service Advertising Protocol) - протокол оголошення про сервіс - концептуально подібний до протоколу RIP. Подібно до того, як протокол RIP дозволяє маршрутизаторам маршрутної обмінюватися інформацією, протокол SAP дає можливість мережних пристроям обмінюватися інформацією про наявні мережевих сервісах. <br /> <br /> Сервери та маршрутизатори використовують SAP для оголошення про своїх сервісних послуги та мережевих контактах. Протокол SAP дозволяє мережних пристроїв постійно коригувати дані про те, які сервісні послуги є зараз у мережі. При старті сервери використовують SAP для оповіщення що залишилася частини мережі про свої послуги. Коли сервер завершує роботу, то він використовує SAP для того, щоб сповістити мережа про припинення дії своїх послуг. <br /> <br /> У мережах Novell сервери NetWare 3.x кожну хвилину розсилають шіроковещательние пакети SAP. Пакети SAP в значній мірі засмічують мережу, тому однією з основних завдань маршрутизаторів, що виходять на глобальні зв'язку, є фільтрація трафіку SAP-пакетів і RIP-пакетів. <br /> <br /> Інформація взята [http://translate.google.com/translate?hl=uk&amp;sl=ru&amp;u=http://www.citforum.ru/nets/protocols/1_02_03.shtml&amp;sa=X&amp;oi=translate&amp;resnum=1&amp;ct=result&amp;prev=/search%3Fq%3D%25D0%25A1%25D1%2582%25D0%25B5%25D0%25BA%2BIPX/SPX%26hl%3Duk%26client%3Dopera%26rls%3Dru%26hs%3DoeZ звідси]<br /> <br /> == IPX - протокол ==<br /> <br /> <br /> Протокол '''IPX''' (''Internetwork Packet Exchange'') призначений для передачі дейтограмм в системах, неорієнтованих на з'єднання (також як і IP або NETBIOS, розроблений IBM і емульований в Novell), він забезпечує зв'язок між NetWare серверами і кінцевими станціями. Максимальний розмір IPX-дейтограмми становить 576 байт, з них 30 байта займає заголовок. Передбачається, що мережа, через яку транспортуються ці дейтограмми, здатна пересилати пакети відповідної довжини. IPX-пакети можуть розсилатися широкомовно, для цього поле типу має значення 0x14, адреса мережі призначення повинен відповідати локальної мережі, адреса вузла призначення при цьому приймає значення 0xFFFFFF.<br /> <br /> Оригінальний транспортний протокол Novell, на мій погляд, не сприяє успіху цієї мережі. Не встигнувши вчасно переорієнтуватися на транспортні й маршрутні протоколи стека TCP / IP цей украй популярний зовсім недавно вид мереж в даний час має шанси зникнути.<br /> <br /> IPX-пакети, що передаються по мережі Ethernet, можуть мати кілька різних форматів. Найстарший з них носить в Novell назву &quot;802.3&quot; і використовується за замовчанням в версіях аж до 3.11. У наступних версіях форматом за замовчанням є &quot;802.2&quot;. Використовуємо також і формат, названий Ethernet II, який найбільш близький ідеології TCP/IP. Мережа в Netware - це логічний канал, який використовується спільно рядом вузлів так, що вони можуть взаємодіяти один з одним безпосередньо. Так процеси, реалізовані на одному сервері, вважаються підключеними до внутрішньої IPX-мережі. Всі користувачі мережі типу Ethernet II утворюють логічну мережу IPX. Всі користувачі однієї мережі типу 802.3 розглядаються як вузли різних мереж IPX. Зіставлення форматів пакетів для різних мережевих стандартів представлено на Мал. 2.<br /> <br /> &lt;center&gt;[[Файл:Imag223.gif]]&lt;/center&gt;<br /> &lt;center&gt;Мал 2. Формати мережних пакетів&lt;/center&gt;<br /> <br /> З малюнка видно, що відмінності непринципові і не перешкоджають співіснування всіх перерахованих форматів у межах однієї локальної мережі. IPX-заголовок починається відразу після поля Тип або Довжина у залежності від використовуваного протоколу.<br /> <br /> Сервери Netware можна настроїти так, щоб вони сприймали пакети різних типів, і тому могли мати безпосередні зв'язки з різними мережами. IPX-сервер може виконувати і функції маршрутизатора. Формат заголовка пакета IPX зображений на Мал 3. За заголовком слідують дані, їх обсяг визначається кодом поля Довжина пакета (мінус 30) і лежить в діапазоні від 0 до 546 байт.<br /> <br /> &lt;center&gt;[[Файл:Imag224.gif]]&lt;/center&gt;<br /> &lt;center&gt;Мал 3. Формат заголовка IPX-пакета&lt;/center&gt;<br /> <br /> Поле Контрольна сума (2 байти) встановлюється IPX-драйвером рівним 0xffff, це означає, що контрольного підсумовування не проводилося. Додаткам дозволено використовувати поле контрольної суми при роботі з кадрами Ethernet II, ІЕЕЕ 802.2 і Ethernet SNAP і заборонено для роботи з кадрами ІЕЕЕ 802.3. Контрольна сума служить лише для контролю правильності IPX-заголовка і не має ніякого відношення до поля даних IPX-дейтаграми. Для того щоб працювати з контрольними сумами на NetWare-сервері, слід виконати команду set enable IPX checksum = n, де n вказує на те, що контрольна сума використана. Можливі значення n і їхній зміст наведено нижче в Таблиці 1 і Таблиці 2.<br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;2&quot;<br /> |+ Таблиця 1.Поля заголовка IPX пакета для сервера<br /> |-<br /> ! Код n !! Призначення для сервера <br /> |-<br /> ! 0<br /> | Контрольна сума не використовується <br /> |-<br /> ! 1<br /> | Контрольна сума використовується, якщо доступна клієнту <br /> |-<br /> ! 2<br /> | Контрольна сума повинна використовуватися <br /> |}<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;2&quot;<br /> |+ Таблиця 2.Поля заголовка IPX пакета для клієнта<br /> |-<br /> ! Код n !! Призначення для клієнта <br /> |-<br /> ! 0<br /> | Контрольна сума не використовується (за замовчуванням) <br /> |-<br /> ! 1<br /> | Контрольна сума використовується, але позбавлена ​​пріоритету<br /> |-<br /> ! 2<br /> | Контрольна сума використовується і має пріоритет<br /> |-<br /> ! 3<br /> | Контрольна сума повинна використовуватися<br /> |}<br /> &lt;/center&gt;<br /> <br /> <br /> <br /> Поле Довжина пакета (2 байти) містить число байт в пакеті, включаючи заголовок, і може бути в межах від 30 (тільки заголовок) до 576. Насправді максимальна довжина IPX-пакета дорівнює 1518 байт, але при проходженні пакетів через маршрутизатори, коли не використовується протокол LIP (large internet packet, протокол міжмережевого пересилання великих пакетів) максимальна довжина може бути рівна лише 576 байт (що й прийнято за замовчуванням). Слід також мати на увазі, що згідно регламентациям Novell довжина пакета може приймати лише парні значення. Програміст не повинен турбуватися про зміст цього поля, це за нього зробить сам протокол IPX. Поле у правління пересиланням (1 байт) встановлюється IPX-драйвером рівним нулю перед посилкою пакета. Кожен маршрутизатор збільшує значення цього поля на 1. Якщо пакет пройшов через 15 маршрутизаторів, черговий - видалить пакет з мережі (в певному сенсі це аналог поля час життя - TTL в протоколах TCP/IP). Поле управління пересиланням можна використовувати для оптимізації маршрутів в локальній мережі. Якщо станція спілкується тільки з серверами сусідній субмережі, її слід переключити туди і знизити тим самим навантаження маршрутизатора. Контроль за вмістом цього поля виконується протоколом IPX. Поле тип пакету (1 байт) встановлюється прикладною програмою. При використанні протоколу ipx це поле повинно містити нуль (або 4), у разі використання протоколу SPX - 5, а для протоколу NCP (Netware core protocol) -17. Поля адресу вузла призначення і а дрес вузла відправника містять 12-байтові структури ipxaddr_1. Ця структура включає в себе 4 байта адреси мережі (присвоюється адміністратором мережі при встановленні мережі Novell), 6 байт адреси вузла (фізична адреса, задається виробником мережевого інтерфейсу) і 2 байти дескриптора з'єднувача (socket, необхідний для адресації програми, що приймає пакети заповнююься додатком ). Пакети, адресовані серверу в NetWare 3.x або 4.x містять в полі адреси вузла одержувача код 0x00 00 00 00 00 01 (аналогічний код буде записаний в поле адресу відправника, якщо ним є сервер). Адреса ж вузла одержувача на рівні Ethernet або Token Ring дорівнюватиме фізичній мережевій адресі інтерфейсу або локального маршрутизатора, якщо сервер розміщений в іншій субмережі. З'єднувачі (socket) служать для управління обробки пакетів. Широкомовний пакет буде отриманий ЕОМ, якщо вона має відкритий з'єднувач для процесу, якому він адресований. З цієї причини повинні прийматися спеціальні заходи, щоб запобігти можливості посилки двома програмами пакетів різного типу на один і той же з'єднувач. Ряд номерів з'єднувачів зарезервовано IPX-протоколом для певних цілей:<br /> <br /> 2 - з'єднувач протокольних відгуків, 3 - обробник помилок.<br /> <br /> Деякі номери зайняті під потреби Netware:<br /> <br /> * '''0x451''' Протокол ядра NetWare (NCP - netware core protocol);<br /> <br /> * '''0x452 ''' Протокол NetWare для оповіщення про послуги (SAP - service advertising protocol);<br /> <br /> * '''0x453''' Маршрутний протокол NetWare (RIP - routing information protocol);<br /> <br /> * '''0x455 ''' Пакет протоколу netbios;<br /> <br /> * '''0x456 ''' Діагностичний протокол NetWare;<br /> <br /> * '''0x457 ''' Пакет серіалізациї (serialization).<br /> <br /> Дескриптори з'єднувачів для робочих станцій задаються динамічно та їх коди лежать в діапазоні 0x4000 - 0x8000. На відміну від протоколів TCP/IP IPX не має фіксованих адрес для мереж або інтерфейсів, які слід конфігурувати. Замість цього робочі станції отримують свої мережеві кімнати від маршрутизатора, до якого вони приєднані, і використовують Ethernet-адресу як номери вузла.<br /> <br /> Додаток повинен встановлювати поля тип пакета та адресу вузла призначення, а IPX-драйвер заповнює інші поля. Можливі значення коду поля тип пакета представлені в Таблиці 3.<br /> <br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;2&quot;<br /> |+ Таблиця 3. Коди типу IPX-пакета<br /> |-<br /> ! Тип пакета !! Значення<br /> |-<br /> ! 0<br /> | Звичайний IPX-пакет <br /> |-<br /> ! 1<br /> | Пакет з маршрутною інформацією (RIP - routing information protocol) <br /> |-<br /> ! 2<br /> | Відгук <br /> |-<br /> ! 3<br /> | Помилка <br /> |-<br /> ! 4<br /> | Інформаційний пакетний обмін (pep - packet exchange protocol) <br /> |-<br /> ! 5<br /> | Послідовний пакетний обмін (SPX - sequence packet exchange) <br /> |-<br /> ! 17<br /> | Протоколи ядра NetWare (NCP) <br /> |-<br /> ! 20<br /> | Іменний пакет netbios (широкомовний)<br /> |}<br /> &lt;/center&gt;<br /> <br /> <br /> Програма, що використовує IPX-протокол для передачі інформації повинна записувати в поле тип пакета код 4.<br /> <br /> Маршрутна інформація передається між серверами і маршрутизаторами. Динамічний маршрутний протокол RIP (routing information protocol, базується на стандарті Xerox IP) забезпечує кінцеві станції інформацією, яка необхідна для динамічного управління оптимізацією маршрутів. Розсилка маршрутної інформації проводиться за допомогою широкомовних пакетів. Як бачимо, мережі Novell є джерелом значних потоків широкомовних пакетів. Аналогічним чином об'єкти мережі оповіщаються про інші зміни в мережевому середовищі, наприклад, розсилка інформації про доступні послуги (SAP - service advertisement protocol). Протокол SAP дозволяє вузлам, які пропонують певні послуги (наприклад, файл-сервери або принт-сервери), повідомляти про свої адреси і видах доступних послуг. Адміністратор може регулювати потік таких пакетів, задаючи постійний час для таймерів оновлення інформації. Маршрутизатори розсилають маршрутну інформацію в п'яти випадках:<br /> <br /> * При ініціалізації.<br /> * У випадку, коли необхідна вихідна маршрутна інформація (напр. в разі збою або псування маршрутної таблиці).<br /> * Періодично для оновлення маршрутних таблиць.<br /> * При зміні конфігурації маршрутів.<br /> * При відмові або відключенні маршрутизатора.<br /> <br /> <br /> Маршрутизація пакетів в мережі досить проста. Кожному мережному сегменту маршрутизатор присвоює номер в межах від 1 до fffffffe. Кожній групі пристроїв присвоюється &quot;мережевий номер&quot;, який представляє цю групу у всіх маршрутизаторах мережі. Пакети що посилаються від одного члена групи іншому, надсилаються безпосередньо. Пакети від одного члена групи до об'єкту з іншої групи будуть переслані через маршрутизатори. Для вибору маршруту в межах локальної мережі використовується маршрутний протокол RIP. Формат пакета NetWare RIP зображений на Мал 4.<br /> <br /> &lt;center&gt;[[Файл:Imag225.gif]]&lt;/center&gt;<br /> &lt;center&gt;Мал 4. Формат RIP-пакета в NetWare&lt;/center&gt;<br /> <br /> Поле тип пакету містить код 0x0001, якщо це запит, і 0x0002, якщо відгук. У полі адреси мережі записується адреса мережі місця призначення, якщо пакет є запитом. Якщо в полі записаний код 0xff ff ff ff, це означає, що запит відноситься до всіх відомих мереж. Поле число кроків до мети має сенс лише у випадку пакетів-відгуків. У цьому випадку сюди заноситься число маршрутизаторів, які повинен пройти пакет по дорозі до мережі призначення. Поле час має сенс для пакетів-відгуків і вказує на час, необхідний для досягнення мережі адресата. Один час дорівнює 1 / 18 секунди. Подібний протокол маршрутизації використовується в мережах appletalk (RTMP).<br /> <br /> Для міжмережевої маршрутизації в Novell розроблений протокол NLSP (NetWare link services protocol). NLSP базується на тій же ідеології, що і протокол IS-IS (intermediate system-to-intermediate system), створений для мереж OSI і IP. У NLSP значення метрики маршруту задається вручну. nlsp-маршрутизатори зберігають повну карту мережі, по якій приймаються рішення про найкращих можливих маршрутах.<br /> <br /> На Мал 5. представлена ​​схема відповідності протоколів Novell і 7-рівневої моделі osi.<br /> <br /> &lt;center&gt;[[Файл:Imag226.gif]]&lt;/center&gt;<br /> &lt;center&gt;Мал 5. Схема відповідності протоколів Novell і моделі OSI&lt;/center&gt;<br /> <br /> Протокол SAP (service advertising protocol) служить для отримання інформації про всі сервера, що є в мережі, і підтримує такі види запитів та функції:<br /> <br /> * запит SAP-сервісу;<br /> * оповіщення про відключення сервера;<br /> * моніторинг відгуків і деякі інші.<br /> <br /> Кожному серверу NetWare присвоює номер, а деякі сервера можуть мати й ім'я. Номер сервера і його ім'я зберігаються в базі даних об'єктів bindary кожного сервера. Пакет запиту SAP-сервісу містить 2 байта типу пакету і два байти типу сервера. Поле тип пакета визначає, чи є даний пакет загальним запитом сервісу (код = 0x0003), або запитом найближчих послуг (код = 0x0001). Таблиця кодів поля тип сервера наведена нижче в Таблиці 4.<br /> <br /> <br /> &lt;center&gt;<br /> {| border=&quot;1&quot; cellpadding=&quot;2&quot;<br /> |+ Таблиця 4. Коди тип сервера<br /> |-<br /> ! Тип сервера !! Опис<br /> |-<br /> ! 0x0001<br /> | Користувач <br /> |-<br /> ! 0x0004<br /> | Файл-сервер<br /> |-<br /> ! 0x0005<br /> | Сервер завдань <br /> |-<br /> ! 0x0006<br /> | Зовнішній мережевий порт (gateway) <br /> |-<br /> ! 0x0007<br /> | Принт-сервер <br /> |-<br /> ! 0x0009<br /> | Сервер архіву <br /> |-<br /> ! 0x000a<br /> | Черга завдань<br /> |-<br /> ! 0x0017<br /> | Діагностика<br /> |-<br /> ! 0x0020<br /> | NetBios<br /> |-<br /> ! 0x0021<br /> | NAS SNA порт<br /> |-<br /> ! 0x0027<br /> | TCP/IP сервер порту<br /> |-<br /> ! 0x0028<br /> | Сервер моста x.25 точка-точка<br /> |-<br /> ! 0x02e<br /> | Динамічний SAP<br /> |-<br /> ! 0x0047<br /> | Сповіщає принт-сервер<br /> |-<br /> ! 0x004b<br /> | vap 5.0<br /> |-<br /> ! 0x004c<br /> | SQL VAP<br /> |-<br /> ! 0x007a<br /> | TES-NetWare VMS<br /> |-<br /> ! 0x0098<br /> | Сервер доступу до NetWare<br /> |-<br /> ! 0x009a<br /> | Сервер іменованих труб<br /> |-<br /> ! 0x009e<br /> | Портативний NetWare-Unix<br /> |-<br /> ! 0x0107<br /> | NetWare 386<br /> |-<br /> ! 0x0111<br /> | Тест-сервер<br /> |-<br /> ! 0x0166<br /> | Управління NetWare<br /> |-<br /> ! 0x026a<br /> | Управління NetWare<br /> |-<br /> ! 0x026b<br /> | Тимчасова синхронізація<br /> |-<br /> ! 0x0278<br /> | Сервер каталогів NetWare<br /> |}<br /> &lt;/center&gt;<br /> <br /> <br /> SAP-пакети-відгуки мають наступний формат (Мал. 6).<br /> <br /> &lt;center&gt;[[Файл:Imag227.gif]]&lt;/center&gt;<br /> &lt;center&gt;Мал 6. Формат пакета SAP&lt;/center&gt;<br /> <br /> Поле тип пакета приймає значення 0x0002 для SAP-відгуків загального обслуговування (General Service Response) і 0x0004 для відгуку найближчого сервера. Запити про найближче сервері використовуються для пошуку в мережі сервера конкретного різновиду (пакет запиту містить лише перші два поля). Реально відгук буде отримано від всіх серверів даного типу, а не тільки від найближчого. Наскільки цей сервер близький, визначається за кількістю маршрутизаторів до нього. Ці запити / відгуки служать для складання списку доступних серверів. Поле тип сервера містить код доступного виду послуг, а в полі найменування сервісу записується ім'я послуги унікальне для даного сервера (довжина поля на рис. 4.2.1.5 дорівнює N). Поле адреса мережі являє собою 4-байтове число, яке ідентифікує адресу сервера. Поле адресу сайту характеризує адресу сервера в мережі. Служби NetWare вказують адресу 0x00.00.00.00.00.01. Поле дескриптор з'єднувача характеризує код з'єднувача, який буде використовувати сервер. Останнє поле - число кроків до сервера (число транзитних мереж) характеризує число маршрутизаторів між сервером і клієнтом. При відключенні сервера від мережі він повинен широкомовно розіслати SAP-повідомлення &quot;Зупинка сервера&quot;. Повідомлення містить код сервера і його повна адреса.<br /> <br /> == SPX - протокол ==<br /> <br /> '''SPX''' ''(Sequence Packet eXchange)'' і його вдосконалена модифікація SPX II є транспортні протоколи 7-рівневої моделі ISO. Це протокол гарантує доставку пакета і використовує техніку ковзаючого вікна (віддалений аналог протоколу TCP). У разі втрати або помилки пакет пересилається повторно, число повторень задається програмно. У протоколі SPX не передбачена широкомовна або мультікастінг-адресація. У SPX індукується ситуація, коли партнер несподівано перериває з'єднання, наприклад через обрив зв'язку. Пакети SPX вкладаються в пакети IPX. При цьому у полі тип пакета IPX записується код 5. Заголовок пакета SPX завжди містить 42 байта, включаючи 30 байт заголовка IPX-пакета, куди він вкладений.<br /> <br /> &lt;center&gt;[[Файл:Imag228.gif]]&lt;/center&gt;<br /> &lt;center&gt;Мал 7. Формат заголовка SPX-пакета&lt;/center&gt;<br /> <br /> Поле управління з'єднанням визначає, чи є даний пакет системним чи прикладним. Це поле містить однобітові прапорці, використовувані spx і spx ІІ для управління потоком даних у віртуальному каналі.<br /> <br /> * '''0x01 XHD''' Зарезервовано SPX II для розширення заголовків;<br /> <br /> * '''0x02 RES1''' Призначення поля не визначено, має дорівнювати нулю;<br /> <br /> * '''0x04 NEG''' SPX II (SIZ) погоджує розмір запиту / відгуку, для spx має дорівнювати нулю;<br /> <br /> * '''0x08 SPX2''' Тип пакета SPX II, для spx має дорівнювати нулю;<br /> <br /> * '''0x10 EOM''' Встановлюється клієнтом spx для індикації кінця повідомлення (end-of-message);<br /> <br /> Поле тип потоку даних характеризує тип даних, поміщених в пакет. Значення цього поля перераховані нижче:<br /> <br /> * '''0x00-0x07''' визначається клієнтом і може використовуватися в додатках;<br /> <br /> * '''0x80-0xfb''' зарезервовані на майбутнє;<br /> <br /> * '''0xfc''' spx ІІ, впорядковане звільнення запиту;<br /> <br /> * '''0xfd''' spx ІІ, впорядковане звільнення підтвердження;<br /> <br /> * '''0xfe''' вказує на закінчення зв'язку (end-of-connection). При закритті каналу spx-драйвер посилає клієнтові пакет, де в полі тип потоку записаний даний код;<br /> <br /> * '''0xff''' підтвердження отримання повідомлення про закінчення зв'язку (end-of-connection-acknowledgment). Цим кодом позначається пакет, що підтверджує закриття каналу, в прикладну програму такий пакет не передається<br /> <br /> Поля ідентифікатора відправника і одержувача містять коди, що визначають учасників інформаційного обміну, присвоюються SPX-драйвером у момент встановлення зв'язку. У запитах на з'єднання це поле містить код 0xffff. Дане поле служить для забезпечення демультиплексування пакетів, що надходять на один і той же з'єднувач (socket). Поле послідовний номер визначає число пакетів пересланих в одному напрямку. Кожен з партнерів обміну має свій лічильник, який скидається в нуль після досягнення 0xffff, після чого рахунок може продовжуватися. Для програми це поле, також як і наступні два, недоторкане. spx-пакети підтвердження містять в цьому полі порядковий номер останнього посланого пакета. Поле номер підтвердження характеризує послідовний номер наступного пакета, який spx очікує отримати. Будь-який пакет з порядковим номером менше, ніж задано в полі номера підтвердження, доставлений благополучно і не вимагає ретрансміссіі. Поле число буферів служить для вказівки числа доступних на станції буферів (буфера нумеруються, починаючи з 0, один буфер здатний прийняти один пакет) і використовується для організації управління потоком даних між додатками. Код цього поля інформує партнера по найбільшому порядковому номері пакету, який може бути посланий. Протокол spx посилає пакети до тих пір, поки локальний послідовний номер не стане рівним числу-вказівником на віддаленій ЕОМ.<br /> <br /> SPX-протокол не посилає наступний пакет до тих пір, поки не отримає підтвердження отримання попереднього. Хоча в протоколі SPX передбачений алгоритм ковзаючих вікон (як і в TCP), практично він у даний час не використовується, що цілком виправдано для локальних мереж. Слід зауважити, що для досить великих LAN, де пакет проходить через кілька маршрутизаторів, нехтування технікою вікон стає недозволеною розкішшю. На випадок непередбачених обривів зв'язку в spx є алгоритм &quot;сторожова собака&quot;. Цей алгоритм реалізується спеціальною програмою, яка активується лише у випадку, коли протягом певного часу в каналі відсутній трафік в будь-якому з напрямів (машина все зробила, а оператор заснув). У цьому випадку програма посилає спеціальні пакети і, якщо через певне число спроб &quot;достукатися&quot; до партнера не вдається, сесія переривається. Якщо партнер не надсилає відгук за обумовлений час (RTT), проводиться повторна посилка пакета, при цьому RTT збільшується на 50%. Значення RTT не повинно перевищити величини max_retry_delay, яка за замовчуванням дорівнює 5 секундам. Якщо зв'язок не відновилася, відправник намагається знайти інший маршрут до адресата. Якщо маршрут знайдений, лічильник спроб скидається в нуль і процедура відправки запускається знову. Допустима кількість спроб може лежати в діапазоні 1-255 (за замовчуванням - 10). При відсутності успіху сесія переривається.<br /> <br /> Значення RTT визначається за часом відгуку найближчого маршрутизатора, яке подвоюється, а до отриманої величини додається деяка константа. Для кожної з сесій RTT визначається незалежно. Багаточасові константи задаються адміністратором мережі.<br /> <br /> Протокол spx дозволяє здійснити від 100 до 2000 з'єднань одночасно (за умовчанням це число дорівнює 1000). Конфігураційні параметри SPX-протоколу (і мережі) зберігаються в файлах shell.cfg і net.cfg.<br /> <br /> У 1992 році була розроблена нова версія SPX - SPX II. Головне удосконалення протоколу пов'язано із застосуванням пакетів більшого розміру. Раніше довгі spx-пакети фрагментувалися і пересилалися по частинах, враховуючи, що черговий пакет може бути посланий лише після отримання підтвердження, неважко зрозуміти крайню неефективність такої схеми. Стандарт spx дозволяє обмін пакетами з розміром, обмеженим тільки використовуваної мережевим середовищем. Так в Ethernet пакет SPX II може мати довжину 1518 байт. Крім того, SPX II допускає використання технології вікон, тобто можна послати кілька кадрів, не чекаючи отримання підтвердження на кожен з вже посланих. Розмір вікна встановлюється відповідно до кодом, що міститься в полі число-покажчик (число буферів / пакетів). При необхідності адміністратор може задати розмір вікна раз і назавжди. Формат пакетів SPX II дещо відрізняється від SPX. У SPX II збільшено число допустимих кодів для поля управління з'єднанням, введено додаткове поле в заголовок підтвердження (два байти, ім'я поля &quot;розширене підтвердження&quot;). Нове поле додано після поля число буферів. Алгоритм встановлення зв'язку в SPX II відрізняться від варіанту spx тим, що необхідно узгодити розмір пересилаються пакетів.<br /> <br /> * '''0x20 ATN''' (Attention) зарезервовано для спеціальних запитів (не підтримується SPX);<br /> <br /> * '''0x40 ACK''' Встановлюється для запиту підтвердження отримання даного пакету. Запити і відгуки обробляються на рівні SPX (додаток не повинно модифікувати цей код);<br /> <br /> * '''0x80 SYS''' Встановлюється, якщо даний пакет є системним і служить для підтвердження. Додатки не використовують пакети цього типу.<br /> <br /> &lt;center&gt;[[Файл:Imag229.gif]]&lt;/center&gt;<br /> &lt;center&gt;Мал 8. Формат заголовка SPX-II&lt;/center&gt;<br /> <br /> Управління мережами Novell здійснюється за допомогою стандартного протоколу [[SNMP]] (Simple Network Management Protocol) і керуючої бази даних MIB.<br /> <br /> ----<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/SNMP 2011-12-18T20:51:30Z

<p>Aleksey: </p> <hr /> <div>'''SNMP''' (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури [[TCP/IP]].<br /> <br /> ==Історія створення SNMP==<br /> <br /> Однією з найперших ініціатив з управління мережами була ініціатива ISO Open Systems Interconnection (OSI). Відповідні групи з стандартизації інфраструктури управління OSI (OSI Management Framework) були створені в 1981 році.<br /> <br /> До кінця 1980-х років мережа Інтернет стала досить великою і вимагала стандартів управління. Однак група ISO OSI була далека від завершення робіт над сімейством стандартів. Тому в 1987 році спільнотою IETF було прийнято рішення тимчасово створити набір спрощених стандартів управління в Інтернеті на основі напрацювань ISO OSI. Дані стандарти отримали назву Simple Network Management Protocol (SNMP). Надалі передбачалося перейти на стандарти ISO у міру їх готовності. Таким чином, багато ідей SNMP були взяті зі стандартів ISO:<br /> <br /> *Концепція «менеджер-агент»;<br /> <br /> *Ідея баз керуючої інформації (Management Information Bases, MIBs);<br /> <br /> *Використання синтаксису Abstract Syntax Notation One ([[ASN.1]]);<br /> <br /> *Частина термінології;<br /> <br /> Іншими проектом стандарту, на базі якого почалася розробка SNMP, був проект простого протоколу моніторингу шлюзів (Simple Gateway Monitoring Protocol, SGMP) співтовариства IETF.<br /> <br /> Надалі в рамках ISO OSI було запропоновано багато нових ідей, зокрема, об'єктно-орієнтований підхід. Однак ці ідеї вже не ввійшли в стандарти SNMP. Один час IETF продовжувала CMIP over TCP (CMOT), яка передбачала використання загального протоколу керуючої інформації (Common Management Information Protocol, CMIP) стека протоколів ISO OSI в стеку IETF TCP / IP. У 1992 році ця ініціатива була припинена у зв'язку з успіхом і поширеністю SNMP.<br /> <br /> Після багатьох засідань IAB (Internet Architecture Board) опублікував у квітні 1988 року епохальний RFC 1052: IAB Recommendations for the Development of Internet Network Management Standards, в якому закликав до якнайшвидшого створення елементів Простого Мережевого Управління (Simple Network Management).<br /> <br /> Багато ідей, що лежать сьогодні в основі SNMP, були запозичені у попередніх дослідженнях з моніторингу Internet-маршрутизаторів. І вже в серпні 1988 з'явилися три основні документа:<br /> <br /> *[http://tools.ietf.org/html/rfc1065 RFC 1065]: Structure and Identification of Management Information for TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]: Management Information Base for Network Management of TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]: A Simple Network Management Protocol.<br /> <br /> Згодом ці документи було перевидано і доповнено до визначення наступного покоління SNMP: RFC 1155, 1156 і 1157, які в свою чергу, також піддалися переробкам.<br /> <br /> Зрештою, у травні 1991 року була закінчена робота зі створення першої версії протоколу SNMPv1, яка знайшла своє відображення в зведенні таких документів:<br /> <br /> *[http://tools.ietf.org/html/rfc1155 RFC 1155]: Structure and Identification of Management Information for TCP / IP-based internets (Травень, 1990):<br /> - Визначає структуру керуючої інформації у вигляді глобального дерева.<br /> - Являє синтаксис визначення імен змінних управління.<br /> <br /> *[http://tools.ietf.org/html/rfc1212 RFC 1212]: Concise MIB Definitions (Березень, 1991)<br /> - Доповнює RFC 1155 в частині синтаксису визначення імен змінних.<br /> <br /> *[http://tools.ietf.org/html/rfc1213 RFC 1213]: Management Information Base for Network Management of TCP / IP-based internets: MIB-II (Березень, 1991):<br /> - Містить список більше ста найбільш необхідних змінних, що відповідають за конфігурацію, статус і статистику систем, що входять в TCP / IP мережі.<br /> <br /> *[http://tools.ietf.org/html/rfc1157 RFC 1157]: A Simple Network Management Protocol (SNMP) (Травень, 1990)<br /> - Визначає повідомлення, якими обмінюються керуюча станція і об'єкт управління для отримання та оновлення значення змінних.<br /> - Визначає trap (alarm)-повідомлення, що посилаються системою при значних змінах у її конфігурації.<br /> <br /> Опублікування цих стандартів стало поштовхом для виробників мережного обладнання, які розгорнули широкі роботи із забезпечення керованості:<br /> <br /> *всього спектра мережного обладнання - мостів, маршрутизаторів, модемів ...<br /> <br /> *широкого кола інтерфейсів - Point-to-Point, DS1, DS3, X.25, Frame Relay, Ethernet, Token Ring, FDDI, та ін.<br /> <br /> В загальному, стандарти SNMP продовжували розвиватися протягом 1990-х років. Основним напрямком розвитку було вдосконалення питань безпеки. Були розроблені наступні версії SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u і SNMPv3. Їх обговорення буде продовжено в розділі «Версії SNMP».<br /> <br /> ==Задачі==<br /> <br /> Сімейство стандартів SNMP створено для вирішення задач обробки помилок і аналізу продуктивності і надійності.<br /> <br /> '''Обробка помилок'''<br /> <br /> Виявлення, визначення і усунення наслідків збоїв і відмов у роботі мережі. На цьому рівні виконується реєстрація повідомлень про помилки, їх фільтрація, маршрутизація і аналіз на основі деякої кореляційної моделі.<br /> <br /> '''Аналіз продуктивності і надійності'''<br /> <br /> Оцінка на основі статистичної інформації таких параметрів, як час реакції системи, пропускна спроможність каналів зв'язку, інтенсивність трафіку в окремих сегментах мережі, імовірність спотворення даних, коефіцієнт готовності служб мережі. Результати такого аналізу дозволяють контролювати угоду про рівень обслуговування (Service Level Agreement, SLA).<br /> <br /> Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:<br /> <br /> *Широка сфера застосування. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;<br /> <br /> *Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;<br /> <br /> *Стійкість у критичних ситуаціях. Наприклад, при перевантаженні і проблемах в мережі, тобто при множинних помилках.<br /> <br /> ==Архітектура==<br /> <br /> Архітектуру розподіленої системи можна описати в термінах обробних елементів (або компонентів), що з'єднують елементів (або з'єднувачів) і елементів даних. Перерахуємо складові елементи системи управління SNMP:<br /> <br /> 1. компоненти:<br /> <br /> *агент;<br /> <br /> *менеджер;<br /> <br /> 2. з'єднувачі:<br /> <br /> *транспортний протокол;<br /> <br /> *Протокольні блоки даних (Protocol Data Units, PDU) і повідомлення SNMP;<br /> <br /> 3. дані:<br /> <br /> *Керуюча інформація MIB;<br /> <br /> Опишемо детальніше і проаналізуємо архітектуру SNMP з позиції досягнення поставлених перед SNMP цілей. Для цього використовуємо поняття архітектурного стилю мережевого програмного забезпечення. Архітектурний стиль - це узгоджений набір архітектурних обмежень, накладених на ролі і особливості архітектурних елементів (компонентів, з'єднувачів і даних) і відносин між ними, яка проявляється у будь-якій архітектурі, і яка задовольняє цьому стилю.<br /> <br /> ===Компоненти===<br /> <br /> Архітектура SNMP передбачає побудову системи управління за схемою «менеджер-агент», тобто використання архітектурного стилю «клієнт-сервер». Система SNMP містить безліч керованих вузлів, на кожному з яких розміщується досить простий сервер - агент SNMP, а також, принаймні, один вузол, що містить складного клієнта - менеджера SNMP.<br /> <br /> Менеджер взаємодіє з агентами за допомогою протоколу SNMP з метою обміну керуючою інформацією. В основному, ця взаємодія реалізується у вигляді періодичного опитування менеджером множини агентів, так як агенти всього лише надають доступ до інформації, але не знають, що їм з нею робити. Видно, що система, побудована за такими принципами, втрачає масштабованость, оскільки є виділений клієнт, який займається опитуванням всіх серверів. Зате така схема забезпечує простоту реалізації систем під управлінням SNMP.<br /> <br /> Для підвищення масштабованості та адміністративної керованості вводиться поняття проксі-агента, який може переправляти операції протоколу SNMP, а також поняття менеджера проміжного рівня, який приховує несуттєві подробиці керуючої інформації від систем управління мережами верхнього рівня, інтегруючи одержувані від агентів дані. Це дозволяє створювати багаторівневі системи управління, що відповідають архітектурному стилю «багаторівневий клієнт-сервер».<br /> <br /> Більш детальна класифікація компонентів за ролями:<br /> <br /> 1. Менеджер:<br /> <br /> *Менеджер проміжного рівня;<br /> <br /> *Система управління мережами;<br /> <br /> 2. Агент:<br /> <br /> * Мінімальний агент;<br /> <br /> * Проксі-агент;<br /> <br /> Компоненти в SNMP узагальнено називаються сутностями SNMP.<br /> <br /> ===Дані===<br /> <br /> Тепер розглянемо дані, якими маніпулюють системи SNMP, тобто керуючу інформацію. У SNMP кожний керований пристрій, на якому розташований агент, представляє свою керуючу інформацію у вигляді змінних. Такими змінними можуть бути, наприклад, ім'я системи, час з моменту її перезапуску, записи в таблиці маршрутизації і т. д. В загальному випадку змінні можна розділити на:<br /> <br /> *Скалярні змінні;<br /> <br /> *Таблиці змінних;<br /> <br /> Схема даних описується структурою керуючої інформації (Structure of Management Information, SMI). Схема даних визначає, як виглядає керуюча інформація, тобто описує її синтаксис. SMI базується на Abstract Syntax Notation One ([[ASN.1]]).<br /> <br /> Конкретні набори керуючої інформації для різних типів пристроїв, протоколів і т. д. описуються базами керуючої інформації (Management Information Bases, MIBs). Бази MIB визначають, яка управляюча інформація існує. Наприклад, для пристрою, що підтримує IP, MIB описує таблицю маршрутизації, прапорець активації функції маршрутизації, число переданих і прийнятих пакетів, число помилок різного характеру і т. д.<br /> <br /> Таким чином, кожен пристрій містить набір значень змінних, визначених у деякій кількості MIB, описаних за правилами SMI. Цей набір змінних і є даними, що управляє інформацією для протоколу SNMP.<br /> <br /> Важливим питанням є іменування змінних. У SNMP кожній змінній присвоюється унікальний ідентифікатор об'єкта (Object Identifier, OID). Простір імен OID є ієрархічним і контролюється організацією по розподілу номерів в Інтернеті (Internet Assigned Numbers Authority, IANA). Кожен компонент імені є числом. В текстовому вигляді імена записуються як десяткові числа, розділені крапками, зліва направо. Числам можуть бути поставлені у відповідність текстові рядки для зручності сприйняття. У цілому, структура імені схожа на систему доменних імен Інтернету (Domain Name System, DNS).<br /> <br /> Кожна MIB визначає набір змінних, тобто певну гілку дерева OID, що описує керуючу інформацію в певній галузі. Наприклад, гілка 1.3.6.1.2.1.1 (мнемонічний еквівалент: iso.org.dod.internet.mgmt.mib-2.system) описує загальну інформацію про систему. Опишемо деякі змінні з цієї гілки:<br /> <br /> *sysDescr (1.3.6.1.2.1.1.1) - короткий опис системи;<br /> <br /> *sysUpTime (1.3.6.1.2.1.1.3) - час з моменту останнього перезапуску;<br /> <br /> *sysName (1.3.6.1.2.1.1.5) - назва системи.<br /> <br /> Змінні і відомості про їхній тип визначені також в MIB. А самі типи змінних - в SMI.<br /> <br /> Крім безпосередньо даних, необхідно ввести операції над ними. Набір цих операцій змінювався і розширювався в міру розвитку SNMP. Основними операціями є:<br /> <br /> *Читання змінної;<br /> <br /> *Запис змінної;<br /> <br /> *Читання змінної, наступної за заданою змінною (необхідне для перегляду таблиць змінних);<br /> <br /> Більш докладно операції над даними описані нижче при обговоренні з'єднувачів в архітектурі SNMP.<br /> <br /> В цілому, операції над даними в SNMP схожі на віддалене налагодження деякої програми: стан системи описується певним набором змінних, які можна переглядати і змінювати.<br /> <br /> ===З'єднувачі===<br /> <br /> Для обміну даними між компонентами використовуються з'єднувачі. У разі SNMP в якості з'єднувача використовується протокол прикладного рівня Simple Network Management Protocol (SNMP), що звичайно працює поверх стека протоколів TCP / IP.<br /> <br /> Розглянемо стек протоколів більш докладно, вказавши прив'язку протоколів до Open Systems Interconnection Reference Model (OSI RM).<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;№&lt;/td&gt;<br /> &lt;td&gt;Протокол&lt;/td&gt;<br /> &lt;td&gt;Коментарі&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;7&lt;/td&gt;<br /> &lt;td&gt;SNMP&lt;/td&gt;<br /> &lt;td&gt;Повідомлення, PDU, операції&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;6&lt;/td&gt;<br /> &lt;td&gt;[[ASN.1]] BER&lt;/td&gt;<br /> &lt;td&gt;Кодування даних&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;5&lt;/td&gt;<br /> &lt;td&gt;-&lt;/td&gt;<br /> &lt;td&gt;-&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;4&lt;/td&gt;<br /> &lt;td&gt;UDP&lt;/td&gt;<br /> &lt;td&gt;Транспорт між службами&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;3&lt;/td&gt;<br /> &lt;td&gt;IP&lt;/td&gt;<br /> &lt;td&gt;Зв'язок між вузлами мережі&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> SNMP вводить свій протокол прикладного рівня. Є чотири версії даного протоколу: SNMPv1, SNMPv2, SNMPv2c і SNMPv3. У процесі розвитку SNMP розширювалися можливі операції, тобто типи протокольних блоків даних (Protocol Data Units, PDUs), а також вводилися нові формати повідомлень SNMP для забезпечення безпеки.<br /> <br /> Повідомлення SNMP містить номер версії SNMP, інформацію про безпеку та протокольний блок даних PDU, який характеризує виконувану операцію і її параметри. Наприклад, SNMPv1 описує наступні PDU і відповідні операції:<br /> <br /> *Get-Request - запит на отримання значень 1 .. N змінних;<br /> <br /> *Get-Next-Request - запит на отримання значень 1 .. N змінних, чиї OID йдуть слідом за OID зазначених 1 .. N змінних;<br /> <br /> *Get-Response - відповідь на запити Get-Request, Get-Next-Request і Set-Request;<br /> <br /> *Set-Request - установка значень 1 .. N змінних;<br /> <br /> *Trap - пастка (див. нижче);<br /> <br /> SNMP - це протокол типу &quot;запит-відповідь&quot;, тобто на кожен запит, що надійшов від менеджера, агент повинен передати відповідь.<br /> <br /> [[Файл:ZaprOtv.gif]]<br /> <br /> Описані PDU, як уже згадувалося, є частиною повідомлення SNMP. Повідомлення кодуються для передачі по мережі за допомогою [[ASN.1]] Basic Encoding Rules (BER). Це функція шостого рівня (рівня подання) еталонної моделі OSI. Далі закодовані повідомлення відправляються одним компонентом SNMP іншого за допомогою транспортного протоколу.<br /> <br /> Як вже зазначалося, стандарт передбачає використання різного транспорту для SNMP, але майже завжди використовується протокол користувацьких датаграм (User Datagram Protocol, UDP). Агенти використовують добре відомий порт UDP 161. Цей протокол надає мінімальні транспортні послуги (доставка повідомлень від служби до служби і перевірка контрольної суми) і не передбачає організацію сеансів і потокову передачу даних, як Transmission Control Protocol (TCP). За рахунок цього вдається домогтися великої швидкості реакції і швидкодії, що відповідає поставленим перед SNMP цілям.<br /> <br /> Для підвищення швидкості реакції менеджера на термінові події вводиться спеціальний тип операції протоколу SNMP, так звана «пастка» (Trap). Він дозволяє агентам асинхронно інформувати менеджера (за власною ініціативою) про настання обмеженого числа значущих подій. У цьому випадку агент виступає в незвичній для себе ролі клієнта, а менеджер - в ролі сервера. У разі використання транспорту UDP для вхідних з'єднань менеджер використовує добре відомий порт UDP 162.<br /> <br /> Як ми бачимо, жодна з цих операцій не припускає, що агент зберігає інформацію про сесії з менеджером. Для виконання операції Trap така інформація зберігається статично, тобто сесія в такому випадку статична і перманентна. Крім цього операції SNMP визначають єдині, уніфіковані інтерфейси агентів і менеджерів SNMP. Таким чином, SNMP - це протокол без збереження стану, який відповідає архітектурному стилю «уніфікований багаторівневий клієнт-сервер без збереження стану».<br /> <br /> Опишемо деякі властивості операцій SNMP на прикладі SNMPv1:<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Ім'я&lt;/td&gt;<br /> &lt;td&gt;Безпека&lt;/td&gt;<br /> &lt;td&gt;Підтвердження&lt;/td&gt;<br /> &lt;td&gt;Ідемпотентність&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Request&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Next-Request&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Response&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Set-Request&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Trap&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> Таким чином, ми розглянули всі основні архітектурні особливості SNMP, крім моделей безпеки. Питання, пов'язані із захистом інформації, будуть розглянуті нижче при обговоренні версій стандартів SNMP.<br /> <br /> ==Відповідність архітектурному стилю REST==<br /> <br /> Архітектурний стиль REST - це уніфікований багаторівневий клієнт-серверний стиль, з кодом за запитом та без збереження стану (Unified-Layered-Code-on-Demand-Client-Cached-Stateless-Server, ULCODCСSS). Як ми визначили в результаті аналізу архітектури SNMP, система SNMP визначається уніфікованим багаторівневим клієнт-серверних стилем без збереження стану (Unified-Layered-Client-Stateless-Server, ULCSS).<br /> <br /> Як ми бачимо, на SNMP не накладаються обмеження, пов'язані з реплікацією (наявність кеша) і мобільним кодом (застосування коду за вимогою). У цьому сенсі стиль SNMP - більш вільний, ніж REST, тобто містить менше архітектурних особливостей, які, наприклад, необхідно враховувати при моделюванні систем з такою архітектурою.<br /> <br /> Однак, навіть у SNMPv1 є особлива операція Trap, що ініціюється агентом асинхронно по відношенню до менеджера. У SNMPv2 вводиться операція Inform-Request, яка також виконується асинхронно, але між двома менеджерами. При виконанні таких операцій клієнт і сервер міняються ролями. При цьому використовується принцип інтеграції на основі повідомлень. Це елементи однорангового стилю взаємодії (Peer-to-Peer), хоча в даному випадку ролі клієнта і сервера для конкретних типів протокольних операцій виражені явно. У цьому сенсі стиль SNMP - більш обмежений, ніж REST.<br /> <br /> Таким чином, при певних обмеженнях система SNMP може бути розглянута як REST-івська розподілена система.<br /> <br /> ==Структура стандартів==<br /> <br /> Стандарти SNMP описують аспекти, відображені нижче:<br /> <br /> 1. Загальна інформація;<br /> <br /> 2. Обробка повідомлень (SNMP Messages):<br /> <br /> *Прив'язки до транспорту;<br /> <br /> *Розбір і диспетчеризація повідомлень;<br /> <br /> *Безпека (аутентифікація, шифрування, своєчасність);<br /> <br /> 3. Обробка протокольних блоків даних (SNMP PDUs):<br /> <br /> *Операції протоколу;<br /> <br /> *Програми SNMP;<br /> <br /> *Управління доступом;<br /> <br /> 4. Інформаційна модель:<br /> <br /> *Структура керуючої інформації (SMI);<br /> <br /> *Текстові конвенції;<br /> <br /> *Вирази відповідності;<br /> <br /> 5. Модулі баз керуючої інформації (MIB);<br /> <br /> Спочатку в стандартах виділялися не всі ці аспекти. Проте, структура стандартів SNMP всіх версій вписується в цю схему.<br /> <br /> ==Інформаційна безпека==<br /> <br /> Розглянемо, як враховуються в SNMP основні елементи інформаційної безпеки:<br /> <br /> *Конфіденційність;<br /> <br /> *Цілісність;<br /> <br /> *Доступність;<br /> <br /> *Контрольованість;<br /> <br /> У ході розвитку стандартів SNMP інфраструктура безпеки піддавалася найбільших змін. Для того, щоб простежити ці зміни, спочатку опишемо вимоги безпеки та загрози, потім структуру моделей безпеки, після чого розглянемо використання в різних версіях SNMP моделі.<br /> <br /> ===Вимоги та загрози безпеці===<br /> <br /> Опишемо вимоги безпеки в архітектурі SNMP. Загрозами безпеці, проти яких повинна надавати захист будь-яка модель безпеки SNMP, є:<br /> <br /> 1. Первинні загрози:<br /> <br /> *Модифікація інформації;<br /> <br /> *Маскарад;<br /> <br /> 2. Вторинні загрози:<br /> <br /> *Модифікація потоку повідомлень;<br /> <br /> *Розголошення;<br /> <br /> Загроза модифікації інформації - це можливість того, що деяка неавторизована сутність може змінити повідомлення SNMP, згенеровані за запитом авторизованого принципала, на шляху їх слідування таким чином, що це призведе до неавторизованих операцій управління, включаючи фальсифікацію значення об'єкта (змінної).<br /> <br /> Загроза маскараду - це можливість того, що операції управління, не авторизовані для деякого принципала, можуть бути виконані при підстановці ідентифікатора іншого принципала, для якого подібні дії авторизовані.<br /> <br /> Загроза модифікації потоку повідомлень полягає в наступному. Протокол SNMP звичайно що грунтується на транспортній службі без організації з'єднання. Перестановка, затримка або повторна посилка повідомлень може відбуватися і відбувається в ході звичайної експлуатації мереж із застосуванням таких протоколів. Загроза модифікацій потоку повідомлень - це можливість того, що повідомлення можуть бути переставлені, затримані чи повторно надіслані зі злим умислом із затримками, які перевищують наявне місце затримки при нормальній експлуатації, з метою виконання неавторизованих операцій управління.<br /> <br /> Загроза розголошення - це можливість прослуховування обмінів повідомленнями між сутностями SNMP. Захист від цієї загрози може вимагати локальної політики безпеки.<br /> <br /> Модель безпеки може не боротися з такими загрозами, як, наприклад, відмова в обслуговуванні, оскільки стан мережевих збоїв і помилок (нормальне для SNMP) часто не відрізняються від ситуацій відмови в обслуговуванні.<br /> <br /> Як ми побачимо нижче, на практиці не кожна модель безпеки SNMP задовольняє вимогам нейтралізації перерахованих загроз.<br /> <br /> ===Структура моделей безпеки===<br /> <br /> Сутність SNMP містить дві підсистеми:<br /> <br /> *Підсистема безпеки;<br /> <br /> *Підсистема управління доступом;<br /> <br /> Підсистема безпеки функціонує на рівні повідомлень SNMP. Вона відповідає за аутентифікацію, шифрування і своєчасність. Документ з безпеки описує модель безпеки, загрози, проти яких вона захищає, цілі моделі безпеки, протоколи, використовувані для досягнення цих цілей, модуль MIB, що описує відповідні структури даних. Такий модуль потрібний у тому числі і для того, щоб віддалено конфігурувати параметри безпеки рівня повідомлень SNMP.<br /> <br /> Підсистема управління доступом функціонує на рівні SNMP PDU. Очевидно, що вона відповідає за управління доступом до керованих об'єктів (змінних). Документи, що описують її, також визначають модуль MIB для віддаленого налаштування параметрів.<br /> <br /> ===Моделі безпеки===<br /> <br /> Перелічимо основні моделі безпеки та відповідні їм інфраструктури:<br /> 1. SNMPv1:<br /> <br /> *SNMPv1 - Community-based Security Model;<br /> <br /> 2. SNMPv2:<br /> <br /> *SNMPv2p - Party-based Security Model;<br /> <br /> *SNMPv2c - Community-based Security Model;<br /> <br /> *SNMPv2u - User-based Security Model;<br /> <br /> 3. SNMPv3<br /> <br /> *SNMPv3 USM User-based Security Model.<br /> <br /> Модель безпеки на основі спільнот (Community-based Security Model) була першою, найпростішою і найбезпечнішою. Вона полягає лише у аутентифікації на основі «рядка спільноти», фактично, пароля, переданого по мережі в тексті повідомлення SNMP у відкритому вигляді. Ця модель безпеки не в змозі боротися ні з однією із загроз інформаційної безпеки в SNMP. Тим не менш, вона часто використовується до цих пір у зв'язку зі своєю простотою, а також завдяки наявності зовнішніх, не пов'язаних з SNMP систем безпеки, наприклад, міжмережевих екранів.<br /> <br /> Модель безпеки на основі сторін (Party-based Security Model) передбачає введення поняття сторони. Сторона - це віртуальне оточення виконання, в якому набір допустимих операцій обмежений адміністративно. Сутність SNMP при обробці повідомлення діє як сторона, тому обмежена операціями, визначеними для цієї сторони. Сторона визначається наступними параметрами:<br /> <br /> *Унікальний ідентифікатор сторони;<br /> <br /> *Логічна мережева адреса (область адрес транспортного протоколу та адреса транспортного протоколу);<br /> <br /> *Протокол аутентифікації і параметри, що вимагаються для аутентифікації всіх повідомлень сторони;<br /> <br /> *Протокол шифрування і параметри, потрібні для шифрування всіх повідомлень сторони;<br /> <br /> Можуть використовуватися різні алгоритми для протоколів аутентифікації і шифрування. Звичайно як алгоритму для протоколу аутентифікації використовують хеш-функцію Message Digest 5 (MD5), а для протоколу шифрування - алгоритм Data Encryption Standard (DES) в режимі Cipher Block Chaining (CBC).<br /> <br /> Запроваджуються й інші поняття, що використовуються для реалізації цієї моделі. Проте тут вони докладно не розглядаються, так само як і деталі функціонування моделі. Зазначимо лише, що при використанні відповідних протоколів аутентифікації і шифрування модель успішно справляється з описаними вище загрозами безпеці SNMP. Дана модель безпеки не була широко прийнята, оскільки є занадто складною і заплутаною.<br /> <br /> Модель безпеки на основі користувачів (User-based Security Model) вводить поняття користувача, від імені якого діє сутність SNMP. Цей користувач характеризується ім'ям користувача, використовуваними протоколами аутентифікації і шифрування, а також закритим ключем аутентифікації і шифрування. Аутентифікація і шифрування є необов'язковими. Їх наявність описується одним з параметрів моделі, якістю обслуговування (Quality of Service, QoS). Модель безпеки багато в чому схожа на модель сторін, але вона спрощує ідентифікацію користувачів, розподіл ключів і протокольні операції.<br /> <br /> ==Версії SNMP==<br /> <br /> Коротко опишемо відмінності між версіями SNMP і документи, що визначають ці версії. Зауважимо, що тут наведено перші версії RFC кожної з версій SNMP, тобто майже всі з них були заміщені новішими RFC і визнані застарілими. На даний момент єдиною не застарілою версією SNMP є SNMPv3, визначена в RFC 3411-3418.<br /> <br /> ===SNMPv1===<br /> Перші RFC, що описують стандарти SNMP, з'явилися в 1988 році. Версія 1 піддалася критиці за її слабку модель безпеки на основі спільнот. У той час безпека в Інтернеті не входила в коло першочергових завдань робочих груп IETF.<br /> <br /> 1. Обробка повідомлень<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]. A Simple Network Management Protocol;<br /> <br /> 2. Обробка PDU<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]. A Simple Network Management Protocol;<br /> <br /> 3. Інформаційна модель<br /> <br /> *Структура керуючої інформації<br /> [http://tools.ietf.org/html/rfc1065 RFC 1065]. Structure and Identification of Management Information for TCP / IP-based internets<br /> <br /> 4. Модулі MIB<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]. Management Information Base for Network Management of TCP / IP-based internets<br /> <br /> ===SNMPv2===<br /> <br /> Версія 2, відома, як Party-based SNMPv2, або SNMPv2p, не отримала широкого розповсюдження через серйозні розбіжності з приводу інфраструктури безпеки в стандарті.<br /> <br /> SNMPv2 поліпшував версію 1 в області швидкодії, безпеки, конфіденційності і взаємодій «менеджер-менеждер». Він представив новий тип PDU Get-Bulk-Request, альтернативу Get-Next-Request для отримання великих обсягів інформації за допомогою одного запиту. Проте, нова система безпеки на основі сторін виглядала для багатьох як надто складна і не була широко визнана.<br /> <br /> 1. Загальна інформація<br /> <br /> *[http://tools.ietf.org/html/rfc1441 RFC 1441]. Introduction to version 2 of the Internet-standard Network Management Framework<br /> <br /> *[http://tools.ietf.org/html/rfc1452 RFC 1452]. Coexistence between version 1 and version 2 of the Internet-standard Network <br /> Management Framework<br /> <br /> 2. Обробка повідомлень<br /> <br /> *Прив'язки до транспорту. [http://tools.ietf.org/html/rfc1448 RFC 1448]. Transport Mappings for SNMPv2<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc1446 RFC 1446]. Security Protocols for SNMPv2<br /> <br /> 3. Обробка PDU<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc1445 RFC 1445]. Administrative Model for SNMPv2<br /> <br /> *Протокольні операції. [http://tools.ietf.org/html/rfc1448 RFC 1448]. Protocol Operations for SNMPv2<br /> <br /> 4. Інформаційна модель<br /> <br /> *Структура керуючої інформації. [http://tools.ietf.org/html/rfc1442 RFC 1442]. Structure of Management Information SNMPv2<br /> <br /> *Текстові конвенції. [http://tools.ietf.org/html/rfc1443 RFC 1443]. Textual Conventions for SNMPv2<br /> <br /> *Вирази відповідності. [http://tools.ietf.org/html/rfc1444 RFC 1444]. Conformance Statements for SNMPv2<br /> <br /> 5. Модулі MIB<br /> <br /> *[http://tools.ietf.org/html/rfc1447 RFC 1447]. Party MIB for SNMPv2<br /> <br /> *[http://tools.ietf.org/html/rfc1450 RFC 1450]. MIB for SNMPv2<br /> <br /> *[http://tools.ietf.org/html/rfc1451 RFC 1451]. Manager-to-Manager MIB<br /> <br /> ===SNMPv2c===<br /> <br /> Community-based SNMPv2, або SNMPv2c, представив SNMPv2 без нової моделі безпеки версії 2. Замість неї пропонувалося використовувати стару модель безпеки версії 1 на основі спільнот. Відповідну пропозицію RFC було прийнято тільки як чернетку стандарту, однак стало де факто стандартом SNMPv2. Безпека SNMP знову опинилася невирішеним питанням.<br /> <br /> 1. Обробка повідомлень<br /> *Безпека. [http://tools.ietf.org/html/rfc1901 RFC 1901]. Introduction to Community-based SNMPv2<br /> <br /> ===SNMPv2u===<br /> <br /> User-based SNMPv2, або SNMPv2u, є компромісом між незахищеністю SNMPv1 і надмірною складністю SNMPv2p. Запропонована модель безпеки на основі користувачів була покладена в основу SNMPv3.<br /> <br /> 1. Обробка повідомлень<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc1909 RFC 1909] - An Administrative Infrastructure for SNMPv2 [http://tools.ietf.org/html/rfc1910 RFC 1910] - User-based Security Model for SNMPv2<br /> <br /> 2. Обробка PDU<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc1909 RFC 1909]. An Administrative Infrastructure for SNMPv2<br /> <br /> ===SNMPv3===<br /> <br /> SNMPv3 нарешті вирішив проблеми з безпекою способом, який багато хто вважав прийнятним. Версія 3 SNMP прийнята IETF як стандарт Інтернету (IETF STD 62). Майже всі попередні RFC визнані застарілими.<br /> <br /> 1. Загальна інформація<br /> *[http://tools.ietf.org/html/rfc3411 RFC 3411]. An Architecture for Describing SNMP Management Frameworks<br /> <br /> 2. Обробка повідомлень<br /> <br /> *Прив'язки до транспорту. [http://tools.ietf.org/html/rfc3417 RFC 3417]. Transport Mappings for the SNMP<br /> <br /> *Розбір і диспетчеризація повідомлень. [http://tools.ietf.org/html/rfc3412 RFC 3412]. Message Processing and Dispatching for the SNMP<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc3414 RFC 3414]. User-based Security Model (USM) for SNMPv3<br /> <br /> 3. Обробка PDU<br /> <br /> *Операції протоколу. [http://tools.ietf.org/html/rfc3416 RFC 3416]. Version 2 of the Protocol Operations for SNMP<br /> <br /> *Програми SNMP. [http://tools.ietf.org/html/rfc3413 RFC 3413]. SNMP Applications<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc3415 RFC 3415]. View-based Access Control Model (VACM) for the SNMP<br /> <br /> 4. Модулі MIB. [http://tools.ietf.org/html/rfc3418 RFC 3418]. MIB for the SNMP<br /> <br /> ==Існуючі реалізації==<br /> <br /> Підтримка SNMP - у багатьох значущих системах управління мережами, зокрема:<br /> <br /> *HP Network Node Manager;<br /> <br /> *IBM Tivoli NetView;<br /> <br /> *OpenNMS<br /> <br /> ==Недоліки SNMP==<br /> <br /> Протокол SNMP служить основою багатьох систем управління, хоча має кілька принципових недоліків, які перераховані нижче:<br /> <br /> *Відсутність засобів взаємної аутентифікації агентів і менеджерів. Єдиним засобом, який можна було б віднести до засобів аутентифікації, є використання в повідомленнях так званого рядка «community string». Цей рядок передається по мережі у відкритій формі в повідомленні SNMP і служить основою для поділу агентів і менеджерів на «спільноти», так що агент взаємодіє тільки з тими менеджерами, які вказують в поле community string такий же символьний рядок, що й рядок, який зберігається в пам'яті агента. Це, безумовно, не спосіб аутентифікації, а спосіб структурування агентів і менеджерів. Версія SNMP v.2 повинна була ліквідувати цей недолік, але в результаті розбіжностей між розробниками стандарту нові засоби аутентифікації хоча і з'явилися в цій версії, але як необов'язкові.<br /> <br /> *Робота через ненадійний протокол UDP (а саме так працює переважна більшість реалізації агентів SNMP) призводить до втрат аварійних повідомлень (повідомлень trap) від агентів до менеджерів, що може призвести до неякісного управління. <br /> <br /> ==Висновки==<br /> <br /> *SNMP широко використовується для управління мережами, особливо IP-мережами<br /> <br /> *Успіх SNMP в порівнянні з іншими стандартами управління показує переваги процесу стандартизації IETF<br /> <br /> *Історія розвитку SNMP показує важливість завдань захисту інформації<br /> <br /> *Архітектура SNMP цікава для аналізу архітектури мережевого програмного забезпечення; вона відповідає поставленим перед SNMP цілям<br /> <br /> *Архітектура SNMP відповідає архітектурному стилю ULCSS мережевого програмного забезпечення<br /> <br /> *У SNMP для вирішення функцій 6 рівня моделі OSI RM використовується [[ASN.1]], що незвично для стандартів IETF і позитивно впливає на питання формалізації протоколів, однозначності стандартів, зручності проектування додатків<br /> <br /> *Структура стандартів SNMP добре продумана і показова для вивчення стандартів<br /> <br /> *Лише деякі моделі безпеки SNMP відповідають поставленим перед системою безпеки SNMP цілям<br /> <br /> *Агенти та менеджери SNMP прості в програмній реалізації, проте завжди потрібно пам'ятати про інформаційну безпеку<br /> <br /> <br /> <br /> <br /> [[Засоби моніторингу та аналізу мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/SNMP 2011-12-18T20:49:55Z

<p>Aleksey: </p> <hr /> <div>'''SNMP''' (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури [[TCP/IP]].<br /> <br /> ==Історія створення SNMP==<br /> <br /> Однією з найперших ініціатив з управління мережами була ініціатива ISO Open Systems Interconnection (OSI). Відповідні групи з стандартизації інфраструктури управління OSI (OSI Management Framework) були створені в 1981 році.<br /> <br /> До кінця 1980-х років мережа Інтернет стала досить великою і вимагала стандартів управління. Однак група ISO OSI була далека від завершення робіт над сімейством стандартів. Тому в 1987 році спільнотою IETF було прийнято рішення тимчасово створити набір спрощених стандартів управління в Інтернеті на основі напрацювань ISO OSI. Дані стандарти отримали назву Simple Network Management Protocol (SNMP). Надалі передбачалося перейти на стандарти ISO у міру їх готовності. Таким чином, багато ідей SNMP були взяті зі стандартів ISO:<br /> <br /> *Концепція «менеджер-агент»;<br /> <br /> *Ідея баз керуючої інформації (Management Information Bases, MIBs);<br /> <br /> *Використання синтаксису Abstract Syntax Notation One ([[ASN.1]]);<br /> <br /> *Частина термінології;<br /> <br /> Іншими проектом стандарту, на базі якого почалася розробка SNMP, був проект простого протоколу моніторингу шлюзів (Simple Gateway Monitoring Protocol, SGMP) співтовариства IETF.<br /> <br /> Надалі в рамках ISO OSI було запропоновано багато нових ідей, зокрема, об'єктно-орієнтований підхід. Однак ці ідеї вже не ввійшли в стандарти SNMP. Один час IETF продовжувала CMIP over TCP (CMOT), яка передбачала використання загального протоколу керуючої інформації (Common Management Information Protocol, CMIP) стека протоколів ISO OSI в стеку IETF TCP / IP. У 1992 році ця ініціатива була припинена у зв'язку з успіхом і поширеністю SNMP.<br /> <br /> Після багатьох засідань IAB (Internet Architecture Board) опублікував у квітні 1988 року епохальний RFC 1052: IAB Recommendations for the Development of Internet Network Management Standards, в якому закликав до якнайшвидшого створення елементів Простого Мережевого Управління (Simple Network Management).<br /> <br /> Багато ідей, що лежать сьогодні в основі SNMP, були запозичені у попередніх дослідженнях з моніторингу Internet-маршрутизаторів. І вже в серпні 1988 з'явилися три основні документа:<br /> <br /> *[http://tools.ietf.org/html/rfc1065 RFC 1065]: Structure and Identification of Management Information for TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]: Management Information Base for Network Management of TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]: A Simple Network Management Protocol.<br /> <br /> Згодом ці документи було перевидано і доповнено до визначення наступного покоління SNMP: RFC 1155, 1156 і 1157, які в свою чергу, також піддалися переробкам.<br /> <br /> Зрештою, у травні 1991 року була закінчена робота зі створення першої версії протоколу SNMPv1, яка знайшла своє відображення в зведенні таких документів:<br /> <br /> *[http://tools.ietf.org/html/rfc1155 RFC 1155]: Structure and Identification of Management Information for TCP / IP-based internets (Травень, 1990):<br /> - Визначає структуру керуючої інформації у вигляді глобального дерева.<br /> - Являє синтаксис визначення імен змінних управління.<br /> <br /> *[http://tools.ietf.org/html/rfc1212 RFC 1212]: Concise MIB Definitions (Березень, 1991)<br /> - Доповнює RFC 1155 в частині синтаксису визначення імен змінних.<br /> <br /> *[http://tools.ietf.org/html/rfc1213 RFC 1213]: Management Information Base for Network Management of TCP / IP-based internets: MIB-II (Березень, 1991):<br /> - Містить список більше ста найбільш необхідних змінних, що відповідають за конфігурацію, статус і статистику систем, що входять в TCP / IP мережі.<br /> <br /> *[http://tools.ietf.org/html/rfc1157 RFC 1157]: A Simple Network Management Protocol (SNMP) (Травень, 1990)<br /> - Визначає повідомлення, якими обмінюються керуюча станція і об'єкт управління для отримання та оновлення значення змінних.<br /> - Визначає trap (alarm)-повідомлення, що посилаються системою при значних змінах у її конфігурації.<br /> <br /> Опублікування цих стандартів стало поштовхом для виробників мережного обладнання, які розгорнули широкі роботи із забезпечення керованості:<br /> <br /> *всього спектра мережного обладнання - мостів, маршрутизаторів, модемів ...<br /> <br /> *широкого кола інтерфейсів - Point-to-Point, DS1, DS3, X.25, Frame Relay, Ethernet, Token Ring, FDDI, та ін.<br /> <br /> В загальному, стандарти SNMP продовжували розвиватися протягом 1990-х років. Основним напрямком розвитку було вдосконалення питань безпеки. Були розроблені наступні версії SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u і SNMPv3. Їх обговорення буде продовжено в розділі «Версії SNMP».<br /> <br /> ==Задачі==<br /> <br /> Сімейство стандартів SNMP створено для вирішення задач обробки помилок і аналізу продуктивності і надійності.<br /> <br /> '''Обробка помилок'''<br /> <br /> Виявлення, визначення і усунення наслідків збоїв і відмов у роботі мережі. На цьому рівні виконується реєстрація повідомлень про помилки, їх фільтрація, маршрутизація і аналіз на основі деякої кореляційної моделі.<br /> <br /> '''Аналіз продуктивності і надійності'''<br /> <br /> Оцінка на основі статистичної інформації таких параметрів, як час реакції системи, пропускна спроможність каналів зв'язку, інтенсивність трафіку в окремих сегментах мережі, імовірність спотворення даних, коефіцієнт готовності служб мережі. Результати такого аналізу дозволяють контролювати угоду про рівень обслуговування (Service Level Agreement, SLA).<br /> <br /> Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:<br /> <br /> *Широка сфера застосування. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;<br /> <br /> *Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;<br /> <br /> *Стійкість у критичних ситуаціях. Наприклад, при перевантаженні і проблемах в мережі, тобто при множинних помилках.<br /> <br /> ==Архітектура==<br /> <br /> Архітектуру розподіленої системи можна описати в термінах обробних елементів (або компонентів), що з'єднують елементів (або з'єднувачів) і елементів даних. Перерахуємо складові елементи системи управління SNMP:<br /> <br /> 1. компоненти:<br /> <br /> *агент;<br /> <br /> *менеджер;<br /> <br /> 2. з'єднувачі:<br /> <br /> *транспортний протокол;<br /> <br /> *Протокольні блоки даних (Protocol Data Units, PDU) і повідомлення SNMP;<br /> <br /> 3. дані:<br /> <br /> *Керуюча інформація MIB;<br /> <br /> Опишемо детальніше і проаналізуємо архітектуру SNMP з позиції досягнення поставлених перед SNMP цілей. Для цього використовуємо поняття архітектурного стилю мережевого програмного забезпечення. Архітектурний стиль - це узгоджений набір архітектурних обмежень, накладених на ролі і особливості архітектурних елементів (компонентів, з'єднувачів і даних) і відносин між ними, яка проявляється у будь-якій архітектурі, і яка задовольняє цьому стилю.<br /> <br /> ===Компоненти===<br /> <br /> Архітектура SNMP передбачає побудову системи управління за схемою «менеджер-агент», тобто використання архітектурного стилю «клієнт-сервер». Система SNMP містить безліч керованих вузлів, на кожному з яких розміщується досить простий сервер - агент SNMP, а також, принаймні, один вузол, що містить складного клієнта - менеджера SNMP.<br /> <br /> Менеджер взаємодіє з агентами за допомогою протоколу SNMP з метою обміну керуючою інформацією. В основному, ця взаємодія реалізується у вигляді періодичного опитування менеджером множини агентів, так як агенти всього лише надають доступ до інформації, але не знають, що їм з нею робити. Видно, що система, побудована за такими принципами, втрачає масштабованость, оскільки є виділений клієнт, який займається опитуванням всіх серверів. Зате така схема забезпечує простоту реалізації систем під управлінням SNMP.<br /> <br /> Для підвищення масштабованості та адміністративної керованості вводиться поняття проксі-агента, який може переправляти операції протоколу SNMP, а також поняття менеджера проміжного рівня, який приховує несуттєві подробиці керуючої інформації від систем управління мережами верхнього рівня, інтегруючи одержувані від агентів дані. Це дозволяє створювати багаторівневі системи управління, що відповідають архітектурному стилю «багаторівневий клієнт-сервер».<br /> <br /> Більш детальна класифікація компонентів за ролями:<br /> <br /> 1. Менеджер:<br /> <br /> *Менеджер проміжного рівня;<br /> <br /> *Система управління мережами;<br /> <br /> 2. Агент:<br /> <br /> * Мінімальний агент;<br /> <br /> * Проксі-агент;<br /> <br /> Компоненти в SNMP узагальнено називаються сутностями SNMP.<br /> <br /> ===Дані===<br /> <br /> Тепер розглянемо дані, якими маніпулюють системи SNMP, тобто керуючу інформацію. У SNMP кожний керований пристрій, на якому розташований агент, представляє свою керуючу інформацію у вигляді змінних. Такими змінними можуть бути, наприклад, ім'я системи, час з моменту її перезапуску, записи в таблиці маршрутизації і т. д. В загальному випадку змінні можна розділити на:<br /> <br /> *Скалярні змінні;<br /> <br /> *Таблиці змінних;<br /> <br /> Схема даних описується структурою керуючої інформації (Structure of Management Information, SMI). Схема даних визначає, як виглядає керуюча інформація, тобто описує її синтаксис. SMI базується на Abstract Syntax Notation One ([[ASN.1]]).<br /> <br /> Конкретні набори керуючої інформації для різних типів пристроїв, протоколів і т. д. описуються базами керуючої інформації (Management Information Bases, MIBs). Бази MIB визначають, яка управляюча інформація існує. Наприклад, для пристрою, що підтримує IP, MIB описує таблицю маршрутизації, прапорець активації функції маршрутизації, число переданих і прийнятих пакетів, число помилок різного характеру і т. д.<br /> <br /> Таким чином, кожен пристрій містить набір значень змінних, визначених у деякій кількості MIB, описаних за правилами SMI. Цей набір змінних і є даними, що управляє інформацією для протоколу SNMP.<br /> <br /> Важливим питанням є іменування змінних. У SNMP кожній змінній присвоюється унікальний ідентифікатор об'єкта (Object Identifier, OID). Простір імен OID є ієрархічним і контролюється організацією по розподілу номерів в Інтернеті (Internet Assigned Numbers Authority, IANA). Кожен компонент імені є числом. В текстовому вигляді імена записуються як десяткові числа, розділені крапками, зліва направо. Числам можуть бути поставлені у відповідність текстові рядки для зручності сприйняття. У цілому, структура імені схожа на систему доменних імен Інтернету (Domain Name System, DNS).<br /> <br /> Кожна MIB визначає набір змінних, тобто певну гілку дерева OID, що описує керуючу інформацію в певній галузі. Наприклад, гілка 1.3.6.1.2.1.1 (мнемонічний еквівалент: iso.org.dod.internet.mgmt.mib-2.system) описує загальну інформацію про систему. Опишемо деякі змінні з цієї гілки:<br /> <br /> *sysDescr (1.3.6.1.2.1.1.1) - короткий опис системи;<br /> <br /> *sysUpTime (1.3.6.1.2.1.1.3) - час з моменту останнього перезапуску;<br /> <br /> *sysName (1.3.6.1.2.1.1.5) - назва системи.<br /> <br /> Змінні і відомості про їхній тип визначені також в MIB. А самі типи змінних - в SMI.<br /> <br /> Крім безпосередньо даних, необхідно ввести операції над ними. Набір цих операцій змінювався і розширювався в міру розвитку SNMP. Основними операціями є:<br /> <br /> *Читання змінної;<br /> <br /> *Запис змінної;<br /> <br /> *Читання змінної, наступної за заданою змінною (необхідне для перегляду таблиць змінних);<br /> <br /> Більш докладно операції над даними описані нижче при обговоренні з'єднувачів в архітектурі SNMP.<br /> <br /> В цілому, операції над даними в SNMP схожі на віддалене налагодження деякої програми: стан системи описується певним набором змінних, які можна переглядати і змінювати.<br /> <br /> ===З'єднувачі===<br /> <br /> Для обміну даними між компонентами використовуються з'єднувачі. У разі SNMP в якості з'єднувача використовується протокол прикладного рівня Simple Network Management Protocol (SNMP), що звичайно працює поверх стека протоколів TCP / IP.<br /> <br /> Розглянемо стек протоколів більш докладно, вказавши прив'язку протоколів до Open Systems Interconnection Reference Model (OSI RM).<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;№&lt;/td&gt;<br /> &lt;td&gt;Протокол&lt;/td&gt;<br /> &lt;td&gt;Коментарі&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;7&lt;/td&gt;<br /> &lt;td&gt;SNMP&lt;/td&gt;<br /> &lt;td&gt;Повідомлення, PDU, операції&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;6&lt;/td&gt;<br /> &lt;td&gt;[[ASN.1]] BER&lt;/td&gt;<br /> &lt;td&gt;Кодування даних&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;5&lt;/td&gt;<br /> &lt;td&gt;-&lt;/td&gt;<br /> &lt;td&gt;-&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;4&lt;/td&gt;<br /> &lt;td&gt;UDP&lt;/td&gt;<br /> &lt;td&gt;Транспорт між службами&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;3&lt;/td&gt;<br /> &lt;td&gt;IP&lt;/td&gt;<br /> &lt;td&gt;Зв'язок між вузлами мережі&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> SNMP вводить свій протокол прикладного рівня. Є чотири версії даного протоколу: SNMPv1, SNMPv2, SNMPv2c і SNMPv3. У процесі розвитку SNMP розширювалися можливі операції, тобто типи протокольних блоків даних (Protocol Data Units, PDUs), а також вводилися нові формати повідомлень SNMP для забезпечення безпеки.<br /> <br /> Повідомлення SNMP містить номер версії SNMP, інформацію про безпеку та протокольний блок даних PDU, який характеризує виконувану операцію і її параметри. Наприклад, SNMPv1 описує наступні PDU і відповідні операції:<br /> <br /> *Get-Request - запит на отримання значень 1 .. N змінних;<br /> <br /> *Get-Next-Request - запит на отримання значень 1 .. N змінних, чиї OID йдуть слідом за OID зазначених 1 .. N змінних;<br /> <br /> *Get-Response - відповідь на запити Get-Request, Get-Next-Request і Set-Request;<br /> <br /> *Set-Request - установка значень 1 .. N змінних;<br /> <br /> *Trap - пастка (див. нижче);<br /> <br /> SNMP - це протокол типу &quot;запит-відповідь&quot;, тобто на кожен запит, що надійшов від менеджера, агент повинен передати відповідь.<br /> <br /> [[Файл:ZaprOtv.gif]]<br /> <br /> Описані PDU, як уже згадувалося, є частиною повідомлення SNMP. Повідомлення кодуються для передачі по мережі за допомогою [[ASN.1]] Basic Encoding Rules (BER). Це функція шостого рівня (рівня подання) еталонної моделі OSI. Далі закодовані повідомлення відправляються одним компонентом SNMP іншого за допомогою транспортного протоколу.<br /> <br /> Як вже зазначалося, стандарт передбачає використання різного транспорту для SNMP, але майже завжди використовується протокол користувацьких датаграм (User Datagram Protocol, UDP). Агенти використовують добре відомий порт UDP 161. Цей протокол надає мінімальні транспортні послуги (доставка повідомлень від служби до служби і перевірка контрольної суми) і не передбачає організацію сеансів і потокову передачу даних, як Transmission Control Protocol (TCP). За рахунок цього вдається домогтися великої швидкості реакції і швидкодії, що відповідає поставленим перед SNMP цілям.<br /> <br /> Для підвищення швидкості реакції менеджера на термінові події вводиться спеціальний тип операції протоколу SNMP, так звана «пастка» (Trap). Він дозволяє агентам асинхронно інформувати менеджера (за власною ініціативою) про настання обмеженого числа значущих подій. У цьому випадку агент виступає в незвичній для себе ролі клієнта, а менеджер - в ролі сервера. У разі використання транспорту UDP для вхідних з'єднань менеджер використовує добре відомий порт UDP 162.<br /> <br /> Як ми бачимо, жодна з цих операцій не припускає, що агент зберігає інформацію про сесії з менеджером. Для виконання операції Trap така інформація зберігається статично, тобто сесія в такому випадку статична і перманентна. Крім цього операції SNMP визначають єдині, уніфіковані інтерфейси агентів і менеджерів SNMP. Таким чином, SNMP - це протокол без збереження стану, який відповідає архітектурному стилю «уніфікований багаторівневий клієнт-сервер без збереження стану».<br /> <br /> Опишемо деякі властивості операцій SNMP на прикладі SNMPv1:<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Ім'я&lt;/td&gt;<br /> &lt;td&gt;Безпека&lt;/td&gt;<br /> &lt;td&gt;Підтвердження&lt;/td&gt;<br /> &lt;td&gt;Ідемпотентність&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Request&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Next-Request&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Response&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Set-Request&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Trap&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> Таким чином, ми розглянули всі основні архітектурні особливості SNMP, крім моделей безпеки. Питання, пов'язані із захистом інформації, будуть розглянуті нижче при обговоренні версій стандартів SNMP.<br /> <br /> ==Відповідність архітектурному стилю REST==<br /> <br /> Архітектурний стиль REST - це уніфікований багаторівневий клієнт-серверний стиль, з кодом за запитом та без збереження стану (Unified-Layered-Code-on-Demand-Client-Cached-Stateless-Server, ULCODCСSS). Як ми визначили в результаті аналізу архітектури SNMP, система SNMP визначається уніфікованим багаторівневим клієнт-серверних стилем без збереження стану (Unified-Layered-Client-Stateless-Server, ULCSS).<br /> <br /> Як ми бачимо, на SNMP не накладаються обмеження, пов'язані з реплікацією (наявність кеша) і мобільним кодом (застосування коду за вимогою). У цьому сенсі стиль SNMP - більш вільний, ніж REST, тобто містить менше архітектурних особливостей, які, наприклад, необхідно враховувати при моделюванні систем з такою архітектурою.<br /> <br /> Однак, навіть у SNMPv1 є особлива операція Trap, що ініціюється агентом асинхронно по відношенню до менеджера. У SNMPv2 вводиться операція Inform-Request, яка також виконується асинхронно, але між двома менеджерами. При виконанні таких операцій клієнт і сервер міняються ролями. При цьому використовується принцип інтеграції на основі повідомлень. Це елементи однорангового стилю взаємодії (Peer-to-Peer), хоча в даному випадку ролі клієнта і сервера для конкретних типів протокольних операцій виражені явно. У цьому сенсі стиль SNMP - більш обмежений, ніж REST.<br /> <br /> Таким чином, при певних обмеженнях система SNMP може бути розглянута як REST-івська розподілена система.<br /> <br /> ==Структура стандартів==<br /> <br /> Стандарти SNMP описують аспекти, відображені нижче:<br /> <br /> 1. Загальна інформація;<br /> <br /> 2. Обробка повідомлень (SNMP Messages):<br /> <br /> *Прив'язки до транспорту;<br /> <br /> *Розбір і диспетчеризація повідомлень;<br /> <br /> *Безпека (аутентифікація, шифрування, своєчасність);<br /> <br /> 3. Обробка протокольних блоків даних (SNMP PDUs):<br /> <br /> *Операції протоколу;<br /> <br /> *Програми SNMP;<br /> <br /> *Управління доступом;<br /> <br /> 4. Інформаційна модель:<br /> <br /> *Структура керуючої інформації (SMI);<br /> <br /> *Текстові конвенції;<br /> <br /> *Вирази відповідності;<br /> <br /> 5. Модулі баз керуючої інформації (MIB);<br /> <br /> Спочатку в стандартах виділялися не всі ці аспекти. Проте, структура стандартів SNMP всіх версій вписується в цю схему.<br /> <br /> ==Інформаційна безпека==<br /> <br /> Розглянемо, як враховуються в SNMP основні елементи інформаційної безпеки:<br /> <br /> *Конфіденційність;<br /> <br /> *Цілісність;<br /> <br /> *Доступність;<br /> <br /> *Контрольованість;<br /> <br /> У ході розвитку стандартів SNMP інфраструктура безпеки піддавалася найбільших змін. Для того, щоб простежити ці зміни, спочатку опишемо вимоги безпеки та загрози, потім структуру моделей безпеки, після чого розглянемо використання в різних версіях SNMP моделі.<br /> <br /> ===Вимоги та загрози безпеці===<br /> <br /> Опишемо вимоги безпеки в архітектурі SNMP. Загрозами безпеці, проти яких повинна надавати захист будь-яка модель безпеки SNMP, є:<br /> <br /> 1. Первинні загрози:<br /> <br /> *Модифікація інформації;<br /> <br /> *Маскарад;<br /> <br /> 2. Вторинні загрози:<br /> <br /> *Модифікація потоку повідомлень;<br /> <br /> *Розголошення;<br /> <br /> Загроза модифікації інформації - це можливість того, що деяка неавторизована сутність може змінити повідомлення SNMP, згенеровані за запитом авторизованого принципала, на шляху їх слідування таким чином, що це призведе до неавторизованих операцій управління, включаючи фальсифікацію значення об'єкта (змінної).<br /> <br /> Загроза маскараду - це можливість того, що операції управління, не авторизовані для деякого принципала, можуть бути виконані при підстановці ідентифікатора іншого принципала, для якого подібні дії авторизовані.<br /> <br /> Загроза модифікації потоку повідомлень полягає в наступному. Протокол SNMP звичайно що грунтується на транспортній службі без організації з'єднання. Перестановка, затримка або повторна посилка повідомлень може відбуватися і відбувається в ході звичайної експлуатації мереж із застосуванням таких протоколів. Загроза модифікацій потоку повідомлень - це можливість того, що повідомлення можуть бути переставлені, затримані чи повторно надіслані зі злим умислом із затримками, які перевищують наявне місце затримки при нормальній експлуатації, з метою виконання неавторизованих операцій управління.<br /> <br /> Загроза розголошення - це можливість прослуховування обмінів повідомленнями між сутностями SNMP. Захист від цієї загрози може вимагати локальної політики безпеки.<br /> <br /> Модель безпеки може не боротися з такими загрозами, як, наприклад, відмова в обслуговуванні, оскільки стан мережевих збоїв і помилок (нормальне для SNMP) часто не відрізняються від ситуацій відмови в обслуговуванні.<br /> <br /> Як ми побачимо нижче, на практиці не кожна модель безпеки SNMP задовольняє вимогам нейтралізації перерахованих загроз.<br /> <br /> ===Структура моделей безпеки===<br /> <br /> Сутність SNMP містить дві підсистеми:<br /> <br /> *Підсистема безпеки;<br /> <br /> *Підсистема управління доступом;<br /> <br /> Підсистема безпеки функціонує на рівні повідомлень SNMP. Вона відповідає за аутентифікацію, шифрування і своєчасність. Документ з безпеки описує модель безпеки, загрози, проти яких вона захищає, цілі моделі безпеки, протоколи, використовувані для досягнення цих цілей, модуль MIB, що описує відповідні структури даних. Такий модуль потрібний у тому числі і для того, щоб віддалено конфігурувати параметри безпеки рівня повідомлень SNMP.<br /> <br /> Підсистема управління доступом функціонує на рівні SNMP PDU. Очевидно, що вона відповідає за управління доступом до керованих об'єктів (змінних). Документи, що описують її, також визначають модуль MIB для віддаленого налаштування параметрів.<br /> <br /> ===Моделі безпеки===<br /> <br /> Перелічимо основні моделі безпеки та відповідні їм інфраструктури:<br /> 1. SNMPv1:<br /> <br /> *SNMPv1 - Community-based Security Model;<br /> <br /> 2. SNMPv2:<br /> <br /> *SNMPv2p - Party-based Security Model;<br /> <br /> *SNMPv2c - Community-based Security Model;<br /> <br /> *SNMPv2u - User-based Security Model;<br /> <br /> 3. SNMPv3<br /> <br /> *SNMPv3 USM User-based Security Model.<br /> <br /> Модель безпеки на основі спільнот (Community-based Security Model) була першою, найпростішою і найбезпечнішою. Вона полягає лише у аутентифікації на основі «рядка спільноти», фактично, пароля, переданого по мережі в тексті повідомлення SNMP у відкритому вигляді. Ця модель безпеки не в змозі боротися ні з однією із загроз інформаційної безпеки в SNMP. Тим не менш, вона часто використовується до цих пір у зв'язку зі своєю простотою, а також завдяки наявності зовнішніх, не пов'язаних з SNMP систем безпеки, наприклад, міжмережевих екранів.<br /> <br /> Модель безпеки на основі сторін (Party-based Security Model) передбачає введення поняття сторони. Сторона - це віртуальне оточення виконання, в якому набір допустимих операцій обмежений адміністративно. Сутність SNMP при обробці повідомлення діє як сторона, тому обмежена операціями, визначеними для цієї сторони. Сторона визначається наступними параметрами:<br /> <br /> *Унікальний ідентифікатор сторони;<br /> <br /> *Логічна мережева адреса (область адрес транспортного протоколу та адреса транспортного протоколу);<br /> <br /> *Протокол аутентифікації і параметри, що вимагаються для аутентифікації всіх повідомлень сторони;<br /> <br /> *Протокол шифрування і параметри, потрібні для шифрування всіх повідомлень сторони;<br /> <br /> Можуть використовуватися різні алгоритми для протоколів аутентифікації і шифрування. Звичайно як алгоритму для протоколу аутентифікації використовують хеш-функцію Message Digest 5 (MD5), а для протоколу шифрування - алгоритм Data Encryption Standard (DES) в режимі Cipher Block Chaining (CBC).<br /> <br /> Запроваджуються й інші поняття, що використовуються для реалізації цієї моделі. Проте тут вони докладно не розглядаються, так само як і деталі функціонування моделі. Зазначимо лише, що при використанні відповідних протоколів аутентифікації і шифрування модель успішно справляється з описаними вище загрозами безпеці SNMP. Дана модель безпеки не була широко прийнята, оскільки є занадто складною і заплутаною.<br /> <br /> Модель безпеки на основі користувачів (User-based Security Model) вводить поняття користувача, від імені якого діє сутність SNMP. Цей користувач характеризується ім'ям користувача, використовуваними протоколами аутентифікації і шифрування, а також закритим ключем аутентифікації і шифрування. Аутентифікація і шифрування є необов'язковими. Їх наявність описується одним з параметрів моделі, якістю обслуговування (Quality of Service, QoS). Модель безпеки багато в чому схожа на модель сторін, але вона спрощує ідентифікацію користувачів, розподіл ключів і протокольні операції.<br /> <br /> ==Версії SNMP==<br /> <br /> Коротко опишемо відмінності між версіями SNMP і документи, що визначають ці версії. Зауважимо, що тут наведено перші версії RFC кожної з версій SNMP, тобто майже всі з них були заміщені новішими RFC і визнані застарілими. На даний момент єдиною не застарілою версією SNMP є SNMPv3, визначена в RFC 3411-3418.<br /> <br /> ===SNMPv1===<br /> Перші RFC, що описують стандарти SNMP, з'явилися в 1988 році. Версія 1 піддалася критиці за її слабку модель безпеки на основі спільнот. У той час безпека в Інтернеті не входила в коло першочергових завдань робочих груп IETF.<br /> <br /> 1. Обробка повідомлень<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]. A Simple Network Management Protocol;<br /> <br /> 2. Обробка PDU<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]. A Simple Network Management Protocol;<br /> <br /> 3. Інформаційна модель<br /> <br /> *Структура керуючої інформації<br /> [http://tools.ietf.org/html/rfc1065 RFC 1065]. Structure and Identification of Management Information for TCP / IP-based internets<br /> <br /> 4. Модулі MIB<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]. Management Information Base for Network Management of TCP / IP-based internets<br /> <br /> ===SNMPv2===<br /> <br /> Версія 2, відома, як Party-based SNMPv2, або SNMPv2p, не отримала широкого розповсюдження через серйозні розбіжності з приводу інфраструктури безпеки в стандарті.<br /> <br /> SNMPv2 поліпшував версію 1 в області швидкодії, безпеки, конфіденційності і взаємодій «менеджер-менеждер». Він представив новий тип PDU Get-Bulk-Request, альтернативу Get-Next-Request для отримання великих обсягів інформації за допомогою одного запиту. Проте, нова система безпеки на основі сторін виглядала для багатьох як надто складна і не була широко визнана.<br /> <br /> 1. Загальна інформація<br /> <br /> *[http://tools.ietf.org/html/rfc1441 RFC 1441]. Introduction to version 2 of the Internet-standard Network Management Framework<br /> <br /> *[http://tools.ietf.org/html/rfc1452 RFC 1452]. Coexistence between version 1 and version 2 of the Internet-standard Network <br /> Management Framework<br /> <br /> 2. Обробка повідомлень<br /> <br /> *Прив'язки до транспорту. [http://tools.ietf.org/html/rfc1448 RFC 1448]. Transport Mappings for SNMPv2<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc1446 RFC 1446]. Security Protocols for SNMPv2<br /> <br /> 3. Обробка PDU<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc1445 RFC 1445]. Administrative Model for SNMPv2<br /> <br /> *Протокольні операції. [http://tools.ietf.org/html/rfc1448 RFC 1448]. Protocol Operations for SNMPv2<br /> <br /> 4. Інформаційна модель<br /> <br /> *Структура керуючої інформації. [http://tools.ietf.org/html/rfc1442 RFC 1442]. Structure of Management Information SNMPv2<br /> <br /> *Текстові конвенції. [http://tools.ietf.org/html/rfc1443 RFC 1443]. Textual Conventions for SNMPv2<br /> <br /> *Вирази відповідності. [http://tools.ietf.org/html/rfc1444 RFC 1444]. Conformance Statements for SNMPv2<br /> <br /> 5. Модулі MIB<br /> <br /> *[http://tools.ietf.org/html/rfc1447 RFC 1447]. Party MIB for SNMPv2<br /> <br /> *[http://tools.ietf.org/html/rfc1450 RFC 1450]. MIB for SNMPv2<br /> <br /> *[http://tools.ietf.org/html/rfc1451 RFC 1451]. Manager-to-Manager MIB<br /> <br /> ===SNMPv2c===<br /> <br /> Community-based SNMPv2, або SNMPv2c, представив SNMPv2 без нової моделі безпеки версії 2. Замість неї пропонувалося використовувати стару модель безпеки версії 1 на основі спільнот. Відповідну пропозицію RFC було прийнято тільки як чернетку стандарту, однак стало де факто стандартом SNMPv2. Безпека SNMP знову опинилася невирішеним питанням.<br /> <br /> 1. Обробка повідомлень<br /> *Безпека. [http://tools.ietf.org/html/rfc1901 RFC 1901]. Introduction to Community-based SNMPv2<br /> <br /> ===SNMPv2u===<br /> <br /> User-based SNMPv2, або SNMPv2u, є компромісом між незахищеністю SNMPv1 і надмірною складністю SNMPv2p. Запропонована модель безпеки на основі користувачів була покладена в основу SNMPv3.<br /> <br /> 1. Обробка повідомлень<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc1909 RFC 1909] - An Administrative Infrastructure for SNMPv2 [http://tools.ietf.org/html/rfc1910 RFC 1910] - User-based Security Model for SNMPv2<br /> <br /> 2. Обробка PDU<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc1909 RFC 1909]. An Administrative Infrastructure for SNMPv2<br /> <br /> ===SNMPv3===<br /> <br /> SNMPv3 нарешті вирішив проблеми з безпекою способом, який багато хто вважав прийнятним. Версія 3 SNMP прийнята IETF як стандарт Інтернету (IETF STD 62). Майже всі попередні RFC визнані застарілими.<br /> <br /> 1. Загальна інформація<br /> *[http://tools.ietf.org/html/rfc3411 RFC 3411]. An Architecture for Describing SNMP Management Frameworks<br /> <br /> 2. Обробка повідомлень<br /> <br /> *Прив'язки до транспорту. [http://tools.ietf.org/html/rfc3417 RFC 3417]. Transport Mappings for the SNMP<br /> <br /> *Розбір і диспетчеризація повідомлень. [http://tools.ietf.org/html/rfc3412 RFC 3412]. Message Processing and Dispatching for the SNMP<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc3414 RFC 3414]. User-based Security Model (USM) for SNMPv3<br /> <br /> 3. Обробка PDU<br /> <br /> *Операції протоколу. [http://tools.ietf.org/html/rfc3416 RFC 3416]. Version 2 of the Protocol Operations for SNMP<br /> <br /> *Програми SNMP. [http://tools.ietf.org/html/rfc3413 RFC 3413]. SNMP Applications<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc3415 RFC 3415]. View-based Access Control Model (VACM) for the SNMP<br /> <br /> 4. Модулі MIB. [http://tools.ietf.org/html/rfc3418 RFC 3418]. MIB for the SNMP<br /> <br /> ==Існуючі реалізації==<br /> <br /> Підтримка SNMP - у багатьох значущих системах управління мережами, зокрема:<br /> <br /> *HP Network Node Manager;<br /> <br /> *IBM Tivoli NetView;<br /> <br /> *OpenNMS<br /> <br /> ===Недоліки SNMP===<br /> <br /> Протокол SNMP служить основою багатьох систем управління, хоча має кілька принципових недоліків, які перераховані нижче:<br /> <br /> *Відсутність засобів взаємної аутентифікації агентів і менеджерів. Єдиним засобом, який можна було б віднести до засобів аутентифікації, є використання в повідомленнях так званого рядка «community string». Цей рядок передається по мережі у відкритій формі в повідомленні SNMP і служить основою для поділу агентів і менеджерів на «спільноти», так що агент взаємодіє тільки з тими менеджерами, які вказують в поле community string такий же символьний рядок, що й рядок, який зберігається в пам'яті агента. Це, безумовно, не спосіб аутентифікації, а спосіб структурування агентів і менеджерів. Версія SNMP v.2 повинна була ліквідувати цей недолік, але в результаті розбіжностей між розробниками стандарту нові засоби аутентифікації хоча і з'явилися в цій версії, але як необов'язкові.<br /> <br /> *Робота через ненадійний протокол UDP (а саме так працює переважна більшість реалізації агентів SNMP) призводить до втрат аварійних повідомлень (повідомлень trap) від агентів до менеджерів, що може призвести до неякісного управління. <br /> <br /> ==Висновки==<br /> <br /> *SNMP широко використовується для управління мережами, особливо IP-мережами<br /> <br /> *Успіх SNMP в порівнянні з іншими стандартами управління показує переваги процесу стандартизації IETF<br /> <br /> *Історія розвитку SNMP показує важливість завдань захисту інформації<br /> <br /> *Архітектура SNMP цікава для аналізу архітектури мережевого програмного забезпечення; вона відповідає поставленим перед SNMP цілям<br /> <br /> *Архітектура SNMP відповідає архітектурному стилю ULCSS мережевого програмного забезпечення<br /> <br /> *У SNMP для вирішення функцій 6 рівня моделі OSI RM використовується [[ASN.1]], що незвично для стандартів IETF і позитивно впливає на питання формалізації протоколів, однозначності стандартів, зручності проектування додатків<br /> <br /> *Структура стандартів SNMP добре продумана і показова для вивчення стандартів<br /> <br /> *Лише деякі моделі безпеки SNMP відповідають поставленим перед системою безпеки SNMP цілям<br /> <br /> *Агенти та менеджери SNMP прості в програмній реалізації, проте завжди потрібно пам'ятати про інформаційну безпеку<br /> <br /> <br /> <br /> <br /> [[Засоби моніторингу та аналізу мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/ASN.1 2011-12-18T20:47:08Z

<p>Aleksey: Створена сторінка: ==Загальна інформація== Однією з найбільш складних систем сьогодні є відкриті системи зв'...</p> <hr /> <div>==Загальна інформація==<br /> <br /> Однією з найбільш складних систем сьогодні є відкриті системи зв'язку OSI (Open System Interconnection). OSI являє собою досить формалізовану стандартну архітектуру управління межкомпьютерними комунікаціями. Для опису цієї системи був розроблений абстрактний синтаксис нотацій ASN.1 (Abstract Syntax Notation; cм. A Layman's Guide to a Subset of ASN.1, BER, and DER. Burton S. Kaliski Jr., RSA Data Security, Inc. Redwood City , CA, 1991). ASN.1 є формальною мовою, яка володіє двома основними рисами.<br /> <br /> ASN.1 являє собою мову опису типів даних та їх значень. У загальному вигляді такий опис має вигляд:<br /> <br /> data type value name | data type identifier:: = data value або {data type identifier (data value)}<br /> <br /> Комі того, ASN.1 є мовою програмування. Ця мова служить для опису MIB і може використовуватися для модифікації існуючої або створення нової бази даних [[MIB]] для [[SNMP]]. Список найбільш поширених ключових слів ASN.1 для опису [[MIB]] [[SNMP]] включає в себе: BEGIN, IDENTIFIER, END, OCTETS, STRING, SEQUENCE, INTEGER, STRING, OBJECT, OF, NULL, DEFINITIONS DESCRIPTION.<br /> <br /> ==Макроси OBJECT-TYPE==<br /> <br /> Об'єкти [[MIB]] створюються макросами ASN.1. Макрос OBJECT-TYPE має формат:<br /> <br /> data type value name OBJECT-TYPE<br /> <br /> SYNTAX data type identifier<br /> <br /> UNITS<br /> <br /> ACCESS<br /> <br /> STATUS<br /> <br /> DESCRIPTION<br /> <br /> REFERENCE<br /> <br /> INDEX<br /> <br /> DEFVAL<br /> <br /> ''::'' = {Data value}<br /> <br /> *SYNTAX - визначає тип даних (простий, структурований і т.д)<br /> <br /> *ACCESS - задає рівень доступу до об'єкта (read only, read &amp; write)<br /> <br /> *STATUS - визначає статус опису об'єкта (поточний, застарілий і пр.)<br /> <br /> *DESCRIPTION - описує роль або функцію керованого об'єкта і способи його застосування<br /> <br /> *REFERENCE - опціональний опис, характеризує наслідування об'єкта (вказує на батьківський об'єкт)<br /> <br /> *INDEX - працює у випадку, коли об'єкт містить список або таблицю і дозволяє вказати позицію в списку або таблиці<br /> <br /> *DEFVAL - опціонна характеристика, яка вказує значення об'єкта за замовчуванням<br /> <br /> Використовувана в документах нотація легко читається і зрозуміла, а в компактному кодовому поданні інформація може використовуватися комунікаційними протоколами. Невід'ємною частиною ASN.1 є базові правила кодування BER (Basic Encoding Rules), які дозволяють визначити велику різноманітність типів даних. BER описує те, як представити або закодувати будь-яку величину в рамках стандарту ASN.1. або всі величини тут представляються у вигляді послідовності 8-бітних октетів. Восьмий біт октету завжди вважається найстаршим. BER дозволяє закодувати величину більш ніж одним способом. Є також піднабір правил кодування DER (Distinguished Encoding Rules, описані в документі Х.509), які визначають однозначні способи кодування величин ASN.1.<br /> <br /> ==Базові правила позначень метасинтаксису ASN.1==<br /> <br /> Нижче наведено базові правила позначень метасинтаксису ASN.1.<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;'''''n'''''&lt;/td&gt;<br /> &lt;td&gt;(полужирний курсив) означає змінну&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;'''[]'''&lt;/td&gt;<br /> &lt;td&gt;(квадратні дужки, полужирним шрифтом) терм є опціональним&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;'''{}'''&lt;/td&gt;<br /> &lt;td&gt;(фігурні дужки, полужирним шрифтом) групування в родинні терми&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;'''|'''&lt;/td&gt;<br /> &lt;td&gt;(вертикальна риска, полужирним шрифтом) виділяє альтернативні значення&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;...&lt;/td&gt;<br /> &lt;td&gt;(три крапки, полужирним шрифтом) означає повторення&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;'''='''&lt;/td&gt;<br /> &lt;td&gt;(знак рівності, полужирним шрифтом) описує терм, як субтерм&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> ASN.1 має чотири різновиди типів: прості типи, що не мають компонент, структурні типи, що мають компоненти, помічені (tagged) типи, які виходять з інших типів, а також інші типи, які включають в себе типи CHOICE і ANY. Типами та значенням можуть присвоюватися імена за допомогою оператора (::=). Ці імена в подальшому можуть використовуватися для визначення інших типів і величин.<br /> <br /> Всі типи ASN.1 крім CHOICE і ANY мають мітки, які складаються з класу і невід'ємного коду мітки. Типи ASN.1 тотожні, якщо їх числові мітки збігаються. Існує чотири класи міток.<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;universal&lt;/td&gt;<br /> &lt;td&gt;для типів, значення яких є незмінним для всіх додатків. Ці типи визначені в документі Х.208.&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;application&lt;/td&gt;<br /> &lt;td&gt;для типів зі значенням, специфічним для додатків, таких як служба каталогів Х.500. Типи двох різних програм можуть мати одну і ту ж мітку і різні значення.&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;private&lt;/td&gt;<br /> &lt;td&gt;для типів, які є специфічними для даного підприємства.&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;content-specific&lt;/td&gt;<br /> &lt;td&gt;для типів зі значенням, специфічним для даного структурного типу.&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> ==Типи та їх мітки==<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Тип&lt;/td&gt;<br /> &lt;td&gt;Коментарій&lt;/td&gt;<br /> &lt;td&gt;Цифрова мітка (шістнадцяткова)&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;INTEGER&lt;/td&gt;<br /> &lt;td&gt;Будь-яке ціле число&lt;/td&gt;<br /> &lt;td&gt;02&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;BIT STRING&lt;/td&gt;<br /> &lt;td&gt;Будь-який рядок біт&lt;/td&gt;<br /> &lt;td&gt;03&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;OCTET STRING&lt;/td&gt;<br /> &lt;td&gt;Будь-яка послідовність октетів&lt;/td&gt;<br /> &lt;td&gt;04&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;NULL&lt;/td&gt;<br /> &lt;td&gt; 0&lt;/td&gt;<br /> &lt;td&gt;05&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;OBJECT IDENTIFIER&lt;/td&gt;<br /> &lt;td&gt;Послідовність цілих компонент, що ідентифікують об'єкт&lt;/td&gt;<br /> &lt;td&gt;06&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;SEQUENCE and SEQUENCE OF&lt;/td&gt;<br /> &lt;td&gt;&lt;/td&gt;<br /> &lt;td&gt;10&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;SET and SET OF&lt;/td&gt;<br /> &lt;td&gt;&lt;/td&gt;<br /> &lt;td&gt;11&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;PrintableString&lt;/td&gt;<br /> &lt;td&gt;Последовательность печатных символов&lt;/td&gt;<br /> &lt;td&gt;13&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;IA5String&lt;/td&gt;<br /> &lt;td&gt;Произвольная строка символов IA5 (ASCII)&lt;/td&gt;<br /> &lt;td&gt;16&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;UTCTime&lt;/td&gt;<br /> &lt;td&gt;Універсальний час(по Гринвічу; GMT)&lt;/td&gt;<br /> &lt;td&gt;17&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> ASN.1 типи і значення виражаються в нотації, близької до тої що використовується в мовах програмування. Множинні пробіли і розриви рядків розглядаються як один пропуск. Коментарі виділяються парами дефісів або парою дефісів і переведенням рядка. Ідентифікатори (імена значень і полів) і імена типів складаються з літер, цифр та пробілів. Ідентифікатори починаються з малої літери, а імена типів - з великої.<br /> <br /> У SMI (Structure of Management Information) не використовується повний набір типів об'єктів, передбачений в ASN.1, дозволені тільки такі типи примітивів: INTEGER, OCTET STRING, OBJECT IDENTIFIER і NULL.<br /> <br /> Стандарт ASN.1 визначає форму подання інформації та імен. Для малих типів може бути введено обмеження на максимальний розмір. В ASN.1 визначено чотири структуровані типи.<br /> <br /> ==Структуровані типи рядків==<br /> <br /> *SEQUENCE - упорядкований набір з одного або більше типів.<br /> <br /> *SEQUENCE OF - упорядкований набір з нуля або більше представників даного типу.<br /> <br /> *SET - невпорядкований набір з одного або більше типів.<br /> <br /> *SET OF - невпорядкований набір з нуля або більше представників даного типу.<br /> <br /> Структуровані типи можуть мати опціонні компоненти, в тому числі зі значеннями за замовчуванням.<br /> <br /> Існують типи помічені явно і неявно. Неявно помічені типи виходять з інших типів шляхом зміни мітки. Для неявної позначки використовується ключове слово IMPLICIT. Явно помічені типи виходять з інших типів шляхом додавання зовнішньої мітки. Позначений явно тип - це структурований тип, що складається з одного компонента основного типу. Для явної позначки використовується ключове слово EXPLICIT. Позначка (тегування) дуже зручна для відмінності типів в межах однієї програми.<br /> <br /> Тип CHOICE позначає об'єднання одного або більше альтернатив. Тип ANY служить для позначення довільної величини для довільного типу.<br /> <br /> ==Правила BER==<br /> <br /> Правила BER визначають один або більше способів представити будь-яку величину у вигляді рядка октетів. Існує три методи кодування величин (в рамках BER): примітивний з відомою довжиною; конструктивний при відомій довжині і конструктивний при невідомій довжині. Вибір методу залежить від типу величини і від того, чи відома довжина перетворюваної величини. Для простих не рядкових типів використовується примітивний метод кодування. У кожному методі BER-кодування має три або чотири частини:<br /> <br /> *Identifier octets - визначає клас і числову позначку значення, а також вказує, чи є метод примітивним або конструктивним.<br /> <br /> *Length octets - для методів кодування з відомою довжиною визначає число октетів вмісту.<br /> <br /> *Contents octets - для примітивних методів із заданою довжиною дає конкретний вираз значення.<br /> <br /> *End-of-contents octets - Для конструктивних методів з невизначеною довжиною вказує на кінець вмісту.<br /> <br /> '''Примітивний метод кодування із заданою довжиною'''<br /> <br /> Цей метод можна застосовувати для простих типів і типів отриманих з простих типів шляхом неявного позначення. Тут необхідно, щоб довжина величини була відома заздалегідь. Октети ідентифікатора мають два формати: для числових міток від 0 до 31, і для числових міток більше 31. У першому випадку біти 7 і 8 визначають клас, біт 6 дорівнює нулю, вказуючи на те, що метод кодування primitive. Решта бітів використовуються для запису коду числової мітки. У другому випадку використовується два або більше октетів. У першому октеті кодування аналогічне першому варіанту за винятком того, що біти 1-5 містять одиниці.<br /> <br /> '''Коди класів''':<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Клас&lt;/td&gt;<br /> &lt;td&gt;Біт 8&lt;/td&gt;<br /> &lt;td&gt;Біт 7&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Універсальний&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Прикладний&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Контекстно-орієнтований&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Приватний&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> Для октетів довжини примітивного методу є два формати: короткий (один октет для довжин 0-127) і довгий (2-127 октетів). Для короткої форми восьмий біт октету завжди дорівнює нулю. Для довгої форми восьмий біт першого октету завжди дорівнює 1, біти 1-7 містять код числа додаткових октетів довжини. Старша цифра записується першою.<br /> <br /> '''Конструктивний метод із заданою довжиною'''<br /> <br /> Цей метод використовується для простих малих і структурованих типів, типів, похідних від простих рядкових типів, та деяких інших. Тут октети ідентифікатора і октети довжини мають формат, ідентичний використовуваному примітивним методом, за винятком того, що біт 6 першого октету ідентифікатора дорівнює 1.<br /> <br /> '''Конструктивний метод кодування з незаданою довжиною'''<br /> <br /> Метод використовується для простих рядкових типів, структурованих типів і типів, отриманих із простих і структурованих типів за допомогою неявного позначення. Октети ідентифікатора ідентичні попереднім. Октет довжини містить код 80. Два октету кінця змістовної частини містять 00 00.<br /> <br /> Нотація типів, позначених неявно, має вигляд:<br /> <br /> ['''['''Class''']''' number] IMPLICIT Type<br /> <br /> class = UNIVERSAL | APPLICATION | PRIVITE<br /> <br /> де Type - тип, class - опціональне ім'я класу і number - цифрова мітка (невід'ємне ціле число).<br /> <br /> Якщо ім'я класу відсутнє, тоді мітка є контекстно-орієнтованою. Такі мітки можуть з'являтися тільки в структурних компонентах або в типі CHOICE. Наприклад:<br /> <br /> PrivateKeyInfo:: = {SEQUENCE<br /> version Version,<br /> privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,<br /> privateKey PrivateKey,<br /> attributes [0] IMPLICIT Attributes OPTIONAL}<br /> <br /> Тут вихідним (що породжує) типом є Attributes, клас відсутній (тобто контекстно-орієнтований), а числова мітка дорівнює нулю. Кодування компоненти attributes величини PrivateKeyInfo здійснюється наступним чином.<br /> <br /> Октети ідентифікатора рівні 80, якщо значення величини Attributes має конструктивне BER-кодування. Октети довжини та вмісту строго відповідають октетам величини Attributes.<br /> <br /> Безпосередня (явна) позначка використовується для опціональних компонент SEQUENCE c породжуючим типом ANY і для компонент version типу Certificate (X.509 і RFC-1114). Нотація типів, позначених явно, має формат:<br /> <br /> [[Class] number] EXPLICIT Type<br /> <br /> class = UNIVERSAL | APPLICATION | PRIVATE<br /> <br /> де Type - тип, class - опціоне ім'я класу, а number - числова мітка в межах класу (невід'ємне ціле число). Приклад:<br /> <br /> ContentInfo:: = {SEQUENCE<br /> ContebtType ContentType,<br /> Content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL}<br /> <br /> Тип ContentInfo має опціональну компоненту content з явною контекстно-орієнтованою міткою. <br /> <br /> Іншим прикладом може бути тип Certificate [X.509], що має компоненту з явною контекстно-орієнтованою міткою (ключове слово EXPLICIT опущено).<br /> <br /> Certificate:: = ...<br /> Version [0] Version DEFAULT v1988,<br /> ...<br /> <br /> BER-кодування величин, позначених явно, є завжди конструктивним. Октети вмісту ідентичні відповідним октетам породжуючої величини. <br /> <br /> '''Тип ANY'''<br /> <br /> Тип ANY позначає довільну величину довільного типу, де довільний тип можливо визначений при реєстрації ідентифікатора об'єкта або є цілочисельним індексом. Нотація типу ANY має формат:<br /> <br /> ANY ''[''DEINED BY identifier]<br /> <br /> де identifier - опціонний ідентифікатор. Форма ANY DEINED BY identifier може з'явитися тільки в компоненті типу SEQUNCE або SET, для якої identifier визначає якусь іншу компоненту і ця компонента має тип INTEGER або OBJECT IDENTIFIER. У цій формі істинний тип задається величиною цієї іншої частини. Наприклад, тип AlgorithmIdentifier [X.509] має компоненту типу ANY:<br /> <br /> AlgorithmIdentifier:: = {SEQUENCE<br /> algorithm OBJECT IDENTIFIER,<br /> parameter ANY DEFINED BY algorithm OPTIONAL}<br /> <br /> Тут справжній тип компоненти parameter залежить від величини компоненти algorithm. Істинний тип буде визначений при реєстрації об'єкта величини ідентифікатора для компоненти algorithm.<br /> <br /> '''Бітові рядки'''<br /> <br /> Тип BIT STRING позначає довільні бітові послідовності довільної довжини (включаючи нуль). Тип BIT STRING використовується для цифрових сигнатур типу ExtendedCertificate або Certificate [X.509]. <br /> <br /> Наприклад, тип SubjectPublicKeyInfo має компоненту типу BIT STRING:<br /> <br /> SubjectPublicKeyInfo:: = {SEQUENCE<br /> Algorithm AlgorithmIdentifier,<br /> PublicKey BIT STRING}<br /> <br /> BER-кодування величини BIT STRING може бути примітивним або конструктивним. При примітивному кодуванні перший октет має в собі довжину бітової рядки в октетах. У наступних октетах записується сама бітова послідовність. Процедура кодування може включати в себе додаток бітового рядка до цілого числа октетів нулями (якщо це необхідно). Рядок ділиться на октети.<br /> <br /> При конструктивному кодуванні октети вмісту представляють собою з'єднання послідовності субрядків, тільки остання з яких містить код довжини, виражений в октетах. Наприклад, при BER-кодуванні значення BIT STRING &quot;0111 1101 1001 1111 11&quot; може бути представлене ​​в одному з наступних видів, залежно від вибору схеми додатку до цілого числа октетів, від формату октетів довжини і від методу кодування примітивний / конструктивний).<br /> <br /> '''Тип CHOICE'''<br /> <br /> Цей тип служить для об'єднання однієї або більше альтернатив. Нотація типу CHOICE має формат.<br /> <br /> CHOICE {<br /> ''[''Identifier1'']'' Type1,<br /> ...,<br /> ''[''IdentifierN'']'' Typen}<br /> <br /> де identifier1, ..., identifierN є опціональним ідентифікаторами альтернатив, а типи Type1, ..., TypeN - альтернативи. Ідентифікатори потрібні для документування і не грають якоїсь ролі при кодуванні. Типи повинні мати певні позначки. Розглянемо приклад типу ExtendedCertificateOrCertificate, який відноситься до типу CHOICE.<br /> <br /> ExtendedCertificateOrCertificate:: = {CHOICE<br /> certificate Certificate, - X.509 certificate<br /> extendedCertificate ''[''0'']'' IMPLICIT ExtendedCertificate}<br /> <br /> Тут ідентифікаторами для альтернатив є certificate і extendedCertificate, а самі альтернативи представлені типами Certificate і ''[''0'']'' IMPLICIT ExtendedCertificate. BER-кодування для типу CHOICE зводиться до кодування альтернатив. При цьому октети ідентифікатора для розглянутого прикладу містять код 30, якщо вибрана альтернатива certificate, і A0 - у разі ExtendedCertificate.<br /> <br /> '''Рядки IA5'''<br /> <br /> Тип IA5String представляє будь послідовності IA5-символів (міжнародний алфавіт 5 - еквівалентно ASCII). Довжина рядка може бути будь-хто, включаючи нуль. Цей тип використовується для адрес електронної пошти та неструктурованих імен.<br /> <br /> BER-кодування величини IA5String може бути примітивним або структурованим. При примітивному кодуванні октети вмісту являють собою символи IA5 в ASCII-кодів. При конструктивному кодуванні октети вмісту представляють собою з'єднання ряду IA5-субрядків. <br /> <br /> ==DER-кодування==<br /> <br /> DER-кодування є завжди примітивним, октети вмісту ідентичні випадку BER-кодування.<br /> <br /> '''Тип INTEGER'''<br /> <br /> Тип INTEGER представляє будь-які цілі числа (позитивні, негативні або 0). Тип INTEGER використовується для номерів версій, криптографічних параметрів (показників, модулів) і типів RSAPublicKey, RSAPrivatKey, DHParameter PBEParameter. Нотація типу INTEGER має формат:<br /> <br /> INTEGER '''['''{identifier1 (value1) ... identifiern (valuen)}''']'''<br /> <br /> де identifier1 ... identifierN є опціональними ідентифікаторами, а value1 ... valueN - jgwsjyfkmys цілі значення. Наприклад, Version RFC-1114 відноситься до цілого типу зі значенням:<br /> <br /> Version:: = INTEGER {1988 (0)}<br /> <br /> Ідентифікатору v1988 поставлено у відповідність значення 0. Тип Certificate RFC-1114 використовує ідентифікатор v1988 для присвоєння значення за замовчуванням компоненту version:<br /> <br /> Certificate<br /> version Version DEFAULT v1988,<br /> ...<br /> <br /> BER-кодування значення INTEGER є завжди примітивним. Октети вмісту представляють значення цілого по модулю 256 в формі доповнення за модулем 2. Старша цифра є першою. Значення нуль кодується одним октетом 00. Приклади BER-кодування (збігається в даному випадку з DER-кодуванням) представлені в таблиці:<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Значення цілого&lt;/td&gt;<br /> &lt;td&gt;BER-код&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;02 01 00&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;127&lt;/td&gt;<br /> &lt;td&gt;02 02 00 7F&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;128&lt;/td&gt;<br /> &lt;td&gt;02 02 00 80&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;256&lt;/td&gt;<br /> &lt;td&gt;02 02 01 00&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;-128&lt;/td&gt;<br /> &lt;td&gt;02 01 80&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;-129&lt;/td&gt;<br /> &lt;td&gt;02 02 FF 7F&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> '''NULL'''<br /> <br /> Тип NULL позначає нульову величину.<br /> <br /> Кодування для типу NULL є завжди примітивним, октети вмісту порожні. Наприклад, BER-представлення значення NULL може мати одну з наведених нижче форм (залежить від використовуваного представлення октетів довжини.<br /> <br /> 05 00<br /> 05 81 00<br /> <br /> DER-кодування типу NULL є також примітивним і збігається з першим рядком наведеного вище прикладу.<br /> <br /> ==Об'єктні ідентифікатори==<br /> <br /> Тип OBJECT IDENTIFIER служить для позначення ідентіфікаторов, які представляють собою послідовність цілочисельних компонент, які ідентифікують такі об'єкти, як алгоритм або атрибут імені каталогу. Значення OBJECT IDENTIFIER може містити будь-яке число невід'ємних компонентів. Значення OBJECT IDENTIFIER присвоюються при реєстрації.<br /> <br /> Тип OBJECT IDENTIFIER використовується для ідентифікації вмісту ContentInfo, алгоритмів в X.509 (AlgorithmIdentifier) і атрибутів Attribute і AttributeValueAssertion (X.501).<br /> <br /> Нотація величини OBJECT IDENTIFIER має вигляд:<br /> <br /> {'''['''Identifier''']''' component1 ... componentN}<br /> componenti = identifieri | identifieri (valuei) | valuei<br /> <br /> де identifier, identifier1, ... identifierN є ідентифікаторами, а value1 ..., valueN - опціональні цілі числа. Ідентифікатори без цілих значень можуть зустрітися тільки для об'єктів, описаних в Х.208.<br /> <br /> Наприклад, наведені нижче величини об'єктних ідентифікаторів присвоєні RSA DATA Security, Inc.<br /> <br /> {Iso (1) member-body (2) 840 113 549}<br /> {1 2 840 113549}<br /> <br /> У наступній таблиці представлені деякі об'єктні ідентифікатори та їх значення:<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Величина об'єктного ідентифікатора&lt;/td&gt;<br /> &lt;td&gt;Призначення&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;{ 1 2 }&lt;/td&gt;<br /> &lt;td&gt;Члени ISO&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;{ 1 2 840 }&lt;/td&gt;<br /> &lt;td&gt;US (ANSI)&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;{ 1 2 840 113549}&lt;/td&gt;<br /> &lt;td&gt;RSA Data Security, Inc.&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;{ 1 2 840 113549 }&lt;/td&gt;<br /> &lt;td&gt;RSA Data Security, Inc. PKCS (Public Key Cryptography Standard)&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;{ 2 5 }&lt;/td&gt;<br /> &lt;td&gt;Служба каталогів (X.500)&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;{ 2 5 8 }&lt;/td&gt;<br /> &lt;td&gt;Служба каталогів - алгоритми&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> BER-кодування OBJECT IDENTIFIER є завжди примітивним. Октети вмісту представляють собою об'єднання n-1 рядка октетів, де n число компонент об'єктного ідентифікатора. Кожни октетний рядок несе в собі ціле число по модулю 128 (старша частина перша). Восьмий біт кожного октету, крім останнього, дорівнює 1. Нехай value1, ..., valueN цілі значення компонентів об'єктного ідентифікатора. Тоді n-1 субідентіфікаторов, з яких формується октетное рядок, будуть мати наступний вигляд:<br /> <br /> 1. Перший субідентіфікатор дорівнює 40value1 + value2. (Значення value1 лежить в межах 0-2 включно, а value2 в інтервалі 0-39, коли value1 дорівнює 0 або 1.<br /> <br /> 2. i-ий субідентіфікатор дорівнює value(i+1); де i - належить проміжку від 2 до n-1.<br /> <br /> Наприклад, субідентіфікатори об'єктного ідентифікатора RSA Data Security, Inc. дорівнюють 42 = 40x1 + 2, 840, 113 549 і 1. У шістнадцятковому представленні BER-код цього об'єктного ідентифікатора має вигляд:<br /> <br /> 06 07 2A 86 48 86 F7 0D 01<br /> <br /> DER-кодування в даному випадку співпадає з BER.<br /> <br /> '''Рядки октетів'''<br /> <br /> Тип OCTET STRING служить для представлення довільних послідовностей октетів. Значення OCTET STRING може мати будь-яку довжину, включаючи нуль. OCTET STRING використовується для подання повідомлень, включаючи зашифровані, а також для типу PBEParameter. Нотація типу OCTET STRING має формат.<br /> <br /> OCTET STRING '''['''SIZE ({size | size1 .. size2})''']'''<br /> <br /> де size, size1 і size2 опціональні обмеження розміру. У формі OCTET STRING SIZE (size) рядок октетів повинен мати октети size. У форматі OCTET STRING SIZE (size1 .. size2) рядок повинен містити число октетів між size1 і size2. Наприклад, тип PBEParameter має компоненту типу OCTET STRING:<br /> <br /> PBEParameter:: = {SEQUENCE<br /> salt OCTET STRING SIZE (8),<br /> iterationCount INTEGER}<br /> <br /> Тут розмір компоненти salt завжди дорівнює 8 октетам. BER-кодування типу OCTET STRING може бути примітивним або конструктивним. При примітивному кодуванні октети вмісту несуть в собі октети рядки з першого по останній. При конструктивному кодуванні вміст октетів являє собою послідовне об'єднання субрядків значення OCTET STRING.</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%97%D0%B0%D1%81%D0%BE%D0%B1%D0%B8_%D0%BC%D0%BE%D0%BD%D1%96%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3%D1%83_%D1%82%D0%B0_%D0%B0%D0%BD%D0%B0%D0%BB%D1%96%D0%B7%D1%83_%D0%BC%D0%B5%D1%80%D0%B5%D0%B6%D1%96 2011-12-18T15:05:48Z

<p>Aleksey: </p> <hr /> <div>== Класифікація засобів моніторингу та аналізу ==<br /> <br /> Всі засоби моніторингу та аналізу мереж, можна розділити на кілька великих класів:<br /> <br /> *''Системи управління мережею'' ([http://en.wikipedia.org/wiki/Network_management_system Network Management Systems]) - централізовані програмні системи, які збирають дані про стан вузлів і комунікаційних пристроїв мережі, а також дані про трафік в мережі. Ці системи не тільки здійснюють моніторинг і аналіз, а й виконують в автоматичному чи напівавтоматичному режимі управління мережею - включення і відключення портів пристроїв, зміна параметрів мостів адресних таблиць мостів, комутаторів і маршрутизаторів і т.п. Прикладами систем управління можуть служити популярні системи HPOpenView, SunNetManager, IBMNetView.<br /> <br /> *''Засоби управління системою'' ([http://uk.wikipedia.org/wiki/%D0%92%D0%B1%D1%83%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B0_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0#.D0.90.D1.80.D1.85.D1.96.D1.82.D0.B5.D0.BA.D1.82.D1.83.D1.80.D0.B8_.D0.BF.D1.80.D0.BE.D0.B3.D1.80.D0.B0.D0.BC.D0.BD.D0.BE.D0.B3.D0.BE_.D0.B7.D0.B0.D0.B1.D0.B5.D0.B7.D0.BF.D0.B5.D1.87.D0.B5.D0.BD.D0.BD.D1.8F_.D0.B2.D0.B1.D1.83.D0.B4.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.85_.D1.81.D0.B8.D1.81.D1.82.D0.B5.D0.BC System Management]). Засоби управління системою часто виконують функції, аналогічні функціям систем управління, але стосовно інших об'єктів. У першому випадку об'єктом управління є програмне і апаратне забезпечення комп'ютерів мережі, а у другому - комунікаційне устаткування. Разом з тим, деякі функції цих двох видів систем управління можуть дублюватися, наприклад, засоби управління системою можуть виконувати найпростіший аналіз мережевого трафіку.До найбільш відомих систем управління системами відносяться LANDesk, IBM Tivoli, Microsoft Systems Management Server, HP OpenView, Novell ZENworks і CA Unicenter.<br /> <br /> *''Вбудовані системи діагностики і управління'' ([http://en.wikipedia.org/wiki/Embedded_system Embedded Systems]). Ці системи виконуються у вигляді програмно-апаратних модулів, які встановлюються в комунікаційне обладнання, а також у вигляді програмних модулів, вбудованих в операційні системи. Вони виконують функції діагностики і управління тільки одним пристроєм, і в цьому їх основна відмінність від централізованих систем управління. Прикладом засобів цього класу може служити модуль управління концентратором Distrebuted 5000, реалізує функції автосигментацієї портів при виявленні несправностей, приписування портів внутрішнім сегментам концентратора і деякі інші. Як правило, вбудовані модулі управління також виконують роль SNMP-агентів, які поставляють дані про стан пристрою системам управління. <br /> <br /> *''Аналізатори протоколів'' (Protocolanalyzers). Представляють собою програмні або апаратно-програмні системи, які обмежуються на відміну від систем управління лише функціями моніторингу і аналізу трафіку в мережах. Хороший аналізатор протоколів може захоплювати і декодувати пакети великої кількості протоколів, що застосовуються в мережах - зазвичай кілька десятків. Аналізатори протоколів дозволяють встановити деякі логічні умови для захоплення окремих пакетів і виконують повне декодування захоплених пакетів, тобто показувати в зручній для користувача формі вкладеність пакетів протоколів різних рівнів один в одного з розшифруванням змісту окремих полів кожного пакета.<br /> <br /> *''Обладнання для діагностики і сертифікації кабельних систем''. Умовно це устаткування можна поділити на чотири основні групи: мережні монітори, прилади для сертифікації кабельних систем, кабельні сканери і тестери (мультиметри). Мережеві монітори (називають також мережевими аналізаторами) призначені для тестування кабелів різних категорій. Слід розрізняти мережеві монітори і аналізатори протоколів. Мережеві монітори збирають дані лише про статистичні показники трафіку - середньої інтенсивності загального трафіку мережі, середньої інтенсивності потоку пакетів з певним типом помилки і т.п. Призначення пристроїв для сертифікації кабельних систем, безпосередньо випливає з їх назви. Сертифікація виконується відповідно до вимог одного з міжнародних стандартів на кабельні системи. Кабельні сканери використовуються для діагностики мідних кабельних систем. Тестери призначені для перевірки кабелів на відсутність фізичного розриву.<br /> <br /> *''Експертні системи''. Цей вид систем акумулює людські знання про виявлення причин аномальної роботи мереж і можливі способи приведення мережі у працездатний стан. Експертні системи часто реалізуються у вигляді окремих підсистем різних засобів моніторингу та аналізу мереж: систем управління мережами, аналізаторів протоколів, мережевих аналізаторів. Найпростішим варіантом експертної системи є контекстно-залежна help-система. Більш складні експертні системи являють собою так звані бази знань, що володіють елементами штучного інтелекту. Прикладом такої системи є експертна система, вбудована в систему управління Spectrum компанії Cabletron. <br /> <br /> *''Багатофункціональні пристрої аналізу та діагностики''. У зв'язку з розповсюдженням локальних мереж виникла необхідність розробки недорогих портативних приладів, які суміщають функції декількох пристроїв: аналізаторів протоколів, кабельних сканерів і, навіть, деяких можливостей ПЗ мережного управління. Як приклад такого роду пристроїв можна привести Compas компанії MicrotestInc. або 675 LANMeterкомпаніі FlukeCorp.<br /> <br /> == Системи управління ==<br /> Відповідно до рекомендацій ISO можна виділити такі функцій '''засобів управління мережею''':<br /> <br /> * ''Управління конфігурацією мережі'' - полягає в конфігурації компонентів мережі, включаючи їх місце розташування, мережні адреси і ідентифікатори, управління параметрами мережевих операційних систем, підтримку схеми мережі: також ці функції використовуються для іменування об'єктів. <br /> <br /> * ''Обробка помилок'' - це виявлення і усунення наслідків збоїв у роботі мережі. <br /> <br /> * ''Аналіз продуктивності'' - допомагає на основі накопиченої статистичної інформації оцінювати час відповіді системи і величину трафіка, а також планувати розвиток мережі. <br /> <br /> * ''Управління безпекою'' - включає в себе контроль доступу та збереження цілісності даних. У функції входить процедура аутентифікації, перевірки привілеїв, підтримка ключів шифрування, управління правами. До цієї ж групи можна віднести важливі механізми управління паролями, зовнішнім доступом, з'єднання з іншими мережами. <br /> <br /> * ''Облік роботи мережі'' - включає реєстрацію і управління використовуваними ресурсами і пристроями. Ця функція оперує такими поняттями як час використання і плата за ресурси.<br /> <br /> З наведеного списку видно, що системи управління виконують не тільки функції моніторингу та аналізу роботи мережі, необхідні для отримання вихідних даних для налаштування мережі, але і включають функції активного впливу на мережу - управління конфігурацією і безпекою, які потрібні для відпрацювання виробленого плану настройки та оптимізації мережі. Сам етап створення плану налаштування мережі зазвичай залишається за межами функцій системи управління, хоча деякі системи управління мають у своєму складі експертні підсистеми, що допомагають адміністратору або интегратору визначити необхідні заходи з настроювання мережі. <br /> <br /> Засоби управління мережею (NetworkManagement), не слід плутати із засобами управління комп'ютерами та їх операційними системами (SystemManagement). Типовими представниками засобів управління мережами є системи HPOpenView, SunNetManager і IBMNetView.<br /> <br /> '''Засоби управління системою''' зазвичай виконують такі функції:<br /> <br /> *''Облік використовуваних апаратних і програмних засобів''. Система автоматично збирає інформацію про комп'ютери і створює записи в базі даних про апаратні і програмні ресурси. Після цього адміністратор може швидко з'ясувати, що він має і де це знаходиться. Наприклад, дізнатися про те, на яких комп'ютерах потрібно оновити драйвери принтерів, які ПК мають достатню кількість пам'яті і дискового простору і т. п. <br /> <br /> * ''Розподіл й встановлення програмного забезпечення''. Після завершення обстеження адміністратор може створити пакети розсилки програмного забезпечення, що являється дуже ефективним способом для зменшення вартості такої процедури. Система може також дозволяти централізовано встановлювати і адмініструвати програми, які запускаються з файлових серверів, а також дати можливість кінцевим користувачам запускати такі програми з будь-якої робочої станції мережі.<br /> <br /> * ''Віддалений аналіз продуктивності і виникаючих проблем''. Адміністратор може віддалено управляти ресурсами будь-якого ПК, що працює в мережі. База даних системи управління зберігає детальну інформацію про конфігурацію всіх комп'ютерів в мережі для того, щоб можна було виконувати віддалений аналіз виникаючих проблем.<br /> <br /> Прикладами засобів управління системою є такі продукти, як SystemManagementServer компанії Microsoft або LANDeskManager фірми Intel.<br /> <br /> Останнім часом в області систем управління спостерігаються дві досить чітко виражені тенденції: <br /> <br /> *інтеграція в одному продукті функцій управління мережами і системами;<br /> *розподіленість системи управління, при якій в системі існує кілька консолей, які збирають інформацію про стан пристроїв і систем та видають керуючі дії.<br /> <br /> ===Стандарти управління мережою===<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Організація&lt;/td&gt;<br /> &lt;td&gt;Стандарти&lt;/td&gt;<br /> &lt;td&gt;Особливості&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;IETF&lt;/td&gt;<br /> &lt;td&gt;SNMP&lt;/td&gt;<br /> &lt;td&gt;Управління має бути простим, орієнтоване на змінні&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;ISO&lt;/td&gt;<br /> &lt;td&gt;CMIP, CMIS&lt;/td&gt;<br /> &lt;td&gt;Управління має бути потужним, об'єктно-орієнтованим&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;ITU-T&lt;/td&gt;<br /> &lt;td&gt;TMN&lt;/td&gt;<br /> &lt;td&gt;Визначена тільки архітектура&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;DMTF&lt;/td&gt;<br /> &lt;td&gt;WBEM, CIM&lt;/td&gt;<br /> &lt;td&gt;Управління мережами і системами, об'єктно-орієнтоване&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;OMG&lt;/td&gt;<br /> &lt;td&gt;CORBA&lt;/td&gt;<br /> &lt;td&gt;Архітектура віддалених об'єктів&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> Нині найуспішнішим сімейством стандартів є [[SNMP]]. Він лідирує за кількістю керованих систем (агентів). Керуючі системи (менеджери) зазвичай підтримують безліч стандартів, тому тут складно говорити про лідерство SNMP. За кількістю вкладених грошей, можливо, лідирує Telecommunications Management Network (TMN).<br /> <br /> Показово простежити залежність популярності стандартів від середовища їх застосування. У локальних і глобальних мережах передачі даних, що використовують Протокол інтернету (Internet Protocol, IP) найбільш широко розповсюджений стандарт [[SNMP]]. У системах відомчих автоматичних телефонних станцій (ВАТС) та в публічних телефонних мережах найбільш часто використовуються пропрієтарні рішення. У мобільних мережах в основному використовуються рішення на основі стандартів ISO.<br /> <br /> Майже всі успіхи SNMP пов'язані з особливостями процесу стандартизації в IETF:<br /> <br /> *Стандарти безкоштовні і вільно розповсюджувані;<br /> <br /> *Стандарти легко доступні в електронній формі;<br /> <br /> *Швидкий розвиток стандартів, продумані етапи стандартизації;<br /> <br /> *На всіх етапах ведеться технічна експертиза;<br /> <br /> *Робочі групи очолюють технічні, а не політичні лідери;<br /> <br /> *Прототипи систем на основі стандартів демонструють їх придатність;<br /> <br /> ===Протокол [[SNMP]]===<br /> <br /> Створення систем управління мережами неможливе без орієнтації на певні стандарти, тому що управляюче програмне забезпечення та мережеве обладнання розробляють сотні компаній. Оскільки корпоративна мережа напевно неоднорідна, керуючі інструменти не можуть відображати специфіки однієї системи або мережі. <br /> Найбільш поширеним протоколом управління мережами є протокол [[SNMP]] (SimpleNetworkManagementProtocol), його підтримують сотні виробників. Головні переваги протоколу SNMP - простота, доступність, незалежність від виробників. Значною мірою саме популярність [[SNMP]] затримала прийняття CMIP, варіанта керуючого протоколу за версією OSI. Протокол SNMP розроблений для управління маршрутизаторами в мережі Internet і є частиною стека TCP/IP.<br /> <br /> У системах управління, побудованих на основі протоколу [[SNMP]], стандартизуються наступні елементи:<br /> <br /> *протокол взаємодії агента і менеджера;<br /> <br /> *мова опису моделей MIВ та повідомлень [[SNMP]] - мова абстрактної синтаксичної нотації [[ASN.1]] (стандарт ISO 8824:1987, рекомендації ITU-T X.208);<br /> <br /> *кілька конкретних моделей MIB (MIB-I, MIB-II, RMON, RMON 2), імена об'єктів яких реєструються в дереві стандартів ISO. Все інше віддається на розсуд розробника системи управління. Протокол SNMP і тісно пов'язана з ним концепція SNMP MIB були розроблені для управління маршрутизаторами Internet як тимчасове рішення. Але, як це часто буває з усім тимчасовим, простота і ефективність вирішення забезпечили успіх цього протоколу, і сьогодні він використовується при управлінні практично будь-якими видами обладнання і програмного забезпечення обчислювальних мереж. І хоча в області управління телекомунікаційними мережами спостерігається стійка тенденція застосування стандартів ITU-T, в які входить протокол CMIP, і тут є досить багато прикладів успішного використання SNMP-управління. Агенти SNMP вбудовуються в аналогові модеми, модеми ADSL, комутатори АТМ і т. д.<br /> <br /> SNMP - це протокол, що використовується для отримання від мережевих пристроїв інформації про їх статус, продуктивність та характеристики, які зберігаються в спеціальній базі даних мережевих пристроїв, що називається MIB (ManagementInformationBase). Існують стандарти, що визначають структуру MIB, в тому числі набір типів її змінних (об'єктів в термінології ISO), їх імена і допустимі операції цими змінними (наприклад, читати). У MIB, поряд з іншою інформацією, можуть зберігатися мережеві та / або MAC-адреси пристроїв, значення лічильників оброблених пакетів і помилок, номери, пріоритети та інформація про стан портів. Деревоподібна структура MIB містить обов'язкові (стандартні) піддерева, а також в ній можуть знаходитися приватні (private) піддерева, що дозволяють виробнику інтелектуальних пристроїв реалізувати будь-які специфічні функції на основі його специфічних змінних. <br /> <br /> Агент в протоколі SNMP - це елемент, який надає менеджерам, розміщеним на керуючих станціях мережі, доступ до значень змінних MIB, і тим самим дає їм можливість реалізовувати функції з управління та спостереження за пристроєм. Типова структура системи управління зображена на наступному малюнку:<br /> <br /> [[Файл:Locnop2211.gif]] <br /> <br /> ===Стандарти управління OSI===<br /> <br /> ====Загальні відомості. Концепція SMAE====<br /> <br /> Модель мережевого управління OSI - OSI Management Framework - визначена в документі ISO / IEC 7498-4: Basic Reference Model, Part 4, Management Framework.<br /> <br /> Документ ISO / IEC 7498-4 складається з наступних основних розділів:<br /> <br /> *Терміни та загальні концепції.<br /> <br /> *Модель управління системами.<br /> <br /> *Інформаційна модель.<br /> <br /> *Функціональні області управління системами.<br /> <br /> *Структура стандартів управління системами.<br /> <br /> Функціональні області управління системами вже були розглянуті вище.<br /> <br /> Стандарти ISO в галузі управління використовує термінологію, яка частково збігається з термінологією систем управління SNMP.<br /> <br /> Як показано на малюнку, обмін керуючою інформацією з використанням протоколу управління (Management Protocol) відбувається між суб'єктами програм управління системами (Systems Management Application Entities, SMAE):<br /> <br /> [[Файл:Smae.jpg]]<br /> <br /> Суб'єкти SMAE розташовані на прикладному рівні семирівневої моделі OSI і є елементами служби управління. Під суб'єктом в моделі OSI розуміється активний в даний момент елемент протоколу будь-якого рівня, який бере участь у взаємодії. Прикладами SMAE є агенти та менеджери систем управління.<br /> <br /> ====Агенти та менеджери====<br /> <br /> Визначення функцій агентів і менеджерів в стандартах OSI досить добре узгоджуються з визначеннями систем SNMP, за деякими винятками в термінології. Повідомлення, які агент посилає менеджеру за своєю ініціативою, називаються повідомленнями - notifications.<br /> <br /> Наприклад, якщо деякий елемент мережі Х відмовив, то менеджеру необхідно оновити свою базу даних конфігурації мережі. Елемент X, який є для системи управління керованим об'єктом (managed object), може послати повідомлення агенту. Елемент Х може знаходитися в тій же керованої системі, що і агент, або може перебувати в іншій системі. У свою чергу агент надсилає повідомлення менеджеру про те, що елемент Х відмовив. Відповідно до цього повідомленням менеджер оновлює базу даних конфігурації.<br /> <br /> ''ПРИМІТКА''. У стандартах Internet під об'єктом розуміється окремий атрибут бази МIВ, що є моделлю керованого ресурсу, а в стандартах ISO об'єкт позначає всю модель керованого ресурсу.<br /> <br /> Менеджер не тільки збирає і порівнює дані, одержувані від агентів, на основі цих даних він може також виконувати адміністративні функції, керуючи операціями віддалених агентів.<br /> <br /> У стандартах OSI різниця між менеджерами та агентами не дуже чітка. Суб'єкт SMAE, що виконує в одній взаємодії роль менеджера, може в іншій взаємодії виконувати роль агента, і навпаки.Стандарти OSI не визначають способів взаємодії агента з керованими об'єктами. Стандарти OSI також не говорять про те, як агент взаємодіє з керованими об'єктами, які перебувають за межами керованої системи, тобто об'єктами, з якими потрібно взаємодіяти через мережу. У таких випадках може знадобитися, наприклад, щоб один агент запросив дані про деякий об'єкт від іншого агента. Порядок такого роду взаємодії також не визначається стандартами OSI.<br /> <br /> Щоб менеджер і агент змогли взаємодіяти, кожен повинен мати певні відомості про один одного. Ці відомості модель OSI називає контекстом додатку (Application Context, AC). AC описує елементи прикладного рівня стека OSI, які використовуються агентами і менеджерами.<br /> <br /> ''ПРИМІТКА''. Необхідно зазначити, що стандарти управління OSI значною мірою орієнтовані на стек протоколів OSI (саме стек, а не модель OSI), так само як системи управління SNMP орієнтовані на роботу зі стеком TCP / IP.<br /> <br /> Прикладний рівень стека OSI включає кілька допоміжних служб загального призначення, які використовуються прикладними протоколами і клієнтськими програмами (в тому числі і додатками управління) для автоматизації найбільш часто виконуваних дій. Це не закінчені протоколи прикладного рівня, подібні протоколах ftp, telnet або NCP, за допомогою яких користувач мережі може виконати якусь корисну дію, а допоміжні системні функції, які допомагають розробнику прикладного протоколу або програми написати її компактно і ефективно. На прикладному рівні стека OSI існують наступні допоміжних служби:<br /> <br /> *ACSE (Association Control Service Element). Відповідає за встановлення з'єднань між додатками різних систем. З'єднання (сесія, сеанс) на прикладному рівні OSI носить назву асоціації. Асоціації бувають індивідуальними та груповими (shared).<br /> <br /> *RTSE (Reliable Transfer Service Element). Займається підтримкою відновлення діалогу, викликаного розривом нижележащих комунікаційних служб, в рамках асоціації.<br /> <br /> *ROSE (Remote Operations Service Element). Організовує виконання програмних функцій на віддалених машинах (аналог служби виклику віддалених процедур RPC).<br /> <br /> ====Управління системами, управління рівнем та операції рівня====<br /> <br /> Основна модель управління OSI включає: управління системами, управління N-рівнем і операції N-рівня. Це розбиття на три області зроблено для того, щоб врахувати всі можливі ситуації, що виникають при управлінні.<br /> <br /> Управління системами має справу з керованими об'єктами на всіх семи рівнях OSI, включаючи прикладний рівень. Воно засноване на надійній передачі з встановленням з'єднання керуючої інформації між кінцевими системами. Необхідно підкреслити, що модель управління OSI не дозволяє використання служб без встановлення з'єднання.<br /> <br /> Управління N-рівнем обмежено керованими об'єктами якогось певного рівня семирівневої моделі. Протокол управління використовує при цьому комунікаційні протоколи нижчих рівнів. Управління N-рівнем корисно, коли немає можливості використовувати всі семи рівнів OSI. У цьому випадку допускається користуватися протоколом управління N-рівня, який строго призначений для даного рівня. Прикладами рівневого протоколу управління є протоколи управління для локальних мереж, розроблені інститутом IEEE (SMT технології FDDI), які обмежені рівнями 1 і 2.<br /> <br /> Нарешті, операції N-рівня зводяться до моніторингу та управління на основі керуючої інформації, що міститься в комунікаційних протоколах тільки даного рівня. Наприклад, дані моніторингу мережі, що містяться в кадрах STM-n технології SDH, відносяться до операцій N-рівня, а саме фізичного рівня.<br /> Стандарти на управління N-рівнем і операції N-рівня не входять в набір стандартів управління OSI. Стандарти OSI розглядають лише управління системами за допомогою повного семирівневого стека.<br /> <br /> Основна модель управління системами передбачає виконання керуючих операцій і передачу повідомлень між одноранговими системами, що означає необов'язковість жорсткого розподілу ролей на керуючі та керовані системи. Ця модель полегшує реалізацію розподілених аспектів управління. З іншого боку, допускається реалізація однорангових систем як керуючих і керованих.<br /> <br /> ====Інформаційна модель управління====<br /> <br /> Керований об'єкт - це представлення OSI про ресурс з метою управління. Ресурс може бути описаний як керований об'єкт. Конкретний керований об'єкт - це екземпляр (instance) деякого класу керованих об'єктів. Модель управління OSI широко використовує об'єктно-орієнтований підхід. Клас керованих об'єктів - це набір властивостей, які можуть бути обов'язковими або умовними. За допомогою опису одного класу керованих об'єктів, наприклад комутаторів, можна створити інший клас керованих об'єктів, наприклад комутаторів, що підтримують техніку VLAN, успадкувавши всі властивості класу комутаторів, але додавши нові атрибути.<br /> <br /> Для управління ресурсами менеджер і агент повинні бути обізнані про деталі цих ресурсів. Деталізація представлення керованих об'єктів, які потрібні для виконання функцій управління, зберігається в репозиторії, відомому як Management Information Base (MIB). Бази MIB OSI зберігають не тільки описи класів керованих об'єктів, але й характеристики мережі та її елементів. Бази MIB містять характеристики кожної частини керованого обладнання і ресурсів. MIB також включає опис дій, які можуть виконуватися на основі зібраних даних або ж викликані зовнішніми командами. Бази MIB дозволяють зовнішнім системам опитувати, змінювати, створювати і видаляти керовані об'єкти (реальні ресурси мережі при цьому, природно, продовжують працювати). Протокол CMIP і локальні інтерфейси управління забезпечують доступ до цих можливостей.<br /> <br /> MIB - це концептуальна модель, і вона не має ніякого зв'язку зі способом фізичного або логічного зберігання даних в ресурсі. Стандарти не визначають аспекти власне зберігання даних. Протоколи OSI визначають синтаксис інформації, що зберігається в MIB, і семантику обміну даними.<br /> <br /> ====Протокол CMIP та послуги CMIS====<br /> <br /> Доступ до керуючої інформації, що зберігається в керованих об'єктах, забезпечується за допомогою елемента системи управління, званого службою CMSIE (Common Management Information Service Element). Служба CMSIE побудована в архітектурі розподіленого додатку, де частину функцій виконує менеджер, а частина - агент. Взаємодія між менеджером і агентом здійснюється по протоколу CMIP. Послуги, що надаються службою CMSIE, називаються послугами CMIS (Common Management Information Services).<br /> <br /> Протокол CMIP та послуги CMIS визначені в стандартах Х.710 і Х.711 ITU-T. Послуги CMIS поділяються на дві групи - послуги, що ініціюються менеджером (запити), та послуги, що ініціюються агентом (повідомлення).<br /> <br /> Послуги, що ініціюються менеджером, включають наступні операції:<br /> <br /> *M-CREATE інструктує агента про необхідність створити новий екземпляр об'єкту певного класу або новий атрибут усередині екземпляра об'єкта;<br /> <br /> *M-DELETE інструктує агента про необхідність видалення деякого екземпляра об'єкту певного класу або атрибуту усередині екземпляра об'єкта;<br /> <br /> *M-GET інструктує агента про повернення значення деякого атрибуту певного екземпляра об'єкту;<br /> <br /> *M-SET інструктує агента про зміну значення деякого атрибуту певного екземпляра об'єкту;<br /> <br /> *M-ACTION інструктує агента про необхідність виконання певної дії над одним або кількома примірниками об'єктів.<br /> <br /> Агент ініціює тільки одну операцію:<br /> M-EVENT_REPORT - відправка повідомлення менеджеру.<br /> <br /> Для реалізації своїх послуг служба CMISE повинна використовувати служби прикладного рівня стека OSI - ACSE, ROSE.<br /> <br /> Відмінність послуг CMIS від аналогічних послуг SNMP полягає в більшій гнучкості. Якщо запити GET і SET протоколу SNMP застосовні тільки до одного атрибуту одного об'єкта, то запити M-GET, M-SET, M-ACTION і M-DELETE можуть застосовуватися до більш ніж одного об'єкту. Для цього стандарти CMIP / CMIS вводять такі поняття, як огляд (scoping), фільтрація (filtering) і синхронізація (synchronization).<br /> <br /> == Вбудовані засоби моніторингу і аналізу мереж ==<br /> <br /> === Агенти [[SNMP]] ===<br /> <br /> На сьогоднішній день існує кілька стандартів на бази даних управляючої інформації. Основними є стандарти MIB-I і MIB-II, а також версія бази даних для віддаленого управління [[RMON MIB]]. Крім цього, існують стандарти для спеціальних [[MIB]] пристроїв конкретного типу, а також приватні [[MIB]] конкретних фірм-виробників обладнання.<br /> <br /> Початкова специфікація MIB-I визначала лише операції читання значень змінні величини. Операції зміни чи установки значень об'єкта є частиною специфікацій MIB-II.<br /> <br /> Версія MIB-I (RFC 1156) визначає до 114 об'єктів, які поділяються на 8 груп:<br /> <br /> * System - загальні дані про пристрій (наприклад, ідентифікатор постачальника, час останньої ініціалізації системи).<br /> <br /> * Interfaces - описуються параметри мережевих інтерфейсів пристрою (наприклад, їх кількість, типи, швидкості обміну, максимальний розмір пакету).<br /> <br /> * AddressTranslationTable - описується відповідність між мережевими і фізичними адресами (наприклад, за протоколом [[ARP]]).<br /> <br /> * [[IP|InternetProtocol]] - дані, що відносяться до протоколу IP (адреси IP-шлюзів, хостів, статистика про IP-пакети).<br /> <br /> * [[ICMP]] - дані, що пов'язані з протоколом обміну керуючими повідомленнями [[ICMP]].<br /> <br /> * [[TCP]] - дані, що належать до протоколу [[TCP]]. <br /> <br /> * [[UDP]] - дані, що належать до протоколу [[UDP]] (кількість переданих, прийнятих та помилкових UPD-дейтаграмм). <br /> <br /> * [[EGP]] - дані, що пов'язані з протоколом обміну маршрутною інформацією ExteriorGatewayProtocol, який використовується в мережі Internet (число прийнятих з помилками і без помилок повідомлень).<br /> <br /> З цього переліку груп змінних видно, що стандарт MIB-I розроблявся з жорсткою орієнтацією на управління маршрутизаторами, які підтримують протоколи стека TCP/IP.<br /> <br /> У версії MIB-II (RFC 1213), прийнятої в 1992 році, був істотно (до 185) розширено набір стандартних об'єктів, а кількість груп збільшилася до 10.<br /> <br /> У число об'єктів, що описують кожен конкретний інтерфейс пристрою, включені наступні:<br /> <br /> * IfType - тип протоколу, який підтримує інтерфейс. Цей об'єкт приймає значення всіх стандартних протоколів канального рівня, наприклад, rfc877-x25, ethernet-csmacd, iso88023-csmacd, iso88024-tokenBus, iso88025-tokenRing і т. д.<br /> <br /> * IfMtu - максимальний розмір пакета мережного рівня, який можна послати через цей інтерфейс.<br /> <br /> * IfSpeed - пропускна здатність інтерфейсу в бітах в секунду (100 для Fast Ethernet).<br /> <br /> * IfPhysAddress - фізичну адресу порту, для [[Fast Ethernet]] ним буде [[MAC]]-адреса.<br /> <br /> * IfAdminStatus - бажаний статус порту:<br /> <br /> :up - готовий передавати пакети;<br /> :down - не готовий передавати пакети;<br /> :testing - знаходиться в тестовому режимі.<br /> <br /> * IfOperStatus - фактичний поточний статус порту, має ті ж значення, що і ifAdminStatus.<br /> <br /> * IfInOctets - загальна кількість байт, прийняте даним портом, включаючи службові, з моменту останньої ініціалізації SNMP-агента.<br /> <br /> * IfInUcastPkts - кількість пакетів з індивідуальним адресою інтерфейсу, доставлених протоколу верхнього рівня.<br /> <br /> * IfInNUcastPkts - кількість пакетів з широкомовним або мультівещательнимі адресою інтерфейсу, доставлених протоколу верхнього рівня.<br /> <br /> * IfInDiscards - кількість пакетів, які були прийняті інтерфейсом, виявилися коректними, але не були доставлені протоколу верхнього рівня, швидше за все через переповнення буфера пакетів або ж з іншої причини.<br /> <br /> * IfInErrors - кількість пакетів, що прийшли, які не були передані протоколу верхнього рівня через виявлення в них помилок.<br /> <br /> Окрім об'єктів, що описують статистику за вхідними пакетів, є аналогічні об'єкти, пов'язані з вихідними пакетами. Як видно з опису об'єктів MIB-II, ця база даних не дає детальної статистики по характерних помилок кадрів [[Ethernet]], крім цього, вона не відображає зміну характеристик у часі, що часто цікавить мережевого адміністратора. Ці обмеження були згодом зняті новим стандартом на [[MIB]] - [[RMON MIB]], який спеціально орієнтований на збір детальної статистики по протоколу [[Ethernet]], до того ж з підтримкою такої важливої функції, як побудова агентом залежностей статистичних характеристик від часу.<br /> <br /> === Агенти [[RMON]] ===<br /> <br /> Нововведенням до функціональних можливостей SNMP є специфікація RMON, яка забезпечує віддалену взаємодію з базою MIB. До появи RMON протокол SNMP не міг використовуватися віддалено, він допускав лише локальне управління пристроями. База RMONMIB має поліпшений набір властивостей для віддаленого управління, оскільки містить агреговану інформацію про пристрій, що не вимагає передачі по мережі великих обсягів інформації. Об'єкти RMONMIB включають додаткові лічильники помилок в пакетах, гнучкіші засоби аналізу графічних трендів і статистики, більш потужні засоби фільтрації для захоплення і аналізу окремих пакетів, а також більш складні умови встановлення сигналів попередження. Агенти RMONMIB більш інтелектуальні порівняно з агентами MIB-I або MIB-II і виконують значну частину роботи по обробці інформації про пристрій, яку раніше виконували менеджери. Ці агенти можуть розташовуватися усередині різних комунікаційних пристроїв, а також бути виконані у вигляді окремих програмних модулів, що працюють на універсальних ПК і ноутбуках (прикладом може служити LANalyzerNovell). <br /> <br /> Об'єкту [[RMON]] присвоєно номер 16 в наборі об'єктів [[MIB]], а сам об'єкт [[RMON]] об'єднує 10 груп наступних об'єктів:<br /> <br /> * ''Statistics'' - поточні накопичені статистичні дані про характеристики пакетів, кількості колізій тощо. <br /> <br /> * ''History'' - статистичні дані, збережені через певні проміжки часу для подальшого аналізу тенденцій їх змін. <br /> <br /> * ''Alarms'' - порогові значення статистичних показників, при перевищенні яких агент RMON посилає повідомлення менеджеру.<br /> <br /> * ''Host'' - дані про хости мережі, у тому числі про їх [[MAC]]-адресах.<br /> <br /> * ''HostTopN'' - таблиця найбільш завантажених хостів мережі.<br /> <br /> * ''TrafficMatrix'' - статистика про інтенсивність трафіка між кожною парою хостів мережі.<br /> <br /> * ''Filter'' - умови фільтрації пакетів. <br /> <br /> * ''PacketCapture'' - умови захоплення пакетів. <br /> <br /> * ''Event'' - умови реєстрації і генерації подій.<br /> <br /> Дані групи пронумеровані у вказаному порядку, тому, наприклад, група Hosts має числове ім'я 1.3.6.1.2.1.16.4.<br /> <br /> Десяту групу складають спеціальні об'єкти протоколу TokenRing.<br /> <br /> Всього стандарт RMONMIB визначає близько 200 об'єктів в 10 групах, зафіксованих в двох документах - RFC 1271 для мереж Ethernet і RFC 1513 для мереж TokenRing.<br /> <br /> Відмінною рисою стандарту RMONMIB є його незалежність від протоколу мережевого рівня (на відміну від стандартів MIB-I і MIB-II, орієнтованих на протоколи TCP / IP). Тому, його зручно використовувати в гетерогенних середовищах, що використовують різні протоколи мережевого рівня.<br /> <br /> Розглянемо більш докладно групу Statistics, яка визначає, яку інформацію про кадри [[Ethernet]] може надати агент RMON.<br /> <br /> До групи Statistics входять наступні об'єкти:<br /> <br /> *''etherStatsDropEvents'' - загальне число подій, при яких пакети були проігноровані агентом через нестачу його ресурсів. Самі пакети при цьому не обов'язково були втрачені.<br /> <br /> *''etherStatsOrtets'' - загальне число байт (включаючи помилкові пакети), прийнятих з мережі (крім заголовка але з байтами контрольної суми).<br /> <br /> *''etherStatsPkts'' - загальне число отриманих пакетів (включаючи помилкові).<br /> <br /> *''etherStatsBroadcastPkts'' - загальне число хороших пакетів, які були надіслані широкомовною адресою.<br /> <br /> *''etherStatsMulticastPkts'' - загальне число хороших пакетів, отриманих за мультівещательнимі адресою.<br /> <br /> *''etherStatsCRCAlign Errors'' - загальне число отриманих пакетів, які мали довжину (виключаючи заголовок) між 64 і 1518 байт, не містили ціле число байт (alignment error) або мали невірну контрольну суму (FCS error).<br /> <br /> *''etherStatsUndersizePkts'' - загальне число пакетів, які мали довжину менше, ніж 64 байт, але були правильно сформовані.<br /> <br /> *''etherStatsOversizePkts'' - загальне число отриманих пакетів, які мали довжину більше, ніж 1518 байт, але були тим не менш правильно сформовані.<br /> <br /> *''etherStatsFragments'' - загальне число отриманих пакетів, які не складалися з цілого числа байт або мали невірну контрольну суму і мали до того ж довжину, меншу 64 байт.<br /> <br /> *''etherStatsJabbers'' - загальне число отриманих пакетів, які не складалися з цілого числа байт або мали невірну контрольну суму і мали до того ж довжину, більшу 1518 байт.<br /> <br /> *''etherStatsCollisions'' - найкраща оцінка числа колізій на даному сегменті Ethernet.<br /> <br /> *''etherStatsPkts640ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром 64 байт.<br /> <br /> *''etherStatsPkts65to1270ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 65 до 127 байт.<br /> <br /> *''etherStatsPktsl28to2550ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 128 до 255 байт.<br /> <br /> *''etherStatsPkts256to5110ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 256 до 511 байт.<br /> <br /> *''etherStatsPkts512tol0230ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 512 до 1023 байт.<br /> <br /> *''etherStatsPktsl024tol5180ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 1024 до 1518 байт.<br /> <br /> Як видно з опису об'єктів, за допомогою агента RMON, вбудованого в повторювач або інше комунікаційне обладнання, можна провести дуже детальний аналіз роботи сегмента Ethernet або Fast Ethernet. Спочатку можна отримати дані про типи помилок в кадрах, що зустрічаються в сегменті, а потім доцільно зібрати за допомогою группи History залежності інтенсивності цих помилок від часу (в тому числі і прив'язавши їх до часу). Після аналізу тимчасових залежностей часто вже можна зробити деякі попередні висновки про джерело помилкових кадрів і на цій підставі сформулювати більш тонкі умови захоплення кадрів зі специфічними ознаками (задавши умови в групі Filter). Після цього можна провести ще більш детальний аналіз за рахунок вивчення захоплених кадрів, витягуючи їх з об'єктів группи Packet Capture.<br /> <br /> Пізніше був прийнятий стандарт RMON 2, який поширює ідеї інтелектуальної RMON MIB на протоколи верхніх рівнів, виконуючи частину роботи аналізаторів протоколів.<br /> <br /> == Аналізатори протоколів ==<br /> <br /> У ході проектування нової або модернізації старої мережі часто виникає необхідність в кількісному вимірі деяких характеристик мережі таких, наприклад, як інтенсивності потоків даних по лініях зв'язку, затримки, що виникають на різних етапах обробки пакетів, часи реакції на запити того чи іншого виду, частота виникнення певних подій та інших характеристик.<br /> <br /> Для цих цілей можуть бути використані різні засоби і насамперед - засоби моніторингу в системах управління мережею, які вже обговорювалися в попередніх розділах. Деякі вимірювання мережі можуть бути виконані і вбудованими в операційну систему програмами.<br /> <br /> Але найбільш досконалим засобом дослідження мережі є аналізатор протоколів. Процес аналізу протоколів включає захоплення циркулюючих в мережі пакетів, що реалізують той чи інший мережевий протокол, і вивчення вмісту цих пакетів. Ґрунтуючись на результатах аналізу, можна здійснювати обґрунтовану і зважену зміну будь-якого компонента мережі, оптимізацію її продуктивності, пошук і усунення неполадок. Очевидно, що для того, щоб можна було зробити якісь висновки про вплив деякої зміни на мережу, необхідно виконати аналіз протоколів і до, і після внесення змін.<br /> <br /> Аналізатор протоколів є самостійним спеціалізованим пристроєм, або персональним комп'ютером, зазвичай переносним, класу Notebook, оснащений спеціальною мережевою картою і відповідним програмним забезпеченням. Мережева карта і програмне забезпечення, що використовуються повинні відповідати топології мережі (кільце, шина, зірка). Аналізатор підключається до мережі точно так, як і звичайний вузол. Відмінність полягає в тому, що аналізатор може приймати всі пакети даних, що передаються по мережі, в той час як звичайна станція - лише адресовані їй. Програмне забезпечення аналізатора складається з ядра, що підтримує роботу мережевого адаптера і декодує одержувані дані, та додаткового програмного коду, що залежить від типу топології досліджуваної мережі. Крім того, поставляється ряд процедур декодування, орієнтованих на певний протокол, наприклад, IPX. До складу деяких аналізаторів може входити також експертна система, яка може видавати користувачеві рекомендації про те, які експерименти слід проводити в даній ситуації, що можуть означати ті чи інші результати вимірювань, як усунути деякі види несправності мережі.<br /> <br /> Незважаючи на відносне різноманіття аналізаторів протоколів, представлених на ринку, можна назвати деякі риси, в тій чи іншій мірі притаманні всім їм:<br /> <br /> *''Інтерфейс користувача''. Більшість аналізаторів мають розвинений дружній інтерфейс, який базується, як правило, на Windows чи Motif. Цей інтерфейс дозволяє користувачеві: виводити результати аналізу інтенсивності трафіку; отримувати миттєву і середню статистичну оцінку продуктивності мережі; задавати певні події і критичні ситуації для відстежування їх виникнення; робити декодування протоколів різного рівня і представляти в зрозумілій формі вміст пакетів.<br /> <br /> *''Буфер захоплення''. Буфери різних аналізаторів відрізняються за обсягом. Буфер може розташовуватися на мережевій карті, або для нього може бути відведено місце в оперативній пам'яті одного з комп'ютерів мережі. Якщо буфер розташований на мережевій карті, то управління ним здійснюється апаратно, і за рахунок цього швидкість введення підвищується. Однак це призводить до подорожчання аналізатора. У разі недостатньої продуктивності процедури захоплення, частина інформації буде губитися, і аналіз буде неможливий. Розмір буфера визначає можливості аналізу по більш або менш представницьким вибіркам даних, що захоплюються. Але яким би великим не був буфер захоплення, рано чи пізно він заповниться. У цьому випадку або припиняється захоплення, або заповнення починається з початку буфера.<br /> <br /> *Можливість ''вимірювання середньостатистичних показників трафіку в сегменті локальної мережі'', в якому встановлений мережевий адаптер аналізатора.<br /> <br /> *Вимірюється коефіцієнт використання сегменту, матриці перехресного трафіку вузлів, кількість хороших і поганих кадрів, що пройшли через сегмент.<br /> <br /> *Можливість роботи з декількома агентами, котрі поставляють захоплені пакети з різних сегментів локальної мережі. Ці агенти найчастіше взаємодіють з аналізатором протоколів за власним протоколом прикладного рівня.<br /> <br /> *''Фільтри''. Фільтри дозволяють керувати процесом захоплення даних, і, тим самим, дозволяють економити простір буфера. Залежно від значення певних полів пакета, заданих у вигляді умови фільтрації, пакет або ігнорується, або записується в буфер захоплення. Використання фільтрів значно прискорює і спрощує аналіз, оскільки виключає перегляд непотрібних в даний момент пакетів.<br /> <br /> *''Перемикачі'' - це деякі умови початку і припинення процесу захоплення даних з мережі, що задаються користувачем. Такими умовами можуть бути виконання ручних команд запуску і зупинки процесу захоплення, тривалість процесу захоплення, поява певних значень в кадрах даних. Перемикачі можуть використовуватися спільно з фільтрами, дозволяючи більш детально й тонко проводити аналіз, а також продуктивніше використовувати обмежений обсяг буфера захоплення.<br /> <br /> *''Пошук''. Деякі аналізатори протоколів дозволяють автоматизувати перегляд інформації, що знаходиться в буфері, і знаходити в ній дані по заданим критеріям. У той час, як фільтри перевіряють вхідний потік на предмет відповідності умовам фільтрації, функції пошуку застосовуються до вже накопичених в буфері даних.<br /> <br /> *''Багатоканальність''. Деякі аналізатори протоколів дозволяють проводити одночасний запис пакетів від декількох мережевих адаптерів, що зручно для зіставлення процесів, що відбуваються в різних сегментах мережі. Можливості аналізу проблем мережі на фізичному рівні у аналізаторів протоколів мінімальні, оскільки всю інформацію вони отримують від стандартних мережевих адаптерів. Тому вони передають і узагальнюють інформацію фізичного рівня, яку повідомляє їм мережевий адаптер, а вона багато в чому залежить від типу мережного адаптера. Деякі мережні адаптери повідомляють більш детальні дані про помилки кадрів та інтенсивності колізій в сегменті, а деякі взагалі не передають таку інформацію верхнім рівням протоколів, на яких працює аналізатор протоколів.<br /> <br /> Методологія проведення аналізу може бути представлена у вигляді наступних шести етапів:<br /> <br /> *Захоплення даних.<br /> <br /> *Перегляд захоплених даних.<br /> <br /> *Аналіз даних.<br /> <br /> *Пошук помилок (більшість аналізаторів полегшують цю роботу, визначаючи типи помилок і ідентифікуючи станцію, від якої прийшов пакет з помилкою).<br /> <br /> *Дослідження продуктивності. Розраховується коефіцієнт використання пропускної здатності мережі або середній час реакції на запит.<br /> <br /> *Докладне дослідження окремих ділянок мережі. Зміст цього етапу конкретизується в міру того, як проводиться аналіз.<br /> <br /> Зазвичай процес аналізу протоколів займає відносно небагато часу - 1-2 робочих дні.<br /> <br /> == Обладнання для діагностики та сертифікації кабельних систем ==<br /> <br /> До обладнання даного класу відносяться мережеві аналізатори, прилади для сертифікації кабелів, кабельні сканери і тестери. Перш, ніж перейти до більш докладного огляду цих пристроїв, наведемо деякі необхідні відомості про основні електромагнітні характеристики кабельних систем.<br /> <br /> === Основні електромагнітні характеристики кабельних систем ===<br /> <br /> Основними електричними характеристиками, що впливають на роботу кабелю, є: затухання, імпеданс (хвильовий опір), перехресні наводки двох кручених пар і рівень зовнішнього електромагнітного випромінювання.<br /> <br /> ''Перехресні наводки між витими парами або NearEndCrosstalk (NEXT)'' - являють собою результат інтерференції електромагнітних сигналів, що виникають у двох кручених парах. Один з кабелів крученої пари передає сигнал, а другий - приймає. При проходженні сигналу по одному з кабелів, наприклад, по тому, що передає, у кабелі, що приймає сигнал виникають перехресні наводки. Величина NEXT залежить від частоти переданого сигналу - чим вище величина NEXT, тим краще (для категорії 5 NEXT повинен бути не менше 27 Дб при частоті 100 Мгц, для кабелю категорії 3 на частоті 10 МГц NEXT повинен бути не менше 26 Дб).<br /> <br /> ''Затухання (Attenuation)'' - являє собою втрату амплітуди електричного сигналу при його поширенні по кабелю. Затухання має два основних джерела: електричні характеристики кабелю і поверхневий ефект. Останній пояснює залежність затухання від частоти. Затухання вимірюється в децибелах на метр. Для кабелю категорії 5 при частоті 100 Мгц загасання не повинно перевищувати 23.6 Дб на 100 м, а для кабелю категорії 3, за стандартом IEEE 802.3 10BASE-T, допустима величина затухання на сегменті довжиною 100 м не повинна перевищувати 11,5 Дб при частоті змінного струму 10 МГц.<br /> <br /> ''Імпеданс (хвильовий опір)'' - це повний (активне і реактивне) опір в електричному ланцюзі. Імпеданс вимірюється в омах і є відносно постійною величиною для кабельних систем. Для неекранованої крученої пари найбільш часті значення імпедансу - 100 і 120 Ом. Характерні значення імпедансу для мереж стандарту Ethernet на коаксіальному кабелі становлять 50 Ом, а для мереж стандарту Arcnet - 93 Ом. Різкі зміни імпедансу по довжині кабелю можуть викликати процеси внутрішнього відображення, що призводять до виникнення стоячих хвиль. Стояча хвиля — тип коливань у неперервному середовищі, при яких кожна точка середовища здійснює періодичний рух зі сталою амплітудою, залежною від її положення. Стоячі хвилі не переносять енергію. Робоча станція, підключена до кабелю у районі вузла стоячої хвилі, не зможе отримувати адресовані їй повідомлення.<br /> <br /> ''Активний опір'' - це опір постійному струму в електричному ланцюзі. На відміну від імпедансу активний опір не залежить від частоти і зростає зі збільшенням довжини кабелю. Для неекранованої крученої пари категорії 5 активний опір не повинен перевищувати 9.4 Ом на 100 м.<br /> <br /> ''Ємність'' - це властивість металевих провідників накопичувати енергію. Два електричних провідника в кабелі, розділені діелектриком, являють собою конденсатор, здатний накопичувати заряд. Ємність є небажаною величиною, тому її слід робити якомога менше. Високе значення ємності в кабелі приводить до спотворення сигналу і обмежує смугу пропускання лінії. Для кабельних систем категорії 5 значення ємності не повинен перевищувати 5.6нФ на 100 м.<br /> <br /> ''Рівень зовнішнього електромагнітного випромінювання, або електричний шум'' - це небажана зміна напруги в провіднику. Електричний шум буває двох типів: фоновий і імпульсний. Електричний шум можна також розділити на низько-, середньо-і високочастотний. Джерелами фонового електричного шуму є в діапазоні до 150 КГц лінії електропередачі, телефони і лампи денного світла; в діапазоні від 150 КГц до 20 Мгц комп'ютери, принтери, ксерокси; в діапазоні від 20 МГц до 1 ГГц – теле- і радіопередавачі, мікрохвильові печі. Основними джерелами імпульсного електричного шуму є мотори, перемикачі і зварювальні агрегати. Електричний шум вимірюється в мВ. Кабельні системи на крученій парі не сильно схильні до впливу електричного шуму (на відміну від впливу NEXT).<br /> <br /> ===Мережеві аналізатори===<br /> <br /> Мережеві аналізатори (не слід плутати їх з аналізаторами протоколів) являють собою еталонні вимірювальні інструменти для діагностики та сертифікації кабелів і кабельних систем. Як приклад можна привести мережеві аналізатори компанії HewlettPackard - HP 4195A і HP 8510C.<br /> Мережеві аналізатори містять високоточний частотний генератор і вузькосмуговий приймач. Передаючи сигнали різних частот в передавальну пару і вимірюючи сигнал у приймальній парі, можна виміряти затухання і NEXT. Мережеві аналізатори - це великогабаритні і дорогі прилади, призначені для використання в лабораторних умовах спеціально навченим технічним персоналом.<br /> <br /> ===Кабельні сканери===<br /> <br /> Дані прилади дозволяють визначити довжину кабелю, NEXT, затухання, імпеданс, схему розводки, рівень електричних шумів і провести оцінку отриманих результатів. Існує досить багато пристроїв даного класу, наприклад, сканери компаній MicrotestInc., FlukeCorp., DatacomTechnologiesInc., ScopeCommunicationInc. На відміну від мережевих аналізаторів сканери можуть бути використані не тільки спеціально навченим технічним персоналом, але навіть адміністраторами-новачками.<br /> <br /> Для визначення місця розташування несправності кабельної системи (обриву, короткого замикання, неправильно встановленого роз'єму і т.д.) використовується метод &quot;кабельного радара&quot;, або TimeDomainReflectometry (TDR). Суть цього методу полягає в тому, що сканер випромінює в кабель короткий електричний імпульс і вимірює час затримки до приходу відбитого сигналу. За полярності відображеного імпульсу визначається характер пошкодження кабелю (коротке замикання або обрив). У правильно встановленому і підключеному кабелі відбитий імпульс зовсім відсутній.<br /> <br /> Точність вимірювання відстані залежить від того, наскільки точно відома швидкість розповсюдження електромагнітних хвиль у кабелі. У різних кабелях вона буде різною. Швидкість розповсюдження електромагнітних хвиль у кабелі (NVP) зазвичай задається у відсотках до швидкості світла у вакуумі. Сучасні сканери містять в собі електронну таблицю даних про NVP для всіх основних типів кабелів і дозволяють користувачеві встановлювати ці параметри самостійно після попереднього калібрування.<br /> <br /> Найбільш відомими виробниками компактних кабельних сканерів є компанії MicrotestInc., WaveTekCorp., ScopeCommunicationInc.<br /> <br /> ===Тестери===<br /> <br /> Тестери кабельних систем - найбільш прості і дешеві прилади для діагностики кабелю. Вони дозволяють визначити пошкодження кабеля, проте, на відміну від кабельних сканерів, не дають відповіді на питання про те, в якому місці стався збій.<br /> <br /> <br /> Перейти до [[Засоби аналізу та оптимізації мереж]]<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%97%D0%B0%D1%81%D0%BE%D0%B1%D0%B8_%D0%BC%D0%BE%D0%BD%D1%96%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3%D1%83_%D1%82%D0%B0_%D0%B0%D0%BD%D0%B0%D0%BB%D1%96%D0%B7%D1%83_%D0%BC%D0%B5%D1%80%D0%B5%D0%B6%D1%96 2011-12-18T14:56:04Z

<p>Aleksey: </p> <hr /> <div>== Класифікація засобів моніторингу та аналізу ==<br /> <br /> Всі засоби моніторингу та аналізу мереж, можна розділити на кілька великих класів:<br /> <br /> *''Системи управління мережею'' ([http://en.wikipedia.org/wiki/Network_management_system Network Management Systems]) - централізовані програмні системи, які збирають дані про стан вузлів і комунікаційних пристроїв мережі, а також дані про трафік в мережі. Ці системи не тільки здійснюють моніторинг і аналіз, а й виконують в автоматичному чи напівавтоматичному режимі управління мережею - включення і відключення портів пристроїв, зміна параметрів мостів адресних таблиць мостів, комутаторів і маршрутизаторів і т.п. Прикладами систем управління можуть служити популярні системи HPOpenView, SunNetManager, IBMNetView.<br /> <br /> *''Засоби управління системою'' ([http://uk.wikipedia.org/wiki/%D0%92%D0%B1%D1%83%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B0_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0#.D0.90.D1.80.D1.85.D1.96.D1.82.D0.B5.D0.BA.D1.82.D1.83.D1.80.D0.B8_.D0.BF.D1.80.D0.BE.D0.B3.D1.80.D0.B0.D0.BC.D0.BD.D0.BE.D0.B3.D0.BE_.D0.B7.D0.B0.D0.B1.D0.B5.D0.B7.D0.BF.D0.B5.D1.87.D0.B5.D0.BD.D0.BD.D1.8F_.D0.B2.D0.B1.D1.83.D0.B4.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.85_.D1.81.D0.B8.D1.81.D1.82.D0.B5.D0.BC System Management]). Засоби управління системою часто виконують функції, аналогічні функціям систем управління, але стосовно інших об'єктів. У першому випадку об'єктом управління є програмне і апаратне забезпечення комп'ютерів мережі, а у другому - комунікаційне устаткування. Разом з тим, деякі функції цих двох видів систем управління можуть дублюватися, наприклад, засоби управління системою можуть виконувати найпростіший аналіз мережевого трафіку.До найбільш відомих систем управління системами відносяться LANDesk, IBM Tivoli, Microsoft Systems Management Server, HP OpenView, Novell ZENworks і CA Unicenter.<br /> <br /> *''Вбудовані системи діагностики і управління'' ([http://en.wikipedia.org/wiki/Embedded_system Embedded Systems]). Ці системи виконуються у вигляді програмно-апаратних модулів, які встановлюються в комунікаційне обладнання, а також у вигляді програмних модулів, вбудованих в операційні системи. Вони виконують функції діагностики і управління тільки одним пристроєм, і в цьому їх основна відмінність від централізованих систем управління. Прикладом засобів цього класу може служити модуль управління концентратором Distrebuted 5000, реалізує функції автосигментацієї портів при виявленні несправностей, приписування портів внутрішнім сегментам концентратора і деякі інші. Як правило, вбудовані модулі управління також виконують роль SNMP-агентів, які поставляють дані про стан пристрою системам управління. <br /> <br /> *''Аналізатори протоколів'' (Protocolanalyzers). Представляють собою програмні або апаратно-програмні системи, які обмежуються на відміну від систем управління лише функціями моніторингу і аналізу трафіку в мережах. Хороший аналізатор протоколів може захоплювати і декодувати пакети великої кількості протоколів, що застосовуються в мережах - зазвичай кілька десятків. Аналізатори протоколів дозволяють встановити деякі логічні умови для захоплення окремих пакетів і виконують повне декодування захоплених пакетів, тобто показувати в зручній для користувача формі вкладеність пакетів протоколів різних рівнів один в одного з розшифруванням змісту окремих полів кожного пакета.<br /> <br /> *''Обладнання для діагностики і сертифікації кабельних систем''. Умовно це устаткування можна поділити на чотири основні групи: мережні монітори, прилади для сертифікації кабельних систем, кабельні сканери і тестери (мультиметри). Мережеві монітори (називають також мережевими аналізаторами) призначені для тестування кабелів різних категорій. Слід розрізняти мережеві монітори і аналізатори протоколів. Мережеві монітори збирають дані лише про статистичні показники трафіку - середньої інтенсивності загального трафіку мережі, середньої інтенсивності потоку пакетів з певним типом помилки і т.п. Призначення пристроїв для сертифікації кабельних систем, безпосередньо випливає з їх назви. Сертифікація виконується відповідно до вимог одного з міжнародних стандартів на кабельні системи. Кабельні сканери використовуються для діагностики мідних кабельних систем. Тестери призначені для перевірки кабелів на відсутність фізичного розриву.<br /> <br /> *''Експертні системи''. Цей вид систем акумулює людські знання про виявлення причин аномальної роботи мереж і можливі способи приведення мережі у працездатний стан. Експертні системи часто реалізуються у вигляді окремих підсистем різних засобів моніторингу та аналізу мереж: систем управління мережами, аналізаторів протоколів, мережевих аналізаторів. Найпростішим варіантом експертної системи є контекстно-залежна help-система. Більш складні експертні системи являють собою так звані бази знань, що володіють елементами штучного інтелекту. Прикладом такої системи є експертна система, вбудована в систему управління Spectrum компанії Cabletron. <br /> <br /> *''Багатофункціональні пристрої аналізу та діагностики''. У зв'язку з розповсюдженням локальних мереж виникла необхідність розробки недорогих портативних приладів, які суміщають функції декількох пристроїв: аналізаторів протоколів, кабельних сканерів і, навіть, деяких можливостей ПЗ мережного управління. Як приклад такого роду пристроїв можна привести Compas компанії MicrotestInc. або 675 LANMeterкомпаніі FlukeCorp.<br /> <br /> == Системи управління ==<br /> Відповідно до рекомендацій ISO можна виділити такі функцій '''засобів управління мережею''':<br /> <br /> * ''Управління конфігурацією мережі'' - полягає в конфігурації компонентів мережі, включаючи їх місце розташування, мережні адреси і ідентифікатори, управління параметрами мережевих операційних систем, підтримку схеми мережі: також ці функції використовуються для іменування об'єктів. <br /> <br /> * ''Обробка помилок'' - це виявлення і усунення наслідків збоїв у роботі мережі. <br /> <br /> * ''Аналіз продуктивності'' - допомагає на основі накопиченої статистичної інформації оцінювати час відповіді системи і величину трафіка, а також планувати розвиток мережі. <br /> <br /> * ''Управління безпекою'' - включає в себе контроль доступу та збереження цілісності даних. У функції входить процедура аутентифікації, перевірки привілеїв, підтримка ключів шифрування, управління правами. До цієї ж групи можна віднести важливі механізми управління паролями, зовнішнім доступом, з'єднання з іншими мережами. <br /> <br /> * ''Облік роботи мережі'' - включає реєстрацію і управління використовуваними ресурсами і пристроями. Ця функція оперує такими поняттями як час використання і плата за ресурси.<br /> <br /> З наведеного списку видно, що системи управління виконують не тільки функції моніторингу та аналізу роботи мережі, необхідні для отримання вихідних даних для налаштування мережі, але і включають функції активного впливу на мережу - управління конфігурацією і безпекою, які потрібні для відпрацювання виробленого плану настройки та оптимізації мережі. Сам етап створення плану налаштування мережі зазвичай залишається за межами функцій системи управління, хоча деякі системи управління мають у своєму складі експертні підсистеми, що допомагають адміністратору або интегратору визначити необхідні заходи з настроювання мережі. <br /> <br /> Засоби управління мережею (NetworkManagement), не слід плутати із засобами управління комп'ютерами та їх операційними системами (SystemManagement). Типовими представниками засобів управління мережами є системи HPOpenView, SunNetManager і IBMNetView.<br /> <br /> '''Засоби управління системою''' зазвичай виконують такі функції:<br /> <br /> *''Облік використовуваних апаратних і програмних засобів''. Система автоматично збирає інформацію про комп'ютери і створює записи в базі даних про апаратні і програмні ресурси. Після цього адміністратор може швидко з'ясувати, що він має і де це знаходиться. Наприклад, дізнатися про те, на яких комп'ютерах потрібно оновити драйвери принтерів, які ПК мають достатню кількість пам'яті і дискового простору і т. п. <br /> <br /> * ''Розподіл й встановлення програмного забезпечення''. Після завершення обстеження адміністратор може створити пакети розсилки програмного забезпечення, що являється дуже ефективним способом для зменшення вартості такої процедури. Система може також дозволяти централізовано встановлювати і адмініструвати програми, які запускаються з файлових серверів, а також дати можливість кінцевим користувачам запускати такі програми з будь-якої робочої станції мережі.<br /> <br /> * ''Віддалений аналіз продуктивності і виникаючих проблем''. Адміністратор може віддалено управляти ресурсами будь-якого ПК, що працює в мережі. База даних системи управління зберігає детальну інформацію про конфігурацію всіх комп'ютерів в мережі для того, щоб можна було виконувати віддалений аналіз виникаючих проблем.<br /> <br /> Прикладами засобів управління системою є такі продукти, як SystemManagementServer компанії Microsoft або LANDeskManager фірми Intel.<br /> <br /> Останнім часом в області систем управління спостерігаються дві досить чітко виражені тенденції: <br /> <br /> *інтеграція в одному продукті функцій управління мережами і системами;<br /> *розподіленість системи управління, при якій в системі існує кілька консолей, які збирають інформацію про стан пристроїв і систем та видають керуючі дії.<br /> <br /> ===Стандарти управління мережою===<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Організація&lt;/td&gt;<br /> &lt;td&gt;Стандарти&lt;/td&gt;<br /> &lt;td&gt;Особливості&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;IETF&lt;/td&gt;<br /> &lt;td&gt;SNMP&lt;/td&gt;<br /> &lt;td&gt;Управління має бути простим, орієнтоване на змінні&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;ISO&lt;/td&gt;<br /> &lt;td&gt;CMIP, CMIS&lt;/td&gt;<br /> &lt;td&gt;Управління має бути потужним, об'єктно-орієнтованим&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;ITU-T&lt;/td&gt;<br /> &lt;td&gt;TMN&lt;/td&gt;<br /> &lt;td&gt;Визначена тільки архітектура&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;DMTF&lt;/td&gt;<br /> &lt;td&gt;WBEM, CIM&lt;/td&gt;<br /> &lt;td&gt;Управління мережами і системами, об'єктно-орієнтоване&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;OMG&lt;/td&gt;<br /> &lt;td&gt;CORBA&lt;/td&gt;<br /> &lt;td&gt;Архітектура віддалених об'єктів&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> Нині найуспішнішим сімейством стандартів є [[SNMP]]. Він лідирує за кількістю керованих систем (агентів). Керуючі системи (менеджери) зазвичай підтримують безліч стандартів, тому тут складно говорити про лідерство SNMP. За кількістю вкладених грошей, можливо, лідирує Telecommunications Management Network (TMN).<br /> <br /> Показово простежити залежність популярності стандартів від середовища їх застосування. У локальних і глобальних мережах передачі даних, що використовують Протокол інтернету (Internet Protocol, IP) найбільш широко розповсюджений стандарт [[SNMP]]. У системах відомчих автоматичних телефонних станцій (ВАТС) та в публічних телефонних мережах найбільш часто використовуються пропрієтарні рішення. У мобільних мережах в основному використовуються рішення на основі стандартів ISO.<br /> <br /> Майже всі успіхи SNMP пов'язані з особливостями процесу стандартизації в IETF:<br /> <br /> *Стандарти безкоштовні і вільно розповсюджувані;<br /> <br /> *Стандарти легко доступні в електронній формі;<br /> <br /> *Швидкий розвиток стандартів, продумані етапи стандартизації;<br /> <br /> *На всіх етапах ведеться технічна експертиза;<br /> <br /> *Робочі групи очолюють технічні, а не політичні лідери;<br /> <br /> *Прототипи систем на основі стандартів демонструють їх придатність;<br /> <br /> ===Протокол [[SNMP]]===<br /> <br /> Створення систем управління мережами неможливе без орієнтації на певні стандарти, тому що управляюче програмне забезпечення та мережеве обладнання розробляють сотні компаній. Оскільки корпоративна мережа напевно неоднорідна, керуючі інструменти не можуть відображати специфіки однієї системи або мережі. <br /> Найбільш поширеним протоколом управління мережами є протокол [[SNMP]] (SimpleNetworkManagementProtocol), його підтримують сотні виробників. Головні переваги протоколу SNMP - простота, доступність, незалежність від виробників. Значною мірою саме популярність [[SNMP]] затримала прийняття CMIP, варіанта керуючого протоколу за версією OSI. Протокол SNMP розроблений для управління маршрутизаторами в мережі Internet і є частиною стека TCP/IP.<br /> <br /> У системах управління, побудованих на основі протоколу [[SNMP]], стандартизуються наступні елементи:<br /> <br /> *протокол взаємодії агента і менеджера;<br /> <br /> *мова опису моделей MIВ та повідомлень [[SNMP]] - мова абстрактної синтаксичної нотації ASN.1 (стандарт ISO 8824:1987, рекомендації ITU-T X.208);<br /> <br /> *кілька конкретних моделей MIB (MIB-I, MIB-II, RMON, RMON 2), імена об'єктів яких реєструються в дереві стандартів ISO. Все інше віддається на розсуд розробника системи управління. Протокол SNMP і тісно пов'язана з ним концепція SNMP MIB були розроблені для управління маршрутизаторами Internet як тимчасове рішення. Але, як це часто буває з усім тимчасовим, простота і ефективність вирішення забезпечили успіх цього протоколу, і сьогодні він використовується при управлінні практично будь-якими видами обладнання і програмного забезпечення обчислювальних мереж. І хоча в області управління телекомунікаційними мережами спостерігається стійка тенденція застосування стандартів ITU-T, в які входить протокол CMIP, і тут є досить багато прикладів успішного використання SNMP-управління. Агенти SNMP вбудовуються в аналогові модеми, модеми ADSL, комутатори АТМ і т. д.<br /> <br /> SNMP - це протокол, що використовується для отримання від мережевих пристроїв інформації про їх статус, продуктивність та характеристики, які зберігаються в спеціальній базі даних мережевих пристроїв, що називається MIB (ManagementInformationBase). Існують стандарти, що визначають структуру MIB, в тому числі набір типів її змінних (об'єктів в термінології ISO), їх імена і допустимі операції цими змінними (наприклад, читати). У MIB, поряд з іншою інформацією, можуть зберігатися мережеві та / або MAC-адреси пристроїв, значення лічильників оброблених пакетів і помилок, номери, пріоритети та інформація про стан портів. Деревоподібна структура MIB містить обов'язкові (стандартні) піддерева, а також в ній можуть знаходитися приватні (private) піддерева, що дозволяють виробнику інтелектуальних пристроїв реалізувати будь-які специфічні функції на основі його специфічних змінних. <br /> <br /> Агент в протоколі SNMP - це елемент, який надає менеджерам, розміщеним на керуючих станціях мережі, доступ до значень змінних MIB, і тим самим дає їм можливість реалізовувати функції з управління та спостереження за пристроєм. Типова структура системи управління зображена на наступному малюнку:<br /> <br /> [[Файл:Locnop2211.gif]] <br /> <br /> ===Стандарти управління OSI===<br /> <br /> ====Загальні відомості. Концепція SMAE====<br /> <br /> Модель мережевого управління OSI - OSI Management Framework - визначена в документі ISO / IEC 7498-4: Basic Reference Model, Part 4, Management Framework.<br /> <br /> Документ ISO / IEC 7498-4 складається з наступних основних розділів:<br /> <br /> *Терміни та загальні концепції.<br /> <br /> *Модель управління системами.<br /> <br /> *Інформаційна модель.<br /> <br /> *Функціональні області управління системами.<br /> <br /> *Структура стандартів управління системами.<br /> <br /> Функціональні області управління системами вже були розглянуті вище.<br /> <br /> Стандарти ISO в галузі управління використовує термінологію, яка частково збігається з термінологією систем управління SNMP.<br /> <br /> Як показано на малюнку, обмін керуючою інформацією з використанням протоколу управління (Management Protocol) відбувається між суб'єктами програм управління системами (Systems Management Application Entities, SMAE):<br /> <br /> [[Файл:Smae.jpg]]<br /> <br /> Суб'єкти SMAE розташовані на прикладному рівні семирівневої моделі OSI і є елементами служби управління. Під суб'єктом в моделі OSI розуміється активний в даний момент елемент протоколу будь-якого рівня, який бере участь у взаємодії. Прикладами SMAE є агенти та менеджери систем управління.<br /> <br /> ====Агенти та менеджери====<br /> <br /> Визначення функцій агентів і менеджерів в стандартах OSI досить добре узгоджуються з визначеннями систем SNMP, за деякими винятками в термінології. Повідомлення, які агент посилає менеджеру за своєю ініціативою, називаються повідомленнями - notifications.<br /> <br /> Наприклад, якщо деякий елемент мережі Х відмовив, то менеджеру необхідно оновити свою базу даних конфігурації мережі. Елемент X, який є для системи управління керованим об'єктом (managed object), може послати повідомлення агенту. Елемент Х може знаходитися в тій же керованої системі, що і агент, або може перебувати в іншій системі. У свою чергу агент надсилає повідомлення менеджеру про те, що елемент Х відмовив. Відповідно до цього повідомленням менеджер оновлює базу даних конфігурації.<br /> <br /> ''ПРИМІТКА''. У стандартах Internet під об'єктом розуміється окремий атрибут бази МIВ, що є моделлю керованого ресурсу, а в стандартах ISO об'єкт позначає всю модель керованого ресурсу.<br /> <br /> Менеджер не тільки збирає і порівнює дані, одержувані від агентів, на основі цих даних він може також виконувати адміністративні функції, керуючи операціями віддалених агентів.<br /> <br /> У стандартах OSI різниця між менеджерами та агентами не дуже чітка. Суб'єкт SMAE, що виконує в одній взаємодії роль менеджера, може в іншій взаємодії виконувати роль агента, і навпаки.Стандарти OSI не визначають способів взаємодії агента з керованими об'єктами. Стандарти OSI також не говорять про те, як агент взаємодіє з керованими об'єктами, які перебувають за межами керованої системи, тобто об'єктами, з якими потрібно взаємодіяти через мережу. У таких випадках може знадобитися, наприклад, щоб один агент запросив дані про деякий об'єкт від іншого агента. Порядок такого роду взаємодії також не визначається стандартами OSI.<br /> <br /> Щоб менеджер і агент змогли взаємодіяти, кожен повинен мати певні відомості про один одного. Ці відомості модель OSI називає контекстом додатку (Application Context, AC). AC описує елементи прикладного рівня стека OSI, які використовуються агентами і менеджерами.<br /> <br /> ''ПРИМІТКА''. Необхідно зазначити, що стандарти управління OSI значною мірою орієнтовані на стек протоколів OSI (саме стек, а не модель OSI), так само як системи управління SNMP орієнтовані на роботу зі стеком TCP / IP.<br /> <br /> Прикладний рівень стека OSI включає кілька допоміжних служб загального призначення, які використовуються прикладними протоколами і клієнтськими програмами (в тому числі і додатками управління) для автоматизації найбільш часто виконуваних дій. Це не закінчені протоколи прикладного рівня, подібні протоколах ftp, telnet або NCP, за допомогою яких користувач мережі може виконати якусь корисну дію, а допоміжні системні функції, які допомагають розробнику прикладного протоколу або програми написати її компактно і ефективно. На прикладному рівні стека OSI існують наступні допоміжних служби:<br /> <br /> *ACSE (Association Control Service Element). Відповідає за встановлення з'єднань між додатками різних систем. З'єднання (сесія, сеанс) на прикладному рівні OSI носить назву асоціації. Асоціації бувають індивідуальними та груповими (shared).<br /> <br /> *RTSE (Reliable Transfer Service Element). Займається підтримкою відновлення діалогу, викликаного розривом нижележащих комунікаційних служб, в рамках асоціації.<br /> <br /> *ROSE (Remote Operations Service Element). Організовує виконання програмних функцій на віддалених машинах (аналог служби виклику віддалених процедур RPC).<br /> <br /> ====Управління системами, управління рівнем та операції рівня====<br /> <br /> Основна модель управління OSI включає: управління системами, управління N-рівнем і операції N-рівня. Це розбиття на три області зроблено для того, щоб врахувати всі можливі ситуації, що виникають при управлінні.<br /> <br /> Управління системами має справу з керованими об'єктами на всіх семи рівнях OSI, включаючи прикладний рівень. Воно засноване на надійній передачі з встановленням з'єднання керуючої інформації між кінцевими системами. Необхідно підкреслити, що модель управління OSI не дозволяє використання служб без встановлення з'єднання.<br /> <br /> Управління N-рівнем обмежено керованими об'єктами якогось певного рівня семирівневої моделі. Протокол управління використовує при цьому комунікаційні протоколи нижчих рівнів. Управління N-рівнем корисно, коли немає можливості використовувати всі семи рівнів OSI. У цьому випадку допускається користуватися протоколом управління N-рівня, який строго призначений для даного рівня. Прикладами рівневого протоколу управління є протоколи управління для локальних мереж, розроблені інститутом IEEE (SMT технології FDDI), які обмежені рівнями 1 і 2.<br /> <br /> Нарешті, операції N-рівня зводяться до моніторингу та управління на основі керуючої інформації, що міститься в комунікаційних протоколах тільки даного рівня. Наприклад, дані моніторингу мережі, що містяться в кадрах STM-n технології SDH, відносяться до операцій N-рівня, а саме фізичного рівня.<br /> Стандарти на управління N-рівнем і операції N-рівня не входять в набір стандартів управління OSI. Стандарти OSI розглядають лише управління системами за допомогою повного семирівневого стека.<br /> <br /> Основна модель управління системами передбачає виконання керуючих операцій і передачу повідомлень між одноранговими системами, що означає необов'язковість жорсткого розподілу ролей на керуючі та керовані системи. Ця модель полегшує реалізацію розподілених аспектів управління. З іншого боку, допускається реалізація однорангових систем як керуючих і керованих.<br /> <br /> ====Інформаційна модель управління====<br /> <br /> Керований об'єкт - це представлення OSI про ресурс з метою управління. Ресурс може бути описаний як керований об'єкт. Конкретний керований об'єкт - це екземпляр (instance) деякого класу керованих об'єктів. Модель управління OSI широко використовує об'єктно-орієнтований підхід. Клас керованих об'єктів - це набір властивостей, які можуть бути обов'язковими або умовними. За допомогою опису одного класу керованих об'єктів, наприклад комутаторів, можна створити інший клас керованих об'єктів, наприклад комутаторів, що підтримують техніку VLAN, успадкувавши всі властивості класу комутаторів, але додавши нові атрибути.<br /> <br /> Для управління ресурсами менеджер і агент повинні бути обізнані про деталі цих ресурсів. Деталізація представлення керованих об'єктів, які потрібні для виконання функцій управління, зберігається в репозиторії, відомому як Management Information Base (MIB). Бази MIB OSI зберігають не тільки описи класів керованих об'єктів, але й характеристики мережі та її елементів. Бази MIB містять характеристики кожної частини керованого обладнання і ресурсів. MIB також включає опис дій, які можуть виконуватися на основі зібраних даних або ж викликані зовнішніми командами. Бази MIB дозволяють зовнішнім системам опитувати, змінювати, створювати і видаляти керовані об'єкти (реальні ресурси мережі при цьому, природно, продовжують працювати). Протокол CMIP і локальні інтерфейси управління забезпечують доступ до цих можливостей.<br /> <br /> MIB - це концептуальна модель, і вона не має ніякого зв'язку зі способом фізичного або логічного зберігання даних в ресурсі. Стандарти не визначають аспекти власне зберігання даних. Протоколи OSI визначають синтаксис інформації, що зберігається в MIB, і семантику обміну даними.<br /> <br /> ====Протокол CMIP та послуги CMIS====<br /> <br /> Доступ до керуючої інформації, що зберігається в керованих об'єктах, забезпечується за допомогою елемента системи управління, званого службою CMSIE (Common Management Information Service Element). Служба CMSIE побудована в архітектурі розподіленого додатку, де частину функцій виконує менеджер, а частина - агент. Взаємодія між менеджером і агентом здійснюється по протоколу CMIP. Послуги, що надаються службою CMSIE, називаються послугами CMIS (Common Management Information Services).<br /> <br /> Протокол CMIP та послуги CMIS визначені в стандартах Х.710 і Х.711 ITU-T. Послуги CMIS поділяються на дві групи - послуги, що ініціюються менеджером (запити), та послуги, що ініціюються агентом (повідомлення).<br /> <br /> Послуги, що ініціюються менеджером, включають наступні операції:<br /> <br /> *M-CREATE інструктує агента про необхідність створити новий екземпляр об'єкту певного класу або новий атрибут усередині екземпляра об'єкта;<br /> <br /> *M-DELETE інструктує агента про необхідність видалення деякого екземпляра об'єкту певного класу або атрибуту усередині екземпляра об'єкта;<br /> <br /> *M-GET інструктує агента про повернення значення деякого атрибуту певного екземпляра об'єкту;<br /> <br /> *M-SET інструктує агента про зміну значення деякого атрибуту певного екземпляра об'єкту;<br /> <br /> *M-ACTION інструктує агента про необхідність виконання певної дії над одним або кількома примірниками об'єктів.<br /> <br /> Агент ініціює тільки одну операцію:<br /> M-EVENT_REPORT - відправка повідомлення менеджеру.<br /> <br /> Для реалізації своїх послуг служба CMISE повинна використовувати служби прикладного рівня стека OSI - ACSE, ROSE.<br /> <br /> Відмінність послуг CMIS від аналогічних послуг SNMP полягає в більшій гнучкості. Якщо запити GET і SET протоколу SNMP застосовні тільки до одного атрибуту одного об'єкта, то запити M-GET, M-SET, M-ACTION і M-DELETE можуть застосовуватися до більш ніж одного об'єкту. Для цього стандарти CMIP / CMIS вводять такі поняття, як огляд (scoping), фільтрація (filtering) і синхронізація (synchronization).<br /> <br /> == Вбудовані засоби моніторингу і аналізу мереж ==<br /> <br /> === Агенти [[SNMP]] ===<br /> <br /> На сьогоднішній день існує кілька стандартів на бази даних управляючої інформації. Основними є стандарти MIB-I і MIB-II, а також версія бази даних для віддаленого управління [[RMON MIB]]. Крім цього, існують стандарти для спеціальних [[MIB]] пристроїв конкретного типу, а також приватні [[MIB]] конкретних фірм-виробників обладнання.<br /> <br /> Початкова специфікація MIB-I визначала лише операції читання значень змінні величини. Операції зміни чи установки значень об'єкта є частиною специфікацій MIB-II.<br /> <br /> Версія MIB-I (RFC 1156) визначає до 114 об'єктів, які поділяються на 8 груп:<br /> <br /> * System - загальні дані про пристрій (наприклад, ідентифікатор постачальника, час останньої ініціалізації системи).<br /> <br /> * Interfaces - описуються параметри мережевих інтерфейсів пристрою (наприклад, їх кількість, типи, швидкості обміну, максимальний розмір пакету).<br /> <br /> * AddressTranslationTable - описується відповідність між мережевими і фізичними адресами (наприклад, за протоколом [[ARP]]).<br /> <br /> * [[IP|InternetProtocol]] - дані, що відносяться до протоколу IP (адреси IP-шлюзів, хостів, статистика про IP-пакети).<br /> <br /> * [[ICMP]] - дані, що пов'язані з протоколом обміну керуючими повідомленнями [[ICMP]].<br /> <br /> * [[TCP]] - дані, що належать до протоколу [[TCP]]. <br /> <br /> * [[UDP]] - дані, що належать до протоколу [[UDP]] (кількість переданих, прийнятих та помилкових UPD-дейтаграмм). <br /> <br /> * [[EGP]] - дані, що пов'язані з протоколом обміну маршрутною інформацією ExteriorGatewayProtocol, який використовується в мережі Internet (число прийнятих з помилками і без помилок повідомлень).<br /> <br /> З цього переліку груп змінних видно, що стандарт MIB-I розроблявся з жорсткою орієнтацією на управління маршрутизаторами, які підтримують протоколи стека TCP/IP.<br /> <br /> У версії MIB-II (RFC 1213), прийнятої в 1992 році, був істотно (до 185) розширено набір стандартних об'єктів, а кількість груп збільшилася до 10.<br /> <br /> У число об'єктів, що описують кожен конкретний інтерфейс пристрою, включені наступні:<br /> <br /> * IfType - тип протоколу, який підтримує інтерфейс. Цей об'єкт приймає значення всіх стандартних протоколів канального рівня, наприклад, rfc877-x25, ethernet-csmacd, iso88023-csmacd, iso88024-tokenBus, iso88025-tokenRing і т. д.<br /> <br /> * IfMtu - максимальний розмір пакета мережного рівня, який можна послати через цей інтерфейс.<br /> <br /> * IfSpeed - пропускна здатність інтерфейсу в бітах в секунду (100 для Fast Ethernet).<br /> <br /> * IfPhysAddress - фізичну адресу порту, для [[Fast Ethernet]] ним буде [[MAC]]-адреса.<br /> <br /> * IfAdminStatus - бажаний статус порту:<br /> <br /> :up - готовий передавати пакети;<br /> :down - не готовий передавати пакети;<br /> :testing - знаходиться в тестовому режимі.<br /> <br /> * IfOperStatus - фактичний поточний статус порту, має ті ж значення, що і ifAdminStatus.<br /> <br /> * IfInOctets - загальна кількість байт, прийняте даним портом, включаючи службові, з моменту останньої ініціалізації SNMP-агента.<br /> <br /> * IfInUcastPkts - кількість пакетів з індивідуальним адресою інтерфейсу, доставлених протоколу верхнього рівня.<br /> <br /> * IfInNUcastPkts - кількість пакетів з широкомовним або мультівещательнимі адресою інтерфейсу, доставлених протоколу верхнього рівня.<br /> <br /> * IfInDiscards - кількість пакетів, які були прийняті інтерфейсом, виявилися коректними, але не були доставлені протоколу верхнього рівня, швидше за все через переповнення буфера пакетів або ж з іншої причини.<br /> <br /> * IfInErrors - кількість пакетів, що прийшли, які не були передані протоколу верхнього рівня через виявлення в них помилок.<br /> <br /> Окрім об'єктів, що описують статистику за вхідними пакетів, є аналогічні об'єкти, пов'язані з вихідними пакетами. Як видно з опису об'єктів MIB-II, ця база даних не дає детальної статистики по характерних помилок кадрів [[Ethernet]], крім цього, вона не відображає зміну характеристик у часі, що часто цікавить мережевого адміністратора. Ці обмеження були згодом зняті новим стандартом на [[MIB]] - [[RMON MIB]], який спеціально орієнтований на збір детальної статистики по протоколу [[Ethernet]], до того ж з підтримкою такої важливої функції, як побудова агентом залежностей статистичних характеристик від часу.<br /> <br /> === Агенти [[RMON]] ===<br /> <br /> Нововведенням до функціональних можливостей SNMP є специфікація RMON, яка забезпечує віддалену взаємодію з базою MIB. До появи RMON протокол SNMP не міг використовуватися віддалено, він допускав лише локальне управління пристроями. База RMONMIB має поліпшений набір властивостей для віддаленого управління, оскільки містить агреговану інформацію про пристрій, що не вимагає передачі по мережі великих обсягів інформації. Об'єкти RMONMIB включають додаткові лічильники помилок в пакетах, гнучкіші засоби аналізу графічних трендів і статистики, більш потужні засоби фільтрації для захоплення і аналізу окремих пакетів, а також більш складні умови встановлення сигналів попередження. Агенти RMONMIB більш інтелектуальні порівняно з агентами MIB-I або MIB-II і виконують значну частину роботи по обробці інформації про пристрій, яку раніше виконували менеджери. Ці агенти можуть розташовуватися усередині різних комунікаційних пристроїв, а також бути виконані у вигляді окремих програмних модулів, що працюють на універсальних ПК і ноутбуках (прикладом може служити LANalyzerNovell). <br /> <br /> Об'єкту [[RMON]] присвоєно номер 16 в наборі об'єктів [[MIB]], а сам об'єкт [[RMON]] об'єднує 10 груп наступних об'єктів:<br /> <br /> * ''Statistics'' - поточні накопичені статистичні дані про характеристики пакетів, кількості колізій тощо. <br /> <br /> * ''History'' - статистичні дані, збережені через певні проміжки часу для подальшого аналізу тенденцій їх змін. <br /> <br /> * ''Alarms'' - порогові значення статистичних показників, при перевищенні яких агент RMON посилає повідомлення менеджеру.<br /> <br /> * ''Host'' - дані про хости мережі, у тому числі про їх [[MAC]]-адресах.<br /> <br /> * ''HostTopN'' - таблиця найбільш завантажених хостів мережі.<br /> <br /> * ''TrafficMatrix'' - статистика про інтенсивність трафіка між кожною парою хостів мережі.<br /> <br /> * ''Filter'' - умови фільтрації пакетів. <br /> <br /> * ''PacketCapture'' - умови захоплення пакетів. <br /> <br /> * ''Event'' - умови реєстрації і генерації подій.<br /> <br /> Дані групи пронумеровані у вказаному порядку, тому, наприклад, група Hosts має числове ім'я 1.3.6.1.2.1.16.4.<br /> <br /> Десяту групу складають спеціальні об'єкти протоколу TokenRing.<br /> <br /> Всього стандарт RMONMIB визначає близько 200 об'єктів в 10 групах, зафіксованих в двох документах - RFC 1271 для мереж Ethernet і RFC 1513 для мереж TokenRing.<br /> <br /> Відмінною рисою стандарту RMONMIB є його незалежність від протоколу мережевого рівня (на відміну від стандартів MIB-I і MIB-II, орієнтованих на протоколи TCP / IP). Тому, його зручно використовувати в гетерогенних середовищах, що використовують різні протоколи мережевого рівня.<br /> <br /> Розглянемо більш докладно групу Statistics, яка визначає, яку інформацію про кадри [[Ethernet]] може надати агент RMON.<br /> <br /> До групи Statistics входять наступні об'єкти:<br /> <br /> *''etherStatsDropEvents'' - загальне число подій, при яких пакети були проігноровані агентом через нестачу його ресурсів. Самі пакети при цьому не обов'язково були втрачені.<br /> <br /> *''etherStatsOrtets'' - загальне число байт (включаючи помилкові пакети), прийнятих з мережі (крім заголовка але з байтами контрольної суми).<br /> <br /> *''etherStatsPkts'' - загальне число отриманих пакетів (включаючи помилкові).<br /> <br /> *''etherStatsBroadcastPkts'' - загальне число хороших пакетів, які були надіслані широкомовною адресою.<br /> <br /> *''etherStatsMulticastPkts'' - загальне число хороших пакетів, отриманих за мультівещательнимі адресою.<br /> <br /> *''etherStatsCRCAlign Errors'' - загальне число отриманих пакетів, які мали довжину (виключаючи заголовок) між 64 і 1518 байт, не містили ціле число байт (alignment error) або мали невірну контрольну суму (FCS error).<br /> <br /> *''etherStatsUndersizePkts'' - загальне число пакетів, які мали довжину менше, ніж 64 байт, але були правильно сформовані.<br /> <br /> *''etherStatsOversizePkts'' - загальне число отриманих пакетів, які мали довжину більше, ніж 1518 байт, але були тим не менш правильно сформовані.<br /> <br /> *''etherStatsFragments'' - загальне число отриманих пакетів, які не складалися з цілого числа байт або мали невірну контрольну суму і мали до того ж довжину, меншу 64 байт.<br /> <br /> *''etherStatsJabbers'' - загальне число отриманих пакетів, які не складалися з цілого числа байт або мали невірну контрольну суму і мали до того ж довжину, більшу 1518 байт.<br /> <br /> *''etherStatsCollisions'' - найкраща оцінка числа колізій на даному сегменті Ethernet.<br /> <br /> *''etherStatsPkts640ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром 64 байт.<br /> <br /> *''etherStatsPkts65to1270ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 65 до 127 байт.<br /> <br /> *''etherStatsPktsl28to2550ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 128 до 255 байт.<br /> <br /> *''etherStatsPkts256to5110ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 256 до 511 байт.<br /> <br /> *''etherStatsPkts512tol0230ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 512 до 1023 байт.<br /> <br /> *''etherStatsPktsl024tol5180ctets'' - загальна кількість отриманих пакетів (включаючи погані) розміром від 1024 до 1518 байт.<br /> <br /> Як видно з опису об'єктів, за допомогою агента RMON, вбудованого в повторювач або інше комунікаційне обладнання, можна провести дуже детальний аналіз роботи сегмента Ethernet або Fast Ethernet. Спочатку можна отримати дані про типи помилок в кадрах, що зустрічаються в сегменті, а потім доцільно зібрати за допомогою группи History залежності інтенсивності цих помилок від часу (в тому числі і прив'язавши їх до часу). Після аналізу тимчасових залежностей часто вже можна зробити деякі попередні висновки про джерело помилкових кадрів і на цій підставі сформулювати більш тонкі умови захоплення кадрів зі специфічними ознаками (задавши умови в групі Filter). Після цього можна провести ще більш детальний аналіз за рахунок вивчення захоплених кадрів, витягуючи їх з об'єктів группи Packet Capture.<br /> <br /> Пізніше був прийнятий стандарт RMON 2, який поширює ідеї інтелектуальної RMON MIB на протоколи верхніх рівнів, виконуючи частину роботи аналізаторів протоколів.<br /> <br /> == Аналізатори протоколів ==<br /> <br /> У ході проектування нової або модернізації старої мережі часто виникає необхідність в кількісному вимірі деяких характеристик мережі таких, наприклад, як інтенсивності потоків даних по лініях зв'язку, затримки, що виникають на різних етапах обробки пакетів, часи реакції на запити того чи іншого виду, частота виникнення певних подій та інших характеристик.<br /> <br /> Для цих цілей можуть бути використані різні засоби і насамперед - засоби моніторингу в системах управління мережею, які вже обговорювалися в попередніх розділах. Деякі вимірювання мережі можуть бути виконані і вбудованими в операційну систему програмами.<br /> <br /> Але найбільш досконалим засобом дослідження мережі є аналізатор протоколів. Процес аналізу протоколів включає захоплення циркулюючих в мережі пакетів, що реалізують той чи інший мережевий протокол, і вивчення вмісту цих пакетів. Ґрунтуючись на результатах аналізу, можна здійснювати обґрунтовану і зважену зміну будь-якого компонента мережі, оптимізацію її продуктивності, пошук і усунення неполадок. Очевидно, що для того, щоб можна було зробити якісь висновки про вплив деякої зміни на мережу, необхідно виконати аналіз протоколів і до, і після внесення змін.<br /> <br /> Аналізатор протоколів є самостійним спеціалізованим пристроєм, або персональним комп'ютером, зазвичай переносним, класу Notebook, оснащений спеціальною мережевою картою і відповідним програмним забезпеченням. Мережева карта і програмне забезпечення, що використовуються повинні відповідати топології мережі (кільце, шина, зірка). Аналізатор підключається до мережі точно так, як і звичайний вузол. Відмінність полягає в тому, що аналізатор може приймати всі пакети даних, що передаються по мережі, в той час як звичайна станція - лише адресовані їй. Програмне забезпечення аналізатора складається з ядра, що підтримує роботу мережевого адаптера і декодує одержувані дані, та додаткового програмного коду, що залежить від типу топології досліджуваної мережі. Крім того, поставляється ряд процедур декодування, орієнтованих на певний протокол, наприклад, IPX. До складу деяких аналізаторів може входити також експертна система, яка може видавати користувачеві рекомендації про те, які експерименти слід проводити в даній ситуації, що можуть означати ті чи інші результати вимірювань, як усунути деякі види несправності мережі.<br /> <br /> Незважаючи на відносне різноманіття аналізаторів протоколів, представлених на ринку, можна назвати деякі риси, в тій чи іншій мірі притаманні всім їм:<br /> <br /> *''Інтерфейс користувача''. Більшість аналізаторів мають розвинений дружній інтерфейс, який базується, як правило, на Windows чи Motif. Цей інтерфейс дозволяє користувачеві: виводити результати аналізу інтенсивності трафіку; отримувати миттєву і середню статистичну оцінку продуктивності мережі; задавати певні події і критичні ситуації для відстежування їх виникнення; робити декодування протоколів різного рівня і представляти в зрозумілій формі вміст пакетів.<br /> <br /> *''Буфер захоплення''. Буфери різних аналізаторів відрізняються за обсягом. Буфер може розташовуватися на мережевій карті, або для нього може бути відведено місце в оперативній пам'яті одного з комп'ютерів мережі. Якщо буфер розташований на мережевій карті, то управління ним здійснюється апаратно, і за рахунок цього швидкість введення підвищується. Однак це призводить до подорожчання аналізатора. У разі недостатньої продуктивності процедури захоплення, частина інформації буде губитися, і аналіз буде неможливий. Розмір буфера визначає можливості аналізу по більш або менш представницьким вибіркам даних, що захоплюються. Але яким би великим не був буфер захоплення, рано чи пізно він заповниться. У цьому випадку або припиняється захоплення, або заповнення починається з початку буфера.<br /> <br /> *Можливість ''вимірювання середньостатистичних показників трафіку в сегменті локальної мережі'', в якому встановлений мережевий адаптер аналізатора.<br /> <br /> *Вимірюється коефіцієнт використання сегменту, матриці перехресного трафіку вузлів, кількість хороших і поганих кадрів, що пройшли через сегмент.<br /> <br /> *Можливість роботи з декількома агентами, котрі поставляють захоплені пакети з різних сегментів локальної мережі. Ці агенти найчастіше взаємодіють з аналізатором протоколів за власним протоколом прикладного рівня.<br /> <br /> *''Фільтри''. Фільтри дозволяють керувати процесом захоплення даних, і, тим самим, дозволяють економити простір буфера. Залежно від значення певних полів пакета, заданих у вигляді умови фільтрації, пакет або ігнорується, або записується в буфер захоплення. Використання фільтрів значно прискорює і спрощує аналіз, оскільки виключає перегляд непотрібних в даний момент пакетів.<br /> <br /> *''Перемикачі'' - це деякі умови початку і припинення процесу захоплення даних з мережі, що задаються користувачем. Такими умовами можуть бути виконання ручних команд запуску і зупинки процесу захоплення, тривалість процесу захоплення, поява певних значень в кадрах даних. Перемикачі можуть використовуватися спільно з фільтрами, дозволяючи більш детально й тонко проводити аналіз, а також продуктивніше використовувати обмежений обсяг буфера захоплення.<br /> <br /> *''Пошук''. Деякі аналізатори протоколів дозволяють автоматизувати перегляд інформації, що знаходиться в буфері, і знаходити в ній дані по заданим критеріям. У той час, як фільтри перевіряють вхідний потік на предмет відповідності умовам фільтрації, функції пошуку застосовуються до вже накопичених в буфері даних.<br /> <br /> *''Багатоканальність''. Деякі аналізатори протоколів дозволяють проводити одночасний запис пакетів від декількох мережевих адаптерів, що зручно для зіставлення процесів, що відбуваються в різних сегментах мережі. Можливості аналізу проблем мережі на фізичному рівні у аналізаторів протоколів мінімальні, оскільки всю інформацію вони отримують від стандартних мережевих адаптерів. Тому вони передають і узагальнюють інформацію фізичного рівня, яку повідомляє їм мережевий адаптер, а вона багато в чому залежить від типу мережного адаптера. Деякі мережні адаптери повідомляють більш детальні дані про помилки кадрів та інтенсивності колізій в сегменті, а деякі взагалі не передають таку інформацію верхнім рівням протоколів, на яких працює аналізатор протоколів.<br /> <br /> Методологія проведення аналізу може бути представлена у вигляді наступних шести етапів:<br /> <br /> *Захоплення даних.<br /> <br /> *Перегляд захоплених даних.<br /> <br /> *Аналіз даних.<br /> <br /> *Пошук помилок (більшість аналізаторів полегшують цю роботу, визначаючи типи помилок і ідентифікуючи станцію, від якої прийшов пакет з помилкою).<br /> <br /> *Дослідження продуктивності. Розраховується коефіцієнт використання пропускної здатності мережі або середній час реакції на запит.<br /> <br /> *Докладне дослідження окремих ділянок мережі. Зміст цього етапу конкретизується в міру того, як проводиться аналіз.<br /> <br /> Зазвичай процес аналізу протоколів займає відносно небагато часу - 1-2 робочих дні.<br /> <br /> == Обладнання для діагностики та сертифікації кабельних систем ==<br /> <br /> До обладнання даного класу відносяться мережеві аналізатори, прилади для сертифікації кабелів, кабельні сканери і тестери. Перш, ніж перейти до більш докладного огляду цих пристроїв, наведемо деякі необхідні відомості про основні електромагнітні характеристики кабельних систем.<br /> <br /> === Основні електромагнітні характеристики кабельних систем ===<br /> <br /> Основними електричними характеристиками, що впливають на роботу кабелю, є: затухання, імпеданс (хвильовий опір), перехресні наводки двох кручених пар і рівень зовнішнього електромагнітного випромінювання.<br /> <br /> ''Перехресні наводки між витими парами або NearEndCrosstalk (NEXT)'' - являють собою результат інтерференції електромагнітних сигналів, що виникають у двох кручених парах. Один з кабелів крученої пари передає сигнал, а другий - приймає. При проходженні сигналу по одному з кабелів, наприклад, по тому, що передає, у кабелі, що приймає сигнал виникають перехресні наводки. Величина NEXT залежить від частоти переданого сигналу - чим вище величина NEXT, тим краще (для категорії 5 NEXT повинен бути не менше 27 Дб при частоті 100 Мгц, для кабелю категорії 3 на частоті 10 МГц NEXT повинен бути не менше 26 Дб).<br /> <br /> ''Затухання (Attenuation)'' - являє собою втрату амплітуди електричного сигналу при його поширенні по кабелю. Затухання має два основних джерела: електричні характеристики кабелю і поверхневий ефект. Останній пояснює залежність затухання від частоти. Затухання вимірюється в децибелах на метр. Для кабелю категорії 5 при частоті 100 Мгц загасання не повинно перевищувати 23.6 Дб на 100 м, а для кабелю категорії 3, за стандартом IEEE 802.3 10BASE-T, допустима величина затухання на сегменті довжиною 100 м не повинна перевищувати 11,5 Дб при частоті змінного струму 10 МГц.<br /> <br /> ''Імпеданс (хвильовий опір)'' - це повний (активне і реактивне) опір в електричному ланцюзі. Імпеданс вимірюється в омах і є відносно постійною величиною для кабельних систем. Для неекранованої крученої пари найбільш часті значення імпедансу - 100 і 120 Ом. Характерні значення імпедансу для мереж стандарту Ethernet на коаксіальному кабелі становлять 50 Ом, а для мереж стандарту Arcnet - 93 Ом. Різкі зміни імпедансу по довжині кабелю можуть викликати процеси внутрішнього відображення, що призводять до виникнення стоячих хвиль. Стояча хвиля — тип коливань у неперервному середовищі, при яких кожна точка середовища здійснює періодичний рух зі сталою амплітудою, залежною від її положення. Стоячі хвилі не переносять енергію. Робоча станція, підключена до кабелю у районі вузла стоячої хвилі, не зможе отримувати адресовані їй повідомлення.<br /> <br /> ''Активний опір'' - це опір постійному струму в електричному ланцюзі. На відміну від імпедансу активний опір не залежить від частоти і зростає зі збільшенням довжини кабелю. Для неекранованої крученої пари категорії 5 активний опір не повинен перевищувати 9.4 Ом на 100 м.<br /> <br /> ''Ємність'' - це властивість металевих провідників накопичувати енергію. Два електричних провідника в кабелі, розділені діелектриком, являють собою конденсатор, здатний накопичувати заряд. Ємність є небажаною величиною, тому її слід робити якомога менше. Високе значення ємності в кабелі приводить до спотворення сигналу і обмежує смугу пропускання лінії. Для кабельних систем категорії 5 значення ємності не повинен перевищувати 5.6нФ на 100 м.<br /> <br /> ''Рівень зовнішнього електромагнітного випромінювання, або електричний шум'' - це небажана зміна напруги в провіднику. Електричний шум буває двох типів: фоновий і імпульсний. Електричний шум можна також розділити на низько-, середньо-і високочастотний. Джерелами фонового електричного шуму є в діапазоні до 150 КГц лінії електропередачі, телефони і лампи денного світла; в діапазоні від 150 КГц до 20 Мгц комп'ютери, принтери, ксерокси; в діапазоні від 20 МГц до 1 ГГц – теле- і радіопередавачі, мікрохвильові печі. Основними джерелами імпульсного електричного шуму є мотори, перемикачі і зварювальні агрегати. Електричний шум вимірюється в мВ. Кабельні системи на крученій парі не сильно схильні до впливу електричного шуму (на відміну від впливу NEXT).<br /> <br /> ===Мережеві аналізатори===<br /> <br /> Мережеві аналізатори (не слід плутати їх з аналізаторами протоколів) являють собою еталонні вимірювальні інструменти для діагностики та сертифікації кабелів і кабельних систем. Як приклад можна привести мережеві аналізатори компанії HewlettPackard - HP 4195A і HP 8510C.<br /> Мережеві аналізатори містять високоточний частотний генератор і вузькосмуговий приймач. Передаючи сигнали різних частот в передавальну пару і вимірюючи сигнал у приймальній парі, можна виміряти затухання і NEXT. Мережеві аналізатори - це великогабаритні і дорогі прилади, призначені для використання в лабораторних умовах спеціально навченим технічним персоналом.<br /> <br /> ===Кабельні сканери===<br /> <br /> Дані прилади дозволяють визначити довжину кабелю, NEXT, затухання, імпеданс, схему розводки, рівень електричних шумів і провести оцінку отриманих результатів. Існує досить багато пристроїв даного класу, наприклад, сканери компаній MicrotestInc., FlukeCorp., DatacomTechnologiesInc., ScopeCommunicationInc. На відміну від мережевих аналізаторів сканери можуть бути використані не тільки спеціально навченим технічним персоналом, але навіть адміністраторами-новачками.<br /> <br /> Для визначення місця розташування несправності кабельної системи (обриву, короткого замикання, неправильно встановленого роз'єму і т.д.) використовується метод &quot;кабельного радара&quot;, або TimeDomainReflectometry (TDR). Суть цього методу полягає в тому, що сканер випромінює в кабель короткий електричний імпульс і вимірює час затримки до приходу відбитого сигналу. За полярності відображеного імпульсу визначається характер пошкодження кабелю (коротке замикання або обрив). У правильно встановленому і підключеному кабелі відбитий імпульс зовсім відсутній.<br /> <br /> Точність вимірювання відстані залежить від того, наскільки точно відома швидкість розповсюдження електромагнітних хвиль у кабелі. У різних кабелях вона буде різною. Швидкість розповсюдження електромагнітних хвиль у кабелі (NVP) зазвичай задається у відсотках до швидкості світла у вакуумі. Сучасні сканери містять в собі електронну таблицю даних про NVP для всіх основних типів кабелів і дозволяють користувачеві встановлювати ці параметри самостійно після попереднього калібрування.<br /> <br /> Найбільш відомими виробниками компактних кабельних сканерів є компанії MicrotestInc., WaveTekCorp., ScopeCommunicationInc.<br /> <br /> ===Тестери===<br /> <br /> Тестери кабельних систем - найбільш прості і дешеві прилади для діагностики кабелю. Вони дозволяють визначити пошкодження кабеля, проте, на відміну від кабельних сканерів, не дають відповіді на питання про те, в якому місці стався збій.<br /> <br /> <br /> Перейти до [[Засоби аналізу та оптимізації мереж]]<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/SNMP 2011-12-18T14:54:26Z

<p>Aleksey: </p> <hr /> <div>'''SNMP''' (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури [[TCP/IP]].<br /> <br /> ==Історія створення SNMP==<br /> <br /> Однією з найперших ініціатив з управління мережами була ініціатива ISO Open Systems Interconnection (OSI). Відповідні групи з стандартизації інфраструктури управління OSI (OSI Management Framework) були створені в 1981 році.<br /> <br /> До кінця 1980-х років мережа Інтернет стала досить великою і вимагала стандартів управління. Однак група ISO OSI була далека від завершення робіт над сімейством стандартів. Тому в 1987 році спільнотою IETF було прийнято рішення тимчасово створити набір спрощених стандартів управління в Інтернеті на основі напрацювань ISO OSI. Дані стандарти отримали назву Simple Network Management Protocol (SNMP). Надалі передбачалося перейти на стандарти ISO у міру їх готовності. Таким чином, багато ідей SNMP були взяті зі стандартів ISO:<br /> <br /> *Концепція «менеджер-агент»;<br /> <br /> *Ідея баз керуючої інформації (Management Information Bases, MIBs);<br /> <br /> *Використання синтаксису Abstract Syntax Notation One (ASN.1);<br /> <br /> *Частина термінології;<br /> <br /> Іншими проектом стандарту, на базі якого почалася розробка SNMP, був проект простого протоколу моніторингу шлюзів (Simple Gateway Monitoring Protocol, SGMP) співтовариства IETF.<br /> <br /> Надалі в рамках ISO OSI було запропоновано багато нових ідей, зокрема, об'єктно-орієнтований підхід. Однак ці ідеї вже не ввійшли в стандарти SNMP. Один час IETF продовжувала CMIP over TCP (CMOT), яка передбачала використання загального протоколу керуючої інформації (Common Management Information Protocol, CMIP) стека протоколів ISO OSI в стеку IETF TCP / IP. У 1992 році ця ініціатива була припинена у зв'язку з успіхом і поширеністю SNMP.<br /> <br /> Після багатьох засідань IAB (Internet Architecture Board) опублікував у квітні 1988 року епохальний RFC 1052: IAB Recommendations for the Development of Internet Network Management Standards, в якому закликав до якнайшвидшого створення елементів Простого Мережевого Управління (Simple Network Management).<br /> <br /> Багато ідей, що лежать сьогодні в основі SNMP, були запозичені у попередніх дослідженнях з моніторингу Internet-маршрутизаторів. І вже в серпні 1988 з'явилися три основні документа:<br /> <br /> *[http://tools.ietf.org/html/rfc1065 RFC 1065]: Structure and Identification of Management Information for TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]: Management Information Base for Network Management of TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]: A Simple Network Management Protocol.<br /> <br /> Згодом ці документи було перевидано і доповнено до визначення наступного покоління SNMP: RFC 1155, 1156 і 1157, які в свою чергу, також піддалися переробкам.<br /> <br /> Зрештою, у травні 1991 року була закінчена робота зі створення першої версії протоколу SNMPv1, яка знайшла своє відображення в зведенні таких документів:<br /> <br /> *[http://tools.ietf.org/html/rfc1155 RFC 1155]: Structure and Identification of Management Information for TCP / IP-based internets (Травень, 1990):<br /> - Визначає структуру керуючої інформації у вигляді глобального дерева.<br /> - Являє синтаксис визначення імен змінних управління.<br /> <br /> *[http://tools.ietf.org/html/rfc1212 RFC 1212]: Concise MIB Definitions (Березень, 1991)<br /> - Доповнює RFC 1155 в частині синтаксису визначення імен змінних.<br /> <br /> *[http://tools.ietf.org/html/rfc1213 RFC 1213]: Management Information Base for Network Management of TCP / IP-based internets: MIB-II (Березень, 1991):<br /> - Містить список більше ста найбільш необхідних змінних, що відповідають за конфігурацію, статус і статистику систем, що входять в TCP / IP мережі.<br /> <br /> *[http://tools.ietf.org/html/rfc1157 RFC 1157]: A Simple Network Management Protocol (SNMP) (Травень, 1990)<br /> - Визначає повідомлення, якими обмінюються керуюча станція і об'єкт управління для отримання та оновлення значення змінних.<br /> - Визначає trap (alarm)-повідомлення, що посилаються системою при значних змінах у її конфігурації.<br /> <br /> Опублікування цих стандартів стало поштовхом для виробників мережного обладнання, які розгорнули широкі роботи із забезпечення керованості:<br /> <br /> *всього спектра мережного обладнання - мостів, маршрутизаторів, модемів ...<br /> <br /> *широкого кола інтерфейсів - Point-to-Point, DS1, DS3, X.25, Frame Relay, Ethernet, Token Ring, FDDI, та ін.<br /> <br /> В загальному, стандарти SNMP продовжували розвиватися протягом 1990-х років. Основним напрямком розвитку було вдосконалення питань безпеки. Були розроблені наступні версії SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u і SNMPv3. Їх обговорення буде продовжено в розділі «Версії SNMP».<br /> <br /> ==Задачі==<br /> <br /> Сімейство стандартів SNMP створено для вирішення задач обробки помилок і аналізу продуктивності і надійності.<br /> <br /> '''Обробка помилок'''<br /> <br /> Виявлення, визначення і усунення наслідків збоїв і відмов у роботі мережі. На цьому рівні виконується реєстрація повідомлень про помилки, їх фільтрація, маршрутизація і аналіз на основі деякої кореляційної моделі.<br /> <br /> '''Аналіз продуктивності і надійності'''<br /> <br /> Оцінка на основі статистичної інформації таких параметрів, як час реакції системи, пропускна спроможність каналів зв'язку, інтенсивність трафіку в окремих сегментах мережі, імовірність спотворення даних, коефіцієнт готовності служб мережі. Результати такого аналізу дозволяють контролювати угоду про рівень обслуговування (Service Level Agreement, SLA).<br /> <br /> Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:<br /> <br /> *Широка сфера застосування. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;<br /> <br /> *Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;<br /> <br /> *Стійкість у критичних ситуаціях. Наприклад, при перевантаженні і проблемах в мережі, тобто при множинних помилках.<br /> <br /> ==Архітектура==<br /> <br /> Архітектуру розподіленої системи можна описати в термінах обробних елементів (або компонентів), що з'єднують елементів (або з'єднувачів) і елементів даних. Перерахуємо складові елементи системи управління SNMP:<br /> <br /> 1. компоненти:<br /> <br /> *агент;<br /> <br /> *менеджер;<br /> <br /> 2. з'єднувачі:<br /> <br /> *транспортний протокол;<br /> <br /> *Протокольні блоки даних (Protocol Data Units, PDU) і повідомлення SNMP;<br /> <br /> 3. дані:<br /> <br /> *Керуюча інформація MIB;<br /> <br /> Опишемо детальніше і проаналізуємо архітектуру SNMP з позиції досягнення поставлених перед SNMP цілей. Для цього використовуємо поняття архітектурного стилю мережевого програмного забезпечення. Архітектурний стиль - це узгоджений набір архітектурних обмежень, накладених на ролі і особливості архітектурних елементів (компонентів, з'єднувачів і даних) і відносин між ними, яка проявляється у будь-якій архітектурі, і яка задовольняє цьому стилю.<br /> <br /> ===Компоненти===<br /> <br /> Архітектура SNMP передбачає побудову системи управління за схемою «менеджер-агент», тобто використання архітектурного стилю «клієнт-сервер». Система SNMP містить безліч керованих вузлів, на кожному з яких розміщується досить простий сервер - агент SNMP, а також, принаймні, один вузол, що містить складного клієнта - менеджера SNMP.<br /> <br /> Менеджер взаємодіє з агентами за допомогою протоколу SNMP з метою обміну керуючою інформацією. В основному, ця взаємодія реалізується у вигляді періодичного опитування менеджером множини агентів, так як агенти всього лише надають доступ до інформації, але не знають, що їм з нею робити. Видно, що система, побудована за такими принципами, втрачає масштабованость, оскільки є виділений клієнт, який займається опитуванням всіх серверів. Зате така схема забезпечує простоту реалізації систем під управлінням SNMP.<br /> <br /> Для підвищення масштабованості та адміністративної керованості вводиться поняття проксі-агента, який може переправляти операції протоколу SNMP, а також поняття менеджера проміжного рівня, який приховує несуттєві подробиці керуючої інформації від систем управління мережами верхнього рівня, інтегруючи одержувані від агентів дані. Це дозволяє створювати багаторівневі системи управління, що відповідають архітектурному стилю «багаторівневий клієнт-сервер».<br /> <br /> Більш детальна класифікація компонентів за ролями:<br /> <br /> 1. Менеджер:<br /> <br /> *Менеджер проміжного рівня;<br /> <br /> *Система управління мережами;<br /> <br /> 2. Агент:<br /> <br /> * Мінімальний агент;<br /> <br /> * Проксі-агент;<br /> <br /> Компоненти в SNMP узагальнено називаються сутностями SNMP.<br /> <br /> ===Дані===<br /> <br /> Тепер розглянемо дані, якими маніпулюють системи SNMP, тобто керуючу інформацію. У SNMP кожний керований пристрій, на якому розташований агент, представляє свою керуючу інформацію у вигляді змінних. Такими змінними можуть бути, наприклад, ім'я системи, час з моменту її перезапуску, записи в таблиці маршрутизації і т. д. В загальному випадку змінні можна розділити на:<br /> <br /> *Скалярні змінні;<br /> <br /> *Таблиці змінних;<br /> <br /> Схема даних описується структурою керуючої інформації (Structure of Management Information, SMI). Схема даних визначає, як виглядає керуюча інформація, тобто описує її синтаксис. SMI базується на Abstract Syntax Notation One (ASN.1).<br /> <br /> Конкретні набори керуючої інформації для різних типів пристроїв, протоколів і т. д. описуються базами керуючої інформації (Management Information Bases, MIBs). Бази MIB визначають, яка управляюча інформація існує. Наприклад, для пристрою, що підтримує IP, MIB описує таблицю маршрутизації, прапорець активації функції маршрутизації, число переданих і прийнятих пакетів, число помилок різного характеру і т. д.<br /> <br /> Таким чином, кожен пристрій містить набір значень змінних, визначених у деякій кількості MIB, описаних за правилами SMI. Цей набір змінних і є даними, що управляє інформацією для протоколу SNMP.<br /> <br /> Важливим питанням є іменування змінних. У SNMP кожній змінній присвоюється унікальний ідентифікатор об'єкта (Object Identifier, OID). Простір імен OID є ієрархічним і контролюється організацією по розподілу номерів в Інтернеті (Internet Assigned Numbers Authority, IANA). Кожен компонент імені є числом. В текстовому вигляді імена записуються як десяткові числа, розділені крапками, зліва направо. Числам можуть бути поставлені у відповідність текстові рядки для зручності сприйняття. У цілому, структура імені схожа на систему доменних імен Інтернету (Domain Name System, DNS).<br /> <br /> Кожна MIB визначає набір змінних, тобто певну гілку дерева OID, що описує керуючу інформацію в певній галузі. Наприклад, гілка 1.3.6.1.2.1.1 (мнемонічний еквівалент: iso.org.dod.internet.mgmt.mib-2.system) описує загальну інформацію про систему. Опишемо деякі змінні з цієї гілки:<br /> <br /> *sysDescr (1.3.6.1.2.1.1.1) - короткий опис системи;<br /> <br /> *sysUpTime (1.3.6.1.2.1.1.3) - час з моменту останнього перезапуску;<br /> <br /> *sysName (1.3.6.1.2.1.1.5) - назва системи.<br /> <br /> Змінні і відомості про їхній тип визначені також в MIB. А самі типи змінних - в SMI.<br /> <br /> Крім безпосередньо даних, необхідно ввести операції над ними. Набір цих операцій змінювався і розширювався в міру розвитку SNMP. Основними операціями є:<br /> <br /> *Читання змінної;<br /> <br /> *Запис змінної;<br /> <br /> *Читання змінної, наступної за заданою змінною (необхідне для перегляду таблиць змінних);<br /> <br /> Більш докладно операції над даними описані нижче при обговоренні з'єднувачів в архітектурі SNMP.<br /> <br /> В цілому, операції над даними в SNMP схожі на віддалене налагодження деякої програми: стан системи описується певним набором змінних, які можна переглядати і змінювати.<br /> <br /> ===З'єднувачі===<br /> <br /> Для обміну даними між компонентами використовуються з'єднувачі. У разі SNMP в якості з'єднувача використовується протокол прикладного рівня Simple Network Management Protocol (SNMP), що звичайно працює поверх стека протоколів TCP / IP.<br /> <br /> Розглянемо стек протоколів більш докладно, вказавши прив'язку протоколів до Open Systems Interconnection Reference Model (OSI RM).<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;№&lt;/td&gt;<br /> &lt;td&gt;Протокол&lt;/td&gt;<br /> &lt;td&gt;Коментарі&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;7&lt;/td&gt;<br /> &lt;td&gt;SNMP&lt;/td&gt;<br /> &lt;td&gt;Повідомлення, PDU, операції&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;6&lt;/td&gt;<br /> &lt;td&gt;ASN.1 BER&lt;/td&gt;<br /> &lt;td&gt;Кодування даних&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;5&lt;/td&gt;<br /> &lt;td&gt;-&lt;/td&gt;<br /> &lt;td&gt;-&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;4&lt;/td&gt;<br /> &lt;td&gt;UDP&lt;/td&gt;<br /> &lt;td&gt;Транспорт між службами&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;3&lt;/td&gt;<br /> &lt;td&gt;IP&lt;/td&gt;<br /> &lt;td&gt;Зв'язок між вузлами мережі&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> SNMP вводить свій протокол прикладного рівня. Є чотири версії даного протоколу: SNMPv1, SNMPv2, SNMPv2c і SNMPv3. У процесі розвитку SNMP розширювалися можливі операції, тобто типи протокольних блоків даних (Protocol Data Units, PDUs), а також вводилися нові формати повідомлень SNMP для забезпечення безпеки.<br /> <br /> Повідомлення SNMP містить номер версії SNMP, інформацію про безпеку та протокольний блок даних PDU, який характеризує виконувану операцію і її параметри. Наприклад, SNMPv1 описує наступні PDU і відповідні операції:<br /> <br /> *Get-Request - запит на отримання значень 1 .. N змінних;<br /> <br /> *Get-Next-Request - запит на отримання значень 1 .. N змінних, чиї OID йдуть слідом за OID зазначених 1 .. N змінних;<br /> <br /> *Get-Response - відповідь на запити Get-Request, Get-Next-Request і Set-Request;<br /> <br /> *Set-Request - установка значень 1 .. N змінних;<br /> <br /> *Trap - пастка (див. нижче);<br /> <br /> SNMP - це протокол типу &quot;запит-відповідь&quot;, тобто на кожен запит, що надійшов від менеджера, агент повинен передати відповідь.<br /> <br /> [[Файл:ZaprOtv.gif]]<br /> <br /> Описані PDU, як уже згадувалося, є частиною повідомлення SNMP. Повідомлення кодуються для передачі по мережі за допомогою ASN.1 Basic Encoding Rules (BER). Це функція шостого рівня (рівня подання) еталонної моделі OSI. Далі закодовані повідомлення відправляються одним компонентом SNMP іншого за допомогою транспортного протоколу.<br /> <br /> Як вже зазначалося, стандарт передбачає використання різного транспорту для SNMP, але майже завжди використовується протокол користувацьких датаграм (User Datagram Protocol, UDP). Агенти використовують добре відомий порт UDP 161. Цей протокол надає мінімальні транспортні послуги (доставка повідомлень від служби до служби і перевірка контрольної суми) і не передбачає організацію сеансів і потокову передачу даних, як Transmission Control Protocol (TCP). За рахунок цього вдається домогтися великої швидкості реакції і швидкодії, що відповідає поставленим перед SNMP цілям.<br /> <br /> Для підвищення швидкості реакції менеджера на термінові події вводиться спеціальний тип операції протоколу SNMP, так звана «пастка» (Trap). Він дозволяє агентам асинхронно інформувати менеджера (за власною ініціативою) про настання обмеженого числа значущих подій. У цьому випадку агент виступає в незвичній для себе ролі клієнта, а менеджер - в ролі сервера. У разі використання транспорту UDP для вхідних з'єднань менеджер використовує добре відомий порт UDP 162.<br /> <br /> Як ми бачимо, жодна з цих операцій не припускає, що агент зберігає інформацію про сесії з менеджером. Для виконання операції Trap така інформація зберігається статично, тобто сесія в такому випадку статична і перманентна. Крім цього операції SNMP визначають єдині, уніфіковані інтерфейси агентів і менеджерів SNMP. Таким чином, SNMP - це протокол без збереження стану, який відповідає архітектурному стилю «уніфікований багаторівневий клієнт-сервер без збереження стану».<br /> <br /> Опишемо деякі властивості операцій SNMP на прикладі SNMPv1:<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Ім'я&lt;/td&gt;<br /> &lt;td&gt;Безпека&lt;/td&gt;<br /> &lt;td&gt;Підтвердження&lt;/td&gt;<br /> &lt;td&gt;Ідемпотентність&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Request&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Next-Request&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Response&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Set-Request&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Trap&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> Таким чином, ми розглянули всі основні архітектурні особливості SNMP, крім моделей безпеки. Питання, пов'язані із захистом інформації, будуть розглянуті нижче при обговоренні версій стандартів SNMP.<br /> <br /> ==Відповідність архітектурному стилю REST==<br /> <br /> Архітектурний стиль REST - це уніфікований багаторівневий клієнт-серверний стиль, з кодом за запитом та без збереження стану (Unified-Layered-Code-on-Demand-Client-Cached-Stateless-Server, ULCODCСSS). Як ми визначили в результаті аналізу архітектури SNMP, система SNMP визначається уніфікованим багаторівневим клієнт-серверних стилем без збереження стану (Unified-Layered-Client-Stateless-Server, ULCSS).<br /> <br /> Як ми бачимо, на SNMP не накладаються обмеження, пов'язані з реплікацією (наявність кеша) і мобільним кодом (застосування коду за вимогою). У цьому сенсі стиль SNMP - більш вільний, ніж REST, тобто містить менше архітектурних особливостей, які, наприклад, необхідно враховувати при моделюванні систем з такою архітектурою.<br /> <br /> Однак, навіть у SNMPv1 є особлива операція Trap, що ініціюється агентом асинхронно по відношенню до менеджера. У SNMPv2 вводиться операція Inform-Request, яка також виконується асинхронно, але між двома менеджерами. При виконанні таких операцій клієнт і сервер міняються ролями. При цьому використовується принцип інтеграції на основі повідомлень. Це елементи однорангового стилю взаємодії (Peer-to-Peer), хоча в даному випадку ролі клієнта і сервера для конкретних типів протокольних операцій виражені явно. У цьому сенсі стиль SNMP - більш обмежений, ніж REST.<br /> <br /> Таким чином, при певних обмеженнях система SNMP може бути розглянута як REST-івська розподілена система.<br /> <br /> ==Структура стандартів==<br /> <br /> Стандарти SNMP описують аспекти, відображені нижче:<br /> <br /> 1. Загальна інформація;<br /> <br /> 2. Обробка повідомлень (SNMP Messages):<br /> <br /> *Прив'язки до транспорту;<br /> <br /> *Розбір і диспетчеризація повідомлень;<br /> <br /> *Безпека (аутентифікація, шифрування, своєчасність);<br /> <br /> 3. Обробка протокольних блоків даних (SNMP PDUs):<br /> <br /> *Операції протоколу;<br /> <br /> *Програми SNMP;<br /> <br /> *Управління доступом;<br /> <br /> 4. Інформаційна модель:<br /> <br /> *Структура керуючої інформації (SMI);<br /> <br /> *Текстові конвенції;<br /> <br /> *Вирази відповідності;<br /> <br /> 5. Модулі баз керуючої інформації (MIB);<br /> <br /> Спочатку в стандартах виділялися не всі ці аспекти. Проте, структура стандартів SNMP всіх версій вписується в цю схему.<br /> <br /> ==Інформаційна безпека==<br /> <br /> Розглянемо, як враховуються в SNMP основні елементи інформаційної безпеки:<br /> <br /> *Конфіденційність;<br /> <br /> *Цілісність;<br /> <br /> *Доступність;<br /> <br /> *Контрольованість;<br /> <br /> У ході розвитку стандартів SNMP інфраструктура безпеки піддавалася найбільших змін. Для того, щоб простежити ці зміни, спочатку опишемо вимоги безпеки та загрози, потім структуру моделей безпеки, після чого розглянемо використання в різних версіях SNMP моделі.<br /> <br /> ===Вимоги та загрози безпеці===<br /> <br /> Опишемо вимоги безпеки в архітектурі SNMP. Загрозами безпеці, проти яких повинна надавати захист будь-яка модель безпеки SNMP, є:<br /> <br /> 1. Первинні загрози:<br /> <br /> *Модифікація інформації;<br /> <br /> *Маскарад;<br /> <br /> 2. Вторинні загрози:<br /> <br /> *Модифікація потоку повідомлень;<br /> <br /> *Розголошення;<br /> <br /> Загроза модифікації інформації - це можливість того, що деяка неавторизована сутність може змінити повідомлення SNMP, згенеровані за запитом авторизованого принципала, на шляху їх слідування таким чином, що це призведе до неавторизованих операцій управління, включаючи фальсифікацію значення об'єкта (змінної).<br /> <br /> Загроза маскараду - це можливість того, що операції управління, не авторизовані для деякого принципала, можуть бути виконані при підстановці ідентифікатора іншого принципала, для якого подібні дії авторизовані.<br /> <br /> Загроза модифікації потоку повідомлень полягає в наступному. Протокол SNMP звичайно що грунтується на транспортній службі без організації з'єднання. Перестановка, затримка або повторна посилка повідомлень може відбуватися і відбувається в ході звичайної експлуатації мереж із застосуванням таких протоколів. Загроза модифікацій потоку повідомлень - це можливість того, що повідомлення можуть бути переставлені, затримані чи повторно надіслані зі злим умислом із затримками, які перевищують наявне місце затримки при нормальній експлуатації, з метою виконання неавторизованих операцій управління.<br /> <br /> Загроза розголошення - це можливість прослуховування обмінів повідомленнями між сутностями SNMP. Захист від цієї загрози може вимагати локальної політики безпеки.<br /> <br /> Модель безпеки може не боротися з такими загрозами, як, наприклад, відмова в обслуговуванні, оскільки стан мережевих збоїв і помилок (нормальне для SNMP) часто не відрізняються від ситуацій відмови в обслуговуванні.<br /> <br /> Як ми побачимо нижче, на практиці не кожна модель безпеки SNMP задовольняє вимогам нейтралізації перерахованих загроз.<br /> <br /> ===Структура моделей безпеки===<br /> <br /> Сутність SNMP містить дві підсистеми:<br /> <br /> *Підсистема безпеки;<br /> <br /> *Підсистема управління доступом;<br /> <br /> Підсистема безпеки функціонує на рівні повідомлень SNMP. Вона відповідає за аутентифікацію, шифрування і своєчасність. Документ з безпеки описує модель безпеки, загрози, проти яких вона захищає, цілі моделі безпеки, протоколи, використовувані для досягнення цих цілей, модуль MIB, що описує відповідні структури даних. Такий модуль потрібний у тому числі і для того, щоб віддалено конфігурувати параметри безпеки рівня повідомлень SNMP.<br /> <br /> Підсистема управління доступом функціонує на рівні SNMP PDU. Очевидно, що вона відповідає за управління доступом до керованих об'єктів (змінних). Документи, що описують її, також визначають модуль MIB для віддаленого налаштування параметрів.<br /> <br /> ===Моделі безпеки===<br /> <br /> Перелічимо основні моделі безпеки та відповідні їм інфраструктури:<br /> 1. SNMPv1:<br /> <br /> *SNMPv1 - Community-based Security Model;<br /> <br /> 2. SNMPv2:<br /> <br /> *SNMPv2p - Party-based Security Model;<br /> <br /> *SNMPv2c - Community-based Security Model;<br /> <br /> *SNMPv2u - User-based Security Model;<br /> <br /> 3. SNMPv3<br /> <br /> *SNMPv3 USM User-based Security Model.<br /> <br /> Модель безпеки на основі спільнот (Community-based Security Model) була першою, найпростішою і найбезпечнішою. Вона полягає лише у аутентифікації на основі «рядка спільноти», фактично, пароля, переданого по мережі в тексті повідомлення SNMP у відкритому вигляді. Ця модель безпеки не в змозі боротися ні з однією із загроз інформаційної безпеки в SNMP. Тим не менш, вона часто використовується до цих пір у зв'язку зі своєю простотою, а також завдяки наявності зовнішніх, не пов'язаних з SNMP систем безпеки, наприклад, міжмережевих екранів.<br /> <br /> Модель безпеки на основі сторін (Party-based Security Model) передбачає введення поняття сторони. Сторона - це віртуальне оточення виконання, в якому набір допустимих операцій обмежений адміністративно. Сутність SNMP при обробці повідомлення діє як сторона, тому обмежена операціями, визначеними для цієї сторони. Сторона визначається наступними параметрами:<br /> <br /> *Унікальний ідентифікатор сторони;<br /> <br /> *Логічна мережева адреса (область адрес транспортного протоколу та адреса транспортного протоколу);<br /> <br /> *Протокол аутентифікації і параметри, що вимагаються для аутентифікації всіх повідомлень сторони;<br /> <br /> *Протокол шифрування і параметри, потрібні для шифрування всіх повідомлень сторони;<br /> <br /> Можуть використовуватися різні алгоритми для протоколів аутентифікації і шифрування. Звичайно як алгоритму для протоколу аутентифікації використовують хеш-функцію Message Digest 5 (MD5), а для протоколу шифрування - алгоритм Data Encryption Standard (DES) в режимі Cipher Block Chaining (CBC).<br /> <br /> Запроваджуються й інші поняття, що використовуються для реалізації цієї моделі. Проте тут вони докладно не розглядаються, так само як і деталі функціонування моделі. Зазначимо лише, що при використанні відповідних протоколів аутентифікації і шифрування модель успішно справляється з описаними вище загрозами безпеці SNMP. Дана модель безпеки не була широко прийнята, оскільки є занадто складною і заплутаною.<br /> <br /> Модель безпеки на основі користувачів (User-based Security Model) вводить поняття користувача, від імені якого діє сутність SNMP. Цей користувач характеризується ім'ям користувача, використовуваними протоколами аутентифікації і шифрування, а також закритим ключем аутентифікації і шифрування. Аутентифікація і шифрування є необов'язковими. Їх наявність описується одним з параметрів моделі, якістю обслуговування (Quality of Service, QoS). Модель безпеки багато в чому схожа на модель сторін, але вона спрощує ідентифікацію користувачів, розподіл ключів і протокольні операції.<br /> <br /> ==Версії SNMP==<br /> <br /> Коротко опишемо відмінності між версіями SNMP і документи, що визначають ці версії. Зауважимо, що тут наведено перші версії RFC кожної з версій SNMP, тобто майже всі з них були заміщені новішими RFC і визнані застарілими. На даний момент єдиною не застарілою версією SNMP є SNMPv3, визначена в RFC 3411-3418.<br /> <br /> ===SNMPv1===<br /> Перші RFC, що описують стандарти SNMP, з'явилися в 1988 році. Версія 1 піддалася критиці за її слабку модель безпеки на основі спільнот. У той час безпека в Інтернеті не входила в коло першочергових завдань робочих груп IETF.<br /> <br /> 1. Обробка повідомлень<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]. A Simple Network Management Protocol;<br /> <br /> 2. Обробка PDU<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]. A Simple Network Management Protocol;<br /> <br /> 3. Інформаційна модель<br /> <br /> *Структура керуючої інформації<br /> [http://tools.ietf.org/html/rfc1065 RFC 1065]. Structure and Identification of Management Information for TCP / IP-based internets<br /> <br /> 4. Модулі MIB<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]. Management Information Base for Network Management of TCP / IP-based internets<br /> <br /> ===SNMPv2===<br /> <br /> Версія 2, відома, як Party-based SNMPv2, або SNMPv2p, не отримала широкого розповсюдження через серйозні розбіжності з приводу інфраструктури безпеки в стандарті.<br /> <br /> SNMPv2 поліпшував версію 1 в області швидкодії, безпеки, конфіденційності і взаємодій «менеджер-менеждер». Він представив новий тип PDU Get-Bulk-Request, альтернативу Get-Next-Request для отримання великих обсягів інформації за допомогою одного запиту. Проте, нова система безпеки на основі сторін виглядала для багатьох як надто складна і не була широко визнана.<br /> <br /> 1. Загальна інформація<br /> <br /> *[http://tools.ietf.org/html/rfc1441 RFC 1441]. Introduction to version 2 of the Internet-standard Network Management Framework<br /> <br /> *[http://tools.ietf.org/html/rfc1452 RFC 1452]. Coexistence between version 1 and version 2 of the Internet-standard Network <br /> Management Framework<br /> <br /> 2. Обробка повідомлень<br /> <br /> *Прив'язки до транспорту. [http://tools.ietf.org/html/rfc1448 RFC 1448]. Transport Mappings for SNMPv2<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc1446 RFC 1446]. Security Protocols for SNMPv2<br /> <br /> 3. Обробка PDU<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc1445 RFC 1445]. Administrative Model for SNMPv2<br /> <br /> *Протокольні операції. [http://tools.ietf.org/html/rfc1448 RFC 1448]. Protocol Operations for SNMPv2<br /> <br /> 4. Інформаційна модель<br /> <br /> *Структура керуючої інформації. [http://tools.ietf.org/html/rfc1442 RFC 1442]. Structure of Management Information SNMPv2<br /> <br /> *Текстові конвенції. [http://tools.ietf.org/html/rfc1443 RFC 1443]. Textual Conventions for SNMPv2<br /> <br /> *Вирази відповідності. [http://tools.ietf.org/html/rfc1444 RFC 1444]. Conformance Statements for SNMPv2<br /> <br /> 5. Модулі MIB<br /> <br /> *[http://tools.ietf.org/html/rfc1447 RFC 1447]. Party MIB for SNMPv2<br /> <br /> *[http://tools.ietf.org/html/rfc1450 RFC 1450]. MIB for SNMPv2<br /> <br /> *[http://tools.ietf.org/html/rfc1451 RFC 1451]. Manager-to-Manager MIB<br /> <br /> ===SNMPv2c===<br /> <br /> Community-based SNMPv2, або SNMPv2c, представив SNMPv2 без нової моделі безпеки версії 2. Замість неї пропонувалося використовувати стару модель безпеки версії 1 на основі спільнот. Відповідну пропозицію RFC було прийнято тільки як чернетку стандарту, однак стало де факто стандартом SNMPv2. Безпека SNMP знову опинилася невирішеним питанням.<br /> <br /> 1. Обробка повідомлень<br /> *Безпека. [http://tools.ietf.org/html/rfc1901 RFC 1901]. Introduction to Community-based SNMPv2<br /> <br /> ===SNMPv2u===<br /> <br /> User-based SNMPv2, або SNMPv2u, є компромісом між незахищеністю SNMPv1 і надмірною складністю SNMPv2p. Запропонована модель безпеки на основі користувачів була покладена в основу SNMPv3.<br /> <br /> 1. Обробка повідомлень<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc1909 RFC 1909] - An Administrative Infrastructure for SNMPv2 [http://tools.ietf.org/html/rfc1910 RFC 1910] - User-based Security Model for SNMPv2<br /> <br /> 2. Обробка PDU<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc1909 RFC 1909]. An Administrative Infrastructure for SNMPv2<br /> <br /> ===SNMPv3===<br /> <br /> SNMPv3 нарешті вирішив проблеми з безпекою способом, який багато хто вважав прийнятним. Версія 3 SNMP прийнята IETF як стандарт Інтернету (IETF STD 62). Майже всі попередні RFC визнані застарілими.<br /> <br /> 1. Загальна інформація<br /> *[http://tools.ietf.org/html/rfc3411 RFC 3411]. An Architecture for Describing SNMP Management Frameworks<br /> <br /> 2. Обробка повідомлень<br /> <br /> *Прив'язки до транспорту. [http://tools.ietf.org/html/rfc3417 RFC 3417]. Transport Mappings for the SNMP<br /> <br /> *Розбір і диспетчеризація повідомлень. [http://tools.ietf.org/html/rfc3412 RFC 3412]. Message Processing and Dispatching for the SNMP<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc3414 RFC 3414]. User-based Security Model (USM) for SNMPv3<br /> <br /> 3. Обробка PDU<br /> <br /> *Операції протоколу. [http://tools.ietf.org/html/rfc3416 RFC 3416]. Version 2 of the Protocol Operations for SNMP<br /> <br /> *Програми SNMP. [http://tools.ietf.org/html/rfc3413 RFC 3413]. SNMP Applications<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc3415 RFC 3415]. View-based Access Control Model (VACM) for the SNMP<br /> <br /> 4. Модулі MIB. [http://tools.ietf.org/html/rfc3418 RFC 3418]. MIB for the SNMP<br /> <br /> ==Існуючі реалізації==<br /> <br /> Підтримка SNMP - у багатьох значущих системах управління мережами, зокрема:<br /> <br /> *HP Network Node Manager;<br /> <br /> *IBM Tivoli NetView;<br /> <br /> *OpenNMS<br /> <br /> ===Недоліки SNMP===<br /> <br /> Протокол SNMP служить основою багатьох систем управління, хоча має кілька принципових недоліків, які перераховані нижче:<br /> <br /> *Відсутність засобів взаємної аутентифікації агентів і менеджерів. Єдиним засобом, який можна було б віднести до засобів аутентифікації, є використання в повідомленнях так званого рядка «community string». Цей рядок передається по мережі у відкритій формі в повідомленні SNMP і служить основою для поділу агентів і менеджерів на «спільноти», так що агент взаємодіє тільки з тими менеджерами, які вказують в поле community string такий же символьний рядок, що й рядок, який зберігається в пам'яті агента. Це, безумовно, не спосіб аутентифікації, а спосіб структурування агентів і менеджерів. Версія SNMP v.2 повинна була ліквідувати цей недолік, але в результаті розбіжностей між розробниками стандарту нові засоби аутентифікації хоча і з'явилися в цій версії, але як необов'язкові.<br /> <br /> *Робота через ненадійний протокол UDP (а саме так працює переважна більшість реалізації агентів SNMP) призводить до втрат аварійних повідомлень (повідомлень trap) від агентів до менеджерів, що може призвести до неякісного управління. <br /> <br /> ==Висновки==<br /> <br /> *SNMP широко використовується для управління мережами, особливо IP-мережами<br /> <br /> *Успіх SNMP в порівнянні з іншими стандартами управління показує переваги процесу стандартизації IETF<br /> <br /> *Історія розвитку SNMP показує важливість завдань захисту інформації<br /> <br /> *Архітектура SNMP цікава для аналізу архітектури мережевого програмного забезпечення; вона відповідає поставленим перед SNMP цілям<br /> <br /> *Архітектура SNMP відповідає архітектурному стилю ULCSS мережевого програмного забезпечення<br /> <br /> *У SNMP для вирішення функцій 6 рівня моделі OSI RM використовується ASN.1, що незвично для стандартів IETF і позитивно впливає на питання формалізації протоколів, однозначності стандартів, зручності проектування додатків<br /> <br /> *Структура стандартів SNMP добре продумана і показова для вивчення стандартів<br /> <br /> *Лише деякі моделі безпеки SNMP відповідають поставленим перед системою безпеки SNMP цілям<br /> <br /> *Агенти та менеджери SNMP прості в програмній реалізації, проте завжди потрібно пам'ятати про інформаційну безпеку<br /> <br /> <br /> <br /> <br /> [[Засоби моніторингу та аналізу мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/SNMP 2011-12-18T14:47:53Z

<p>Aleksey: </p> <hr /> <div>'''SNMP''' (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури [[TCP/IP]].<br /> <br /> ==Історія створення SNMP==<br /> <br /> Однією з найперших ініціатив з управління мережами була ініціатива ISO Open Systems Interconnection (OSI). Відповідні групи з стандартизації інфраструктури управління OSI (OSI Management Framework) були створені в 1981 році.<br /> <br /> До кінця 1980-х років мережа Інтернет стала досить великою і вимагала стандартів управління. Однак група ISO OSI була далека від завершення робіт над сімейством стандартів. Тому в 1987 році спільнотою IETF було прийнято рішення тимчасово створити набір спрощених стандартів управління в Інтернеті на основі напрацювань ISO OSI. Дані стандарти отримали назву Simple Network Management Protocol (SNMP). Надалі передбачалося перейти на стандарти ISO у міру їх готовності. Таким чином, багато ідей SNMP були взяті зі стандартів ISO:<br /> <br /> *Концепція «менеджер-агент»;<br /> <br /> *Ідея баз керуючої інформації (Management Information Bases, MIBs);<br /> <br /> *Використання синтаксису Abstract Syntax Notation One (ASN.1);<br /> <br /> *Частина термінології;<br /> <br /> Іншими проектом стандарту, на базі якого почалася розробка SNMP, був проект простого протоколу моніторингу шлюзів (Simple Gateway Monitoring Protocol, SGMP) співтовариства IETF.<br /> <br /> Надалі в рамках ISO OSI було запропоновано багато нових ідей, зокрема, об'єктно-орієнтований підхід. Однак ці ідеї вже не ввійшли в стандарти SNMP. Один час IETF продовжувала CMIP over TCP (CMOT), яка передбачала використання загального протоколу керуючої інформації (Common Management Information Protocol, CMIP) стека протоколів ISO OSI в стеку IETF TCP / IP. У 1992 році ця ініціатива була припинена у зв'язку з успіхом і поширеністю SNMP.<br /> <br /> Після багатьох засідань IAB (Internet Architecture Board) опублікував у квітні 1988 року епохальний RFC 1052: IAB Recommendations for the Development of Internet Network Management Standards, в якому закликав до якнайшвидшого створення елементів Простого Мережевого Управління (Simple Network Management).<br /> <br /> Багато ідей, що лежать сьогодні в основі SNMP, були запозичені у попередніх дослідженнях з моніторингу Internet-маршрутизаторів. І вже в серпні 1988 з'явилися три основні документа:<br /> <br /> *[http://tools.ietf.org/html/rfc1065 RFC 1065]: Structure and Identification of Management Information for TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]: Management Information Base for Network Management of TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]: A Simple Network Management Protocol.<br /> <br /> Згодом ці документи було перевидано і доповнено до визначення наступного покоління SNMP: RFC 1155, 1156 і 1157, які в свою чергу, також піддалися переробкам.<br /> <br /> Зрештою, у травні 1991 року була закінчена робота зі створення першої версії протоколу SNMPv1, яка знайшла своє відображення в зведенні таких документів:<br /> <br /> *[http://tools.ietf.org/html/rfc1155 RFC 1155]: Structure and Identification of Management Information for TCP / IP-based internets (Травень, 1990):<br /> - Визначає структуру керуючої інформації у вигляді глобального дерева.<br /> - Являє синтаксис визначення імен змінних управління.<br /> <br /> *[http://tools.ietf.org/html/rfc1212 RFC 1212]: Concise MIB Definitions (Березень, 1991)<br /> - Доповнює RFC 1155 в частині синтаксису визначення імен змінних.<br /> <br /> *[http://tools.ietf.org/html/rfc1213 RFC 1213]: Management Information Base for Network Management of TCP / IP-based internets: MIB-II (Березень, 1991):<br /> - Містить список більше ста найбільш необхідних змінних, що відповідають за конфігурацію, статус і статистику систем, що входять в TCP / IP мережі.<br /> <br /> *[http://tools.ietf.org/html/rfc1157 RFC 1157]: A Simple Network Management Protocol (SNMP) (Травень, 1990)<br /> - Визначає повідомлення, якими обмінюються керуюча станція і об'єкт управління для отримання та оновлення значення змінних.<br /> - Визначає trap (alarm)-повідомлення, що посилаються системою при значних змінах у її конфігурації.<br /> <br /> Опублікування цих стандартів стало поштовхом для виробників мережного обладнання, які розгорнули широкі роботи із забезпечення керованості:<br /> <br /> *всього спектра мережного обладнання - мостів, маршрутизаторів, модемів ...<br /> <br /> *широкого кола інтерфейсів - Point-to-Point, DS1, DS3, X.25, Frame Relay, Ethernet, Token Ring, FDDI, та ін.<br /> <br /> В загальному, стандарти SNMP продовжували розвиватися протягом 1990-х років. Основним напрямком розвитку було вдосконалення питань безпеки. Були розроблені наступні версії SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u і SNMPv3. Їх обговорення буде продовжено в розділі «Версії SNMP».<br /> <br /> ==Задачі==<br /> <br /> Сімейство стандартів SNMP створено для вирішення задач обробки помилок і аналізу продуктивності і надійності.<br /> <br /> '''Обробка помилок'''<br /> <br /> Виявлення, визначення і усунення наслідків збоїв і відмов у роботі мережі. На цьому рівні виконується реєстрація повідомлень про помилки, їх фільтрація, маршрутизація і аналіз на основі деякої кореляційної моделі.<br /> <br /> '''Аналіз продуктивності і надійності'''<br /> <br /> Оцінка на основі статистичної інформації таких параметрів, як час реакції системи, пропускна спроможність каналів зв'язку, інтенсивність трафіку в окремих сегментах мережі, імовірність спотворення даних, коефіцієнт готовності служб мережі. Результати такого аналізу дозволяють контролювати угоду про рівень обслуговування (Service Level Agreement, SLA).<br /> <br /> Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:<br /> <br /> *Широка сфера застосування. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;<br /> <br /> *Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;<br /> <br /> *Стійкість у критичних ситуаціях. Наприклад, при перевантаженні і проблемах в мережі, тобто при множинних помилках.<br /> <br /> ==Архітектура==<br /> <br /> Архітектуру розподіленої системи можна описати в термінах обробних елементів (або компонентів), що з'єднують елементів (або з'єднувачів) і елементів даних. Перерахуємо складові елементи системи управління SNMP:<br /> <br /> 1. компоненти:<br /> <br /> *агент;<br /> <br /> *менеджер;<br /> <br /> 2. з'єднувачі:<br /> <br /> *транспортний протокол;<br /> <br /> *Протокольні блоки даних (Protocol Data Units, PDU) і повідомлення SNMP;<br /> <br /> 3. дані:<br /> <br /> *Керуюча інформація MIB;<br /> <br /> Опишемо детальніше і проаналізуємо архітектуру SNMP з позиції досягнення поставлених перед SNMP цілей. Для цього використовуємо поняття архітектурного стилю мережевого програмного забезпечення. Архітектурний стиль - це узгоджений набір архітектурних обмежень, накладених на ролі і особливості архітектурних елементів (компонентів, з'єднувачів і даних) і відносин між ними, яка проявляється у будь-якій архітектурі, і яка задовольняє цьому стилю.<br /> <br /> ===Компоненти===<br /> <br /> Архітектура SNMP передбачає побудову системи управління за схемою «менеджер-агент», тобто використання архітектурного стилю «клієнт-сервер». Система SNMP містить безліч керованих вузлів, на кожному з яких розміщується досить простий сервер - агент SNMP, а також, принаймні, один вузол, що містить складного клієнта - менеджера SNMP.<br /> <br /> Менеджер взаємодіє з агентами за допомогою протоколу SNMP з метою обміну керуючою інформацією. В основному, ця взаємодія реалізується у вигляді періодичного опитування менеджером множини агентів, так як агенти всього лише надають доступ до інформації, але не знають, що їм з нею робити. Видно, що система, побудована за такими принципами, втрачає масштабованость, оскільки є виділений клієнт, який займається опитуванням всіх серверів. Зате така схема забезпечує простоту реалізації систем під управлінням SNMP.<br /> <br /> Для підвищення масштабованості та адміністративної керованості вводиться поняття проксі-агента, який може переправляти операції протоколу SNMP, а також поняття менеджера проміжного рівня, який приховує несуттєві подробиці керуючої інформації від систем управління мережами верхнього рівня, інтегруючи одержувані від агентів дані. Це дозволяє створювати багаторівневі системи управління, що відповідають архітектурному стилю «багаторівневий клієнт-сервер».<br /> <br /> Більш детальна класифікація компонентів за ролями:<br /> <br /> 1. Менеджер:<br /> <br /> *Менеджер проміжного рівня;<br /> <br /> *Система управління мережами;<br /> <br /> 2. Агент:<br /> <br /> * Мінімальний агент;<br /> <br /> * Проксі-агент;<br /> <br /> Компоненти в SNMP узагальнено називаються сутностями SNMP.<br /> <br /> ===Дані===<br /> <br /> Тепер розглянемо дані, якими маніпулюють системи SNMP, тобто керуючу інформацію. У SNMP кожний керований пристрій, на якому розташований агент, представляє свою керуючу інформацію у вигляді змінних. Такими змінними можуть бути, наприклад, ім'я системи, час з моменту її перезапуску, записи в таблиці маршрутизації і т. д. В загальному випадку змінні можна розділити на:<br /> <br /> *Скалярні змінні;<br /> <br /> *Таблиці змінних;<br /> <br /> Схема даних описується структурою керуючої інформації (Structure of Management Information, SMI). Схема даних визначає, як виглядає керуюча інформація, тобто описує її синтаксис. SMI базується на Abstract Syntax Notation One (ASN.1).<br /> <br /> Конкретні набори керуючої інформації для різних типів пристроїв, протоколів і т. д. описуються базами керуючої інформації (Management Information Bases, MIBs). Бази MIB визначають, яка управляюча інформація існує. Наприклад, для пристрою, що підтримує IP, MIB описує таблицю маршрутизації, прапорець активації функції маршрутизації, число переданих і прийнятих пакетів, число помилок різного характеру і т. д.<br /> <br /> Таким чином, кожен пристрій містить набір значень змінних, визначених у деякій кількості MIB, описаних за правилами SMI. Цей набір змінних і є даними, що управляє інформацією для протоколу SNMP.<br /> <br /> Важливим питанням є іменування змінних. У SNMP кожній змінній присвоюється унікальний ідентифікатор об'єкта (Object Identifier, OID). Простір імен OID є ієрархічним і контролюється організацією по розподілу номерів в Інтернеті (Internet Assigned Numbers Authority, IANA). Кожен компонент імені є числом. В текстовому вигляді імена записуються як десяткові числа, розділені крапками, зліва направо. Числам можуть бути поставлені у відповідність текстові рядки для зручності сприйняття. У цілому, структура імені схожа на систему доменних імен Інтернету (Domain Name System, DNS).<br /> <br /> Кожна MIB визначає набір змінних, тобто певну гілку дерева OID, що описує керуючу інформацію в певній галузі. Наприклад, гілка 1.3.6.1.2.1.1 (мнемонічний еквівалент: iso.org.dod.internet.mgmt.mib-2.system) описує загальну інформацію про систему. Опишемо деякі змінні з цієї гілки:<br /> <br /> *sysDescr (1.3.6.1.2.1.1.1) - короткий опис системи;<br /> <br /> *sysUpTime (1.3.6.1.2.1.1.3) - час з моменту останнього перезапуску;<br /> <br /> *sysName (1.3.6.1.2.1.1.5) - назва системи.<br /> <br /> Змінні і відомості про їхній тип визначені також в MIB. А самі типи змінних - в SMI.<br /> <br /> Крім безпосередньо даних, необхідно ввести операції над ними. Набір цих операцій змінювався і розширювався в міру розвитку SNMP. Основними операціями є:<br /> <br /> *Читання змінної;<br /> <br /> *Запис змінної;<br /> <br /> *Читання змінної, наступної за заданою змінною (необхідне для перегляду таблиць змінних);<br /> <br /> Більш докладно операції над даними описані нижче при обговоренні з'єднувачів в архітектурі SNMP.<br /> <br /> В цілому, операції над даними в SNMP схожі на віддалене налагодження деякої програми: стан системи описується певним набором змінних, які можна переглядати і змінювати.<br /> <br /> ===З'єднувачі===<br /> <br /> Для обміну даними між компонентами використовуються з'єднувачі. У разі SNMP в якості з'єднувача використовується протокол прикладного рівня Simple Network Management Protocol (SNMP), що звичайно працює поверх стека протоколів TCP / IP.<br /> <br /> Розглянемо стек протоколів більш докладно, вказавши прив'язку протоколів до Open Systems Interconnection Reference Model (OSI RM).<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;№&lt;/td&gt;<br /> &lt;td&gt;Протокол&lt;/td&gt;<br /> &lt;td&gt;Коментарі&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;7&lt;/td&gt;<br /> &lt;td&gt;SNMP&lt;/td&gt;<br /> &lt;td&gt;Повідомлення, PDU, операції&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;6&lt;/td&gt;<br /> &lt;td&gt;ASN.1 BER&lt;/td&gt;<br /> &lt;td&gt;Кодування даних&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;5&lt;/td&gt;<br /> &lt;td&gt;-&lt;/td&gt;<br /> &lt;td&gt;-&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;4&lt;/td&gt;<br /> &lt;td&gt;UDP&lt;/td&gt;<br /> &lt;td&gt;Транспорт між службами&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;3&lt;/td&gt;<br /> &lt;td&gt;IP&lt;/td&gt;<br /> &lt;td&gt;Зв'язок між вузлами мережі&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> SNMP вводить свій протокол прикладного рівня. Є чотири версії даного протоколу: SNMPv1, SNMPv2, SNMPv2c і SNMPv3. У процесі розвитку SNMP розширювалися можливі операції, тобто типи протокольних блоків даних (Protocol Data Units, PDUs), а також вводилися нові формати повідомлень SNMP для забезпечення безпеки.<br /> <br /> Повідомлення SNMP містить номер версії SNMP, інформацію про безпеку та протокольний блок даних PDU, який характеризує виконувану операцію і її параметри. Наприклад, SNMPv1 описує наступні PDU і відповідні операції:<br /> <br /> *Get-Request - запит на отримання значень 1 .. N змінних;<br /> <br /> *Get-Next-Request - запит на отримання значень 1 .. N змінних, чиї OID йдуть слідом за OID зазначених 1 .. N змінних;<br /> <br /> *Get-Response - відповідь на запити Get-Request, Get-Next-Request і Set-Request;<br /> <br /> *Set-Request - установка значень 1 .. N змінних;<br /> <br /> *Trap - пастка (див. нижче);<br /> <br /> SNMP - це протокол типу &quot;запит-відповідь&quot;, тобто на кожен запит, що надійшов від менеджера, агент повинен передати відповідь.<br /> <br /> [[Файл:ZaprOtv.gif]]<br /> <br /> Описані PDU, як уже згадувалося, є частиною повідомлення SNMP. Повідомлення кодуються для передачі по мережі за допомогою ASN.1 Basic Encoding Rules (BER). Це функція шостого рівня (рівня подання) еталонної моделі OSI. Далі закодовані повідомлення відправляються одним компонентом SNMP іншого за допомогою транспортного протоколу.<br /> <br /> Як вже зазначалося, стандарт передбачає використання різного транспорту для SNMP, але майже завжди використовується протокол користувацьких датаграм (User Datagram Protocol, UDP). Агенти використовують добре відомий порт UDP 161. Цей протокол надає мінімальні транспортні послуги (доставка повідомлень від служби до служби і перевірка контрольної суми) і не передбачає організацію сеансів і потокову передачу даних, як Transmission Control Protocol (TCP). За рахунок цього вдається домогтися великої швидкості реакції і швидкодії, що відповідає поставленим перед SNMP цілям.<br /> <br /> Для підвищення швидкості реакції менеджера на термінові події вводиться спеціальний тип операції протоколу SNMP, так звана «пастка» (Trap). Він дозволяє агентам асинхронно інформувати менеджера (за власною ініціативою) про настання обмеженого числа значущих подій. У цьому випадку агент виступає в незвичній для себе ролі клієнта, а менеджер - в ролі сервера. У разі використання транспорту UDP для вхідних з'єднань менеджер використовує добре відомий порт UDP 162.<br /> <br /> Як ми бачимо, жодна з цих операцій не припускає, що агент зберігає інформацію про сесії з менеджером. Для виконання операції Trap така інформація зберігається статично, тобто сесія в такому випадку статична і перманентна. Крім цього операції SNMP визначають єдині, уніфіковані інтерфейси агентів і менеджерів SNMP. Таким чином, SNMP - це протокол без збереження стану, який відповідає архітектурному стилю «уніфікований багаторівневий клієнт-сервер без збереження стану».<br /> <br /> Опишемо деякі властивості операцій SNMP на прикладі SNMPv1:<br /> <br /> &lt;table cellpadding=&quot;3&quot; cellspacing=&quot;0&quot; bordercolor=&quot;#000000&quot; border=&quot;1&quot;&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Ім'я&lt;/td&gt;<br /> &lt;td&gt;Безпека&lt;/td&gt;<br /> &lt;td&gt;Підтвердження&lt;/td&gt;<br /> &lt;td&gt;Ідемпотентність&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Request&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Next-Request&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Get-Response&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Set-Request&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;tr&gt;<br /> &lt;td&gt;Trap&lt;/td&gt;<br /> &lt;td&gt;1&lt;/td&gt;<br /> &lt;td&gt;0&lt;/td&gt;<br /> &lt;td&gt;?&lt;/td&gt;<br /> &lt;/tr&gt;<br /> &lt;/table&gt;<br /> <br /> Таким чином, ми розглянули всі основні архітектурні особливості SNMP, крім моделей безпеки. Питання, пов'язані із захистом інформації, будуть розглянуті нижче при обговоренні версій стандартів SNMP.<br /> <br /> ==Відповідність архітектурному стилю REST==<br /> <br /> Архітектурний стиль REST - це уніфікований багаторівневий клієнт-серверний стиль, з кодом за запитом та без збереження стану (Unified-Layered-Code-on-Demand-Client-Cached-Stateless-Server, ULCODCСSS). Як ми визначили в результаті аналізу архітектури SNMP, система SNMP визначається уніфікованим багаторівневим клієнт-серверних стилем без збереження стану (Unified-Layered-Client-Stateless-Server, ULCSS).<br /> <br /> Як ми бачимо, на SNMP не накладаються обмеження, пов'язані з реплікацією (наявність кеша) і мобільним кодом (застосування коду за вимогою). У цьому сенсі стиль SNMP - більш вільний, ніж REST, тобто містить менше архітектурних особливостей, які, наприклад, необхідно враховувати при моделюванні систем з такою архітектурою.<br /> <br /> Однак, навіть у SNMPv1 є особлива операція Trap, що ініціюється агентом асинхронно по відношенню до менеджера. У SNMPv2 вводиться операція Inform-Request, яка також виконується асинхронно, але між двома менеджерами. При виконанні таких операцій клієнт і сервер міняються ролями. При цьому використовується принцип інтеграції на основі повідомлень. Це елементи однорангового стилю взаємодії (Peer-to-Peer), хоча в даному випадку ролі клієнта і сервера для конкретних типів протокольних операцій виражені явно. У цьому сенсі стиль SNMP - більш обмежений, ніж REST.<br /> <br /> Таким чином, при певних обмеженнях система SNMP може бути розглянута як REST-івська розподілена система.<br /> <br /> ==Структура стандартів==<br /> <br /> Стандарти SNMP описують аспекти, відображені нижче:<br /> <br /> 1. Загальна інформація;<br /> <br /> 2. Обробка повідомлень (SNMP Messages):<br /> <br /> *Прив'язки до транспорту;<br /> <br /> *Розбір і диспетчеризація повідомлень;<br /> <br /> *Безпека (аутентифікація, шифрування, своєчасність);<br /> <br /> 3. Обробка протокольних блоків даних (SNMP PDUs):<br /> <br /> *Операції протоколу;<br /> <br /> *Програми SNMP;<br /> <br /> *Управління доступом;<br /> <br /> 4. Інформаційна модель:<br /> <br /> *Структура керуючої інформації (SMI);<br /> <br /> *Текстові конвенції;<br /> <br /> *Вирази відповідності;<br /> <br /> 5. Модулі баз керуючої інформації (MIB);<br /> <br /> Спочатку в стандартах виділялися не всі ці аспекти. Проте, структура стандартів SNMP всіх версій вписується в цю схему.<br /> <br /> ==Інформаційна безпека==<br /> <br /> Розглянемо, як враховуються в SNMP основні елементи інформаційної безпеки:<br /> <br /> *Конфіденційність;<br /> <br /> *Цілісність;<br /> <br /> *Доступність;<br /> <br /> *Контрольованість;<br /> <br /> У ході розвитку стандартів SNMP інфраструктура безпеки піддавалася найбільших змін. Для того, щоб простежити ці зміни, спочатку опишемо вимоги безпеки та загрози, потім структуру моделей безпеки, після чого розглянемо використання в різних версіях SNMP моделі.<br /> <br /> ===Вимоги та загрози безпеці===<br /> <br /> Опишемо вимоги безпеки в архітектурі SNMP. Загрозами безпеці, проти яких повинна надавати захист будь-яка модель безпеки SNMP, є:<br /> <br /> 1. Первинні загрози:<br /> <br /> *Модифікація інформації;<br /> <br /> *Маскарад;<br /> <br /> 2. Вторинні загрози:<br /> <br /> *Модифікація потоку повідомлень;<br /> <br /> *Розголошення;<br /> <br /> Загроза модифікації інформації - це можливість того, що деяка неавторизована сутність може змінити повідомлення SNMP, згенеровані за запитом авторизованого принципала, на шляху їх слідування таким чином, що це призведе до неавторизованих операцій управління, включаючи фальсифікацію значення об'єкта (змінної).<br /> <br /> Загроза маскараду - це можливість того, що операції управління, не авторизовані для деякого принципала, можуть бути виконані при підстановці ідентифікатора іншого принципала, для якого подібні дії авторизовані.<br /> <br /> Загроза модифікації потоку повідомлень полягає в наступному. Протокол SNMP звичайно що грунтується на транспортній службі без організації з'єднання. Перестановка, затримка або повторна посилка повідомлень може відбуватися і відбувається в ході звичайної експлуатації мереж із застосуванням таких протоколів. Загроза модифікацій потоку повідомлень - це можливість того, що повідомлення можуть бути переставлені, затримані чи повторно надіслані зі злим умислом із затримками, які перевищують наявне місце затримки при нормальній експлуатації, з метою виконання неавторизованих операцій управління.<br /> <br /> Загроза розголошення - це можливість прослуховування обмінів повідомленнями між сутностями SNMP. Захист від цієї загрози може вимагати локальної політики безпеки.<br /> <br /> Модель безпеки може не боротися з такими загрозами, як, наприклад, відмова в обслуговуванні, оскільки стан мережевих збоїв і помилок (нормальне для SNMP) часто не відрізняються від ситуацій відмови в обслуговуванні.<br /> <br /> Як ми побачимо нижче, на практиці не кожна модель безпеки SNMP задовольняє вимогам нейтралізації перерахованих загроз.<br /> <br /> ===Структура моделей безпеки===<br /> <br /> Сутність SNMP містить дві підсистеми:<br /> <br /> *Підсистема безпеки;<br /> <br /> *Підсистема управління доступом;<br /> <br /> Підсистема безпеки функціонує на рівні повідомлень SNMP. Вона відповідає за аутентифікацію, шифрування і своєчасність. Документ з безпеки описує модель безпеки, загрози, проти яких вона захищає, цілі моделі безпеки, протоколи, використовувані для досягнення цих цілей, модуль MIB, що описує відповідні структури даних. Такий модуль потрібний у тому числі і для того, щоб віддалено конфігурувати параметри безпеки рівня повідомлень SNMP.<br /> <br /> Підсистема управління доступом функціонує на рівні SNMP PDU. Очевидно, що вона відповідає за управління доступом до керованих об'єктів (змінних). Документи, що описують її, також визначають модуль MIB для віддаленого налаштування параметрів.<br /> <br /> ===Моделі безпеки===<br /> <br /> Перелічимо основні моделі безпеки та відповідні їм інфраструктури:<br /> 1. SNMPv1:<br /> <br /> *SNMPv1 - Community-based Security Model;<br /> <br /> 2. SNMPv2:<br /> <br /> *SNMPv2p - Party-based Security Model;<br /> <br /> *SNMPv2c - Community-based Security Model;<br /> <br /> *SNMPv2u - User-based Security Model;<br /> <br /> 3. SNMPv3<br /> <br /> *SNMPv3 USM User-based Security Model.<br /> <br /> Модель безпеки на основі спільнот (Community-based Security Model) була першою, найпростішою і найбезпечнішою. Вона полягає лише у аутентифікації на основі «рядка спільноти», фактично, пароля, переданого по мережі в тексті повідомлення SNMP у відкритому вигляді. Ця модель безпеки не в змозі боротися ні з однією із загроз інформаційної безпеки в SNMP. Тим не менш, вона часто використовується до цих пір у зв'язку зі своєю простотою, а також завдяки наявності зовнішніх, не пов'язаних з SNMP систем безпеки, наприклад, міжмережевих екранів.<br /> <br /> Модель безпеки на основі сторін (Party-based Security Model) передбачає введення поняття сторони. Сторона - це віртуальне оточення виконання, в якому набір допустимих операцій обмежений адміністративно. Сутність SNMP при обробці повідомлення діє як сторона, тому обмежена операціями, визначеними для цієї сторони. Сторона визначається наступними параметрами:<br /> <br /> *Унікальний ідентифікатор сторони;<br /> <br /> *Логічна мережева адреса (область адрес транспортного протоколу та адреса транспортного протоколу);<br /> <br /> *Протокол аутентифікації і параметри, що вимагаються для аутентифікації всіх повідомлень сторони;<br /> <br /> *Протокол шифрування і параметри, потрібні для шифрування всіх повідомлень сторони;<br /> <br /> Можуть використовуватися різні алгоритми для протоколів аутентифікації і шифрування. Звичайно як алгоритму для протоколу аутентифікації використовують хеш-функцію Message Digest 5 (MD5), а для протоколу шифрування - алгоритм Data Encryption Standard (DES) в режимі Cipher Block Chaining (CBC).<br /> <br /> Запроваджуються й інші поняття, що використовуються для реалізації цієї моделі. Проте тут вони докладно не розглядаються, так само як і деталі функціонування моделі. Зазначимо лише, що при використанні відповідних протоколів аутентифікації і шифрування модель успішно справляється з описаними вище загрозами безпеці SNMP. Дана модель безпеки не була широко прийнята, оскільки є занадто складною і заплутаною.<br /> <br /> Модель безпеки на основі користувачів (User-based Security Model) вводить поняття користувача, від імені якого діє сутність SNMP. Цей користувач характеризується ім'ям користувача, використовуваними протоколами аутентифікації і шифрування, а також закритим ключем аутентифікації і шифрування. Аутентифікація і шифрування є необов'язковими. Їх наявність описується одним з параметрів моделі, якістю обслуговування (Quality of Service, QoS). Модель безпеки багато в чому схожа на модель сторін, але вона спрощує ідентифікацію користувачів, розподіл ключів і протокольні операції.<br /> <br /> ==Версії SNMP==<br /> <br /> Коротко опишемо відмінності між версіями SNMP і документи, що визначають ці версії. Зауважимо, що тут наведено перші версії RFC кожної з версій SNMP, тобто майже всі з них були заміщені новішими RFC і визнані застарілими. На даний момент єдиною не застарілою версією SNMP є SNMPv3, визначена в RFC 3411-3418.<br /> <br /> ===SNMPv1===<br /> Перші RFC, що описують стандарти SNMP, з'явилися в 1988 році. Версія 1 піддалася критиці за її слабку модель безпеки на основі спільнот. У той час безпека в Інтернеті не входила в коло першочергових завдань робочих груп IETF.<br /> <br /> 1. Обробка повідомлень<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]. A Simple Network Management Protocol;<br /> <br /> 2. Обробка PDU<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]. A Simple Network Management Protocol;<br /> <br /> 3. Інформаційна модель<br /> <br /> *Структура керуючої інформації<br /> [http://tools.ietf.org/html/rfc1065 RFC 1065]. Structure and Identification of Management Information for TCP / IP-based internets<br /> <br /> 4. Модулі MIB<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]. Management Information Base for Network Management of TCP / IP-based internets<br /> <br /> ===SNMPv2===<br /> <br /> Версія 2, відома, як Party-based SNMPv2, або SNMPv2p, не отримала широкого розповсюдження через серйозні розбіжності з приводу інфраструктури безпеки в стандарті.<br /> <br /> SNMPv2 поліпшував версію 1 в області швидкодії, безпеки, конфіденційності і взаємодій «менеджер-менеждер». Він представив новий тип PDU Get-Bulk-Request, альтернативу Get-Next-Request для отримання великих обсягів інформації за допомогою одного запиту. Проте, нова система безпеки на основі сторін виглядала для багатьох як надто складна і не була широко визнана.<br /> <br /> 1. Загальна інформація<br /> <br /> *[http://tools.ietf.org/html/rfc1441 RFC 1441]. Introduction to version 2 of the Internet-standard Network Management Framework<br /> <br /> *[http://tools.ietf.org/html/rfc1452 RFC 1452]. Coexistence between version 1 and version 2 of the Internet-standard Network <br /> Management Framework<br /> <br /> 2. Обробка повідомлень<br /> <br /> *Прив'язки до транспорту. [http://tools.ietf.org/html/rfc1448 RFC 1448]. Transport Mappings for SNMPv2<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc1446 RFC 1446]. Security Protocols for SNMPv2<br /> <br /> 3. Обробка PDU<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc1445 RFC 1445]. Administrative Model for SNMPv2<br /> <br /> *Протокольні операції. [http://tools.ietf.org/html/rfc1448 RFC 1448]. Protocol Operations for SNMPv2<br /> <br /> 4. Інформаційна модель<br /> <br /> *Структура керуючої інформації. [http://tools.ietf.org/html/rfc1442 RFC 1442]. Structure of Management Information SNMPv2<br /> <br /> *Текстові конвенції. [http://tools.ietf.org/html/rfc1443 RFC 1443]. Textual Conventions for SNMPv2<br /> <br /> *Вирази відповідності. [http://tools.ietf.org/html/rfc1444 RFC 1444]. Conformance Statements for SNMPv2<br /> <br /> 5. Модулі MIB<br /> <br /> *[http://tools.ietf.org/html/rfc1447 RFC 1447]. Party MIB for SNMPv2<br /> <br /> *[http://tools.ietf.org/html/rfc1450 RFC 1450]. MIB for SNMPv2<br /> <br /> *[http://tools.ietf.org/html/rfc1451 RFC 1451]. Manager-to-Manager MIB<br /> <br /> ===SNMPv2c===<br /> <br /> Community-based SNMPv2, або SNMPv2c, представив SNMPv2 без нової моделі безпеки версії 2. Замість неї пропонувалося використовувати стару модель безпеки версії 1 на основі спільнот. Відповідну пропозицію RFC було прийнято тільки як чернетку стандарту, однак стало де факто стандартом SNMPv2. Безпека SNMP знову опинилася невирішеним питанням.<br /> <br /> 1. Обробка повідомлень<br /> *Безпека. [http://tools.ietf.org/html/rfc1901 RFC 1901]. Introduction to Community-based SNMPv2<br /> <br /> ===SNMPv2u===<br /> <br /> User-based SNMPv2, або SNMPv2u, є компромісом між незахищеністю SNMPv1 і надмірною складністю SNMPv2p. Запропонована модель безпеки на основі користувачів була покладена в основу SNMPv3.<br /> <br /> 1. Обробка повідомлень<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc1909 RFC 1909] - An Administrative Infrastructure for SNMPv2 [http://tools.ietf.org/html/rfc1910 RFC 1910] - User-based Security Model for SNMPv2<br /> <br /> 2. Обробка PDU<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc1909 RFC 1909]. An Administrative Infrastructure for SNMPv2<br /> <br /> ===SNMPv3===<br /> <br /> SNMPv3 нарешті вирішив проблеми з безпекою способом, який багато хто вважав прийнятним. Версія 3 SNMP прийнята IETF як стандарт Інтернету (IETF STD 62). Майже всі попередні RFC визнані застарілими.<br /> <br /> 1. Загальна інформація<br /> *[http://tools.ietf.org/html/rfc3411 RFC 3411]. An Architecture for Describing SNMP Management Frameworks<br /> <br /> 2. Обробка повідомлень<br /> <br /> *Прив'язки до транспорту. [http://tools.ietf.org/html/rfc3417 RFC 3417]. Transport Mappings for the SNMP<br /> <br /> *Розбір і диспетчеризація повідомлень. [http://tools.ietf.org/html/rfc3412 RFC 3412]. Message Processing and Dispatching for the SNMP<br /> <br /> *Безпека. [http://tools.ietf.org/html/rfc3414 RFC 3414]. User-based Security Model (USM) for SNMPv3<br /> <br /> 3. Обробка PDU<br /> <br /> *Операції протоколу. [http://tools.ietf.org/html/rfc3416 RFC 3416]. Version 2 of the Protocol Operations for SNMP<br /> <br /> *Програми SNMP. [http://tools.ietf.org/html/rfc3413 RFC 3413]. SNMP Applications<br /> <br /> *Управління доступом. [http://tools.ietf.org/html/rfc3415 RFC 3415]. View-based Access Control Model (VACM) for the SNMP<br /> <br /> 4. Модулі MIB. [http://tools.ietf.org/html/rfc3418 RFC 3418]. MIB for the SNMP<br /> <br /> ==Існуючі реалізації==<br /> <br /> Підтримка SNMP - у багатьох значущих системах управління мережами, зокрема:<br /> <br /> *HP Network Node Manager;<br /> <br /> *IBM Tivoli NetView;<br /> <br /> *OpenNMS<br /> <br /> ==Висновки==<br /> <br /> *SNMP широко використовується для управління мережами, особливо IP-мережами<br /> <br /> *Успіх SNMP в порівнянні з іншими стандартами управління показує переваги процесу стандартизації IETF<br /> <br /> *Історія розвитку SNMP показує важливість завдань захисту інформації<br /> <br /> *Архітектура SNMP цікава для аналізу архітектури мережевого програмного забезпечення; вона відповідає поставленим перед SNMP цілям<br /> <br /> *Архітектура SNMP відповідає архітектурному стилю ULCSS мережевого програмного забезпечення<br /> <br /> *У SNMP для вирішення функцій 6 рівня моделі OSI RM використовується ASN.1, що незвично для стандартів IETF і позитивно впливає на питання формалізації протоколів, однозначності стандартів, зручності проектування додатків<br /> <br /> *Структура стандартів SNMP добре продумана і показова для вивчення стандартів<br /> <br /> *Лише деякі моделі безпеки SNMP відповідають поставленим перед системою безпеки SNMP цілям<br /> <br /> Агенти та менеджери SNMP прості в програмній реалізації, проте завжди потрібно пам'ятати про інформаційну безпеку<br /> <br /> <br /> <br /> <br /> [[Засоби моніторингу та аналізу мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:ZaprOtv.gif 2011-12-18T11:48:41Z

<p>Aleksey: </p> <hr /> <div></div>

Aleksey https://wiki.cusu.edu.ua/index.php/SNMP 2011-12-18T00:37:35Z

<p>Aleksey: </p> <hr /> <div>'''SNMP''' (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури [[TCP/IP]].<br /> <br /> ==Історія створення SNMP==<br /> <br /> Однією з найперших ініціатив з управління мережами була ініціатива ISO Open Systems Interconnection (OSI). Відповідні групи з стандартизації інфраструктури управління OSI (OSI Management Framework) були створені в 1981 році.<br /> <br /> До кінця 1980-х років мережа Інтернет стала досить великою і вимагала стандартів управління. Однак група ISO OSI була далека від завершення робіт над сімейством стандартів. Тому в 1987 році спільнотою IETF було прийнято рішення тимчасово створити набір спрощених стандартів управління в Інтернеті на основі напрацювань ISO OSI. Дані стандарти отримали назву Simple Network Management Protocol (SNMP). Надалі передбачалося перейти на стандарти ISO у міру їх готовності. Таким чином, багато ідей SNMP були взяті зі стандартів ISO:<br /> <br /> *Концепція «менеджер-агент»;<br /> <br /> *Ідея баз керуючої інформації (Management Information Bases, MIBs);<br /> <br /> *Використання синтаксису Abstract Syntax Notation One (ASN.1);<br /> <br /> *Частина термінології;<br /> <br /> Іншими проектом стандарту, на базі якого почалася розробка SNMP, був проект простого протоколу моніторингу шлюзів (Simple Gateway Monitoring Protocol, SGMP) співтовариства IETF.<br /> <br /> Надалі в рамках ISO OSI було запропоновано багато нових ідей, зокрема, об'єктно-орієнтований підхід. Однак ці ідеї вже не ввійшли в стандарти SNMP. Один час IETF продовжувала CMIP over TCP (CMOT), яка передбачала використання загального протоколу керуючої інформації (Common Management Information Protocol, CMIP) стека протоколів ISO OSI в стеку IETF TCP / IP. У 1992 році ця ініціатива була припинена у зв'язку з успіхом і поширеністю SNMP.<br /> <br /> Після багатьох засідань IAB (Internet Architecture Board) опублікував у квітні 1988 року епохальний RFC 1052: IAB Recommendations for the Development of Internet Network Management Standards, в якому закликав до якнайшвидшого створення елементів Простого Мережевого Управління (Simple Network Management).<br /> <br /> Багато ідей, що лежать сьогодні в основі SNMP, були запозичені у попередніх дослідженнях з моніторингу Internet-маршрутизаторів. І вже в серпні 1988 з'явилися три основні документа:<br /> <br /> *[http://tools.ietf.org/html/rfc1065 RFC 1065]: Structure and Identification of Management Information for TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]: Management Information Base for Network Management of TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]: A Simple Network Management Protocol.<br /> <br /> Згодом ці документи було перевидано і доповнено до визначення наступного покоління SNMP: RFC 1155, 1156 і 1157, які в свою чергу, також піддалися переробкам.<br /> <br /> Зрештою, у травні 1991 року була закінчена робота зі створення першої версії протоколу SNMPv1, яка знайшла своє відображення в зведенні таких документів:<br /> <br /> *[http://tools.ietf.org/html/rfc1155 RFC 1155]: Structure and Identification of Management Information for TCP / IP-based internets (Травень, 1990):<br /> - Визначає структуру керуючої інформації у вигляді глобального дерева.<br /> - Являє синтаксис визначення імен змінних управління.<br /> <br /> *[http://tools.ietf.org/html/rfc1212 RFC 1212]: Concise MIB Definitions (Березень, 1991)<br /> - Доповнює RFC 1155 в частині синтаксису визначення імен змінних.<br /> <br /> *[http://tools.ietf.org/html/rfc1213 RFC 1213]: Management Information Base for Network Management of TCP / IP-based internets: MIB-II (Березень, 1991):<br /> - Містить список більше ста найбільш необхідних змінних, що відповідають за конфігурацію, статус і статистику систем, що входять в TCP / IP мережі.<br /> <br /> *[http://tools.ietf.org/html/rfc1157 RFC 1157]: A Simple Network Management Protocol (SNMP) (Травень, 1990)<br /> - Визначає повідомлення, якими обмінюються керуюча станція і об'єкт управління для отримання та оновлення значення змінних.<br /> - Визначає trap (alarm)-повідомлення, що посилаються системою при значних змінах у її конфігурації.<br /> <br /> Опублікування цих стандартів стало поштовхом для виробників мережного обладнання, які розгорнули широкі роботи із забезпечення керованості:<br /> <br /> *всього спектра мережного обладнання - мостів, маршрутизаторів, модемів ...<br /> <br /> *широкого кола інтерфейсів - Point-to-Point, DS1, DS3, X.25, Frame Relay, Ethernet, Token Ring, FDDI, та ін.<br /> <br /> В загальному, стандарти SNMP продовжували розвиватися протягом 1990-х років. Основним напрямком розвитку було вдосконалення питань безпеки. Були розроблені наступні версії SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u і SNMPv3. Їх обговорення буде продовжено в розділі «Версії SNMP».<br /> <br /> ==Задачі==<br /> <br /> Сімейство стандартів SNMP створено для вирішення задач обробки помилок і аналізу продуктивності і надійності.<br /> <br /> '''Обробка помилок'''<br /> <br /> Виявлення, визначення і усунення наслідків збоїв і відмов у роботі мережі. На цьому рівні виконується реєстрація повідомлень про помилки, їх фільтрація, маршрутизація і аналіз на основі деякої кореляційної моделі.<br /> <br /> '''Аналіз продуктивності і надійності'''<br /> <br /> Оцінка на основі статистичної інформації таких параметрів, як час реакції системи, пропускна спроможність каналів зв'язку, інтенсивність трафіку в окремих сегментах мережі, імовірність спотворення даних, коефіцієнт готовності служб мережі. Результати такого аналізу дозволяють контролювати угоду про рівень обслуговування (Service Level Agreement, SLA).<br /> <br /> Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:<br /> <br /> *Повсюдність. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;<br /> <br /> *Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;<br /> <br /> *Стійкість у критичних ситуаціях. Наприклад, при перевантаженні і проблемах в мережі, тобто при множинних помилках.<br /> <br /> ==Архітектура==<br /> <br /> Архітектуру розподіленої системи можна описати в термінах обробних елементів (або компонентів), що з'єднують елементів (або з'єднувачів) і елементів даних. Перерахуємо складові елементи системи управління SNMP:<br /> <br /> 1. компоненти:<br /> <br /> *агент;<br /> <br /> *менеджер;<br /> <br /> 2. з'єднувачі:<br /> <br /> *транспортний протокол;<br /> <br /> *Протокольні блоки даних (Protocol Data Units, PDU) і повідомлення SNMP;<br /> <br /> 3. дані:<br /> <br /> *Керуюча інформація MIB;<br /> <br /> Опишемо детальніше і проаналізуємо архітектуру SNMP з позиції досягнення поставлених перед SNMP цілей. Для цього використовуємо поняття архітектурного стилю мережевого програмного забезпечення. Архітектурний стиль - це узгоджений набір архітектурних обмежень, накладених на ролі і особливості архітектурних елементів (компонентів, з'єднувачів і даних) і відносин між ними, яка проявляється у будь-якій архітектурі, і яка задовольняє цьому стилю.<br /> <br /> [[Засоби моніторингу та аналізу мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/SNMP 2011-12-18T00:34:03Z

<p>Aleksey: Замінено вміст на «{{subst:Шаблон:Портфоліо проекту}}»</p> <hr /> <div><br /> <br /> == Автор проекту ==<br /> <br /> == Назва проекту ==<br /> <br /> <br /> == Предмет, клас ==<br /> <br /> <br /> == Коротка анотація проекту ==<br /> <br /> <br /> == Спрямовуючі запитання ==<br /> <br /> ===''Ключове запитання''===<br /> <br /> ===''Тематичні запитання''===<br /> <br /> ===''Змістові запитання''===<br /> <br /> == Компетентності, які розвиває навчальний проект ==<br /> <br /> == Дидактичні цілі проекту ==<br /> <br /> ==Методичні завдання проекту ==<br /> <br /> ==Предметні області ==<br /> <br /> 1. Список<br /> <br /> # ...<br /> # ...<br /> <br /> 2. Карти &quot;Інтеграція предметів у навчальному проекті&quot;<br /> <br /> ''Карти навчальних проектів, виконані вчителями або обдарованими учнями в [http://bubbl.us/ Вubbl.us], за допомогою [[Freemind]], за допомогою [[графвіз]]а.<br /> <br /> <br /> == Публікація вчителя ==<br /> <br /> == Візитна картка проекту ==<br /> <br /> == Презентація вчителя для виявлення уявлень й інтересів учнів ==<br /> <br /> ==Самостійні дослідження учнів ==<br /> <br /> == Приклад продукту проектної діяльності учнів ==<br /> <br /> == Матеріали по формуючому й підсумковому оцінюванню ==<br /> <br /> == Матеріали по супроводу й підтримці проектної діяльності ==<br /> <br /> == Інші документи ==<br /> <br /> <br /> [[Категорія:Банк проектів]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/SNMP 2011-12-18T00:33:06Z

<p>Aleksey: </p> <hr /> <div>'''SNMP''' (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури [[TCP/IP]].<br /> <br /> ==Історія створення SNMP==<br /> <br /> Однією з найперших ініціатив з управління мережами була ініціатива ISO Open Systems Interconnection (OSI). Відповідні групи з стандартизації інфраструктури управління OSI (OSI Management Framework) були створені в 1981 році.<br /> <br /> До кінця 1980-х років мережа Інтернет стала досить великою і вимагала стандартів управління. Однак група ISO OSI була далека від завершення робіт над сімейством стандартів. Тому в 1987 році спільнотою IETF було прийнято рішення тимчасово створити набір спрощених стандартів управління в Інтернеті на основі напрацювань ISO OSI. Дані стандарти отримали назву Simple Network Management Protocol (SNMP). Надалі передбачалося перейти на стандарти ISO у міру їх готовності. Таким чином, багато ідей SNMP були взяті зі стандартів ISO:<br /> <br /> *Концепція «менеджер-агент»;<br /> <br /> *Ідея баз керуючої інформації (Management Information Bases, MIBs);<br /> <br /> *Використання синтаксису Abstract Syntax Notation One (ASN.1);<br /> <br /> *Частина термінології;<br /> <br /> Іншими проектом стандарту, на базі якого почалася розробка SNMP, був проект простого протоколу моніторингу шлюзів (Simple Gateway Monitoring Protocol, SGMP) співтовариства IETF.<br /> <br /> Надалі в рамках ISO OSI було запропоновано багато нових ідей, зокрема, об'єктно-орієнтований підхід. Однак ці ідеї вже не ввійшли в стандарти SNMP. Один час IETF продовжувала CMIP over TCP (CMOT), яка передбачала використання загального протоколу керуючої інформації (Common Management Information Protocol, CMIP) стека протоколів ISO OSI в стеку IETF TCP / IP. У 1992 році ця ініціатива була припинена у зв'язку з успіхом і поширеністю SNMP.<br /> <br /> Після багатьох засідань IAB (Internet Architecture Board) опублікував у квітні 1988 року епохальний RFC 1052: IAB Recommendations for the Development of Internet Network Management Standards, в якому закликав до якнайшвидшого створення елементів Простого Мережевого Управління (Simple Network Management).<br /> <br /> Багато ідей, що лежать сьогодні в основі SNMP, були запозичені у попередніх дослідженнях з моніторингу Internet-маршрутизаторів. І вже в серпні 1988 з'явилися три основні документа:<br /> <br /> *[http://tools.ietf.org/html/rfc1065 RFC 1065]: Structure and Identification of Management Information for TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]: Management Information Base for Network Management of TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]: A Simple Network Management Protocol.<br /> <br /> Згодом ці документи було перевидано і доповнено до визначення наступного покоління SNMP: RFC 1155, 1156 і 1157, які в свою чергу, також піддалися переробкам.<br /> <br /> Зрештою, у травні 1991 року була закінчена робота зі створення першої версії протоколу SNMPv1, яка знайшла своє відображення в зведенні таких документів:<br /> <br /> *[http://tools.ietf.org/html/rfc1155 RFC 1155]: Structure and Identification of Management Information for TCP / IP-based internets (Травень, 1990):<br /> - Визначає структуру керуючої інформації у вигляді глобального дерева.<br /> - Являє синтаксис визначення імен змінних управління.<br /> <br /> *[http://tools.ietf.org/html/rfc1212 RFC 1212]: Concise MIB Definitions (Березень, 1991)<br /> - Доповнює RFC 1155 в частині синтаксису визначення імен змінних.<br /> <br /> *[http://tools.ietf.org/html/rfc1213 RFC 1213]: Management Information Base for Network Management of TCP / IP-based internets: MIB-II (Березень, 1991):<br /> - Містить список більше ста найбільш необхідних змінних, що відповідають за конфігурацію, статус і статистику систем, що входять в TCP / IP мережі.<br /> <br /> *[http://tools.ietf.org/html/rfc1157 RFC 1157]: A Simple Network Management Protocol (SNMP) (Травень, 1990)<br /> - Визначає повідомлення, якими обмінюються керуюча станція і об'єкт управління для отримання та оновлення значення змінних.<br /> - Визначає trap (alarm)-повідомлення, що посилаються системою при значних змінах у її конфігурації.<br /> <br /> Опублікування цих стандартів стало поштовхом для виробників мережного обладнання, які розгорнули широкі роботи із забезпечення керованості:<br /> <br /> *всього спектра мережного обладнання - мостів, маршрутизаторів, модемів ...<br /> <br /> *широкого кола інтерфейсів - Point-to-Point, DS1, DS3, X.25, Frame Relay, Ethernet, Token Ring, FDDI, та ін.<br /> <br /> В загальному, стандарти SNMP продовжували розвиватися протягом 1990-х років. Основним напрямком розвитку було вдосконалення питань безпеки. Були розроблені наступні версії SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u і SNMPv3. Їх обговорення буде продовжено в розділі «Версії SNMP».<br /> <br /> ==Задачі==<br /> <br /> Сімейство стандартів SNMP створено для вирішення задач обробки помилок і аналізу продуктивності і надійності.<br /> <br /> '''Обробка помилок'''<br /> <br /> Виявлення, визначення і усунення наслідків збоїв і відмов у роботі мережі. На цьому рівні виконується реєстрація повідомлень про помилки, їх фільтрація, маршрутизація і аналіз на основі деякої кореляційної моделі.<br /> <br /> '''Аналіз продуктивності і надійності'''<br /> <br /> Оцінка на основі статистичної інформації таких параметрів, як час реакції системи, пропускна спроможність каналів зв'язку, інтенсивність трафіку в окремих сегментах мережі, імовірність спотворення даних, коефіцієнт готовності служб мережі. Результати такого аналізу дозволяють контролювати угоду про рівень обслуговування (Service Level Agreement, SLA).<br /> <br /> Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:<br /> <br /> *Повсюдність. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;<br /> <br /> *Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;<br /> <br /> *Стійкість у критичних ситуаціях. Наприклад, при перевантаженні і проблемах в мережі, тобто при множинних помилках.<br /> <br /> ==Архітектура==<br /> <br /> Архітектуру розподіленої системи можна описати в термінах обробних елементів (або компонентів), що з'єднують елементів (або з'єднувачів) і елементів даних. Перерахуємо складові елементи системи управління SNMP:<br /> <br /> 1. компоненти:<br /> <br /> *агент;<br /> <br /> *менеджер;<br /> <br /> 2. з'єднувачі:<br /> <br /> *транспортний протокол;<br /> <br /> *Протокольні блоки даних (Protocol Data Units, PDU) і повідомлення SNMP;<br /> <br /> 3. дані:<br /> <br /> *Керуюча інформація MIB;<br /> <br /> Опишемо детальніше і проаналізуємо архітектуру SNMP з позиції досягнення поставлених перед SNMP цілей. Для цього використовуємо поняття архітектурного стилю мережевого програмного забезпечення. Архітектурний стиль - це узгоджений набір архітектурних обмежень, накладених на ролі і особливості архітектурних елементів (компонентів, з'єднувачів і даних) і відносин між ними, яка проявляється у будь-якій архітектурі, і яка задовольняє цьому стилю.<br /> <br /> [[Засоби моніторингу та аналізу мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/SNMP 2011-12-18T00:32:03Z

<p>Aleksey: </p> <hr /> <div><br /> <br /> == Автор проекту ==<br /> <br /> == Назва проекту ==<br /> <br /> <br /> == Предмет, клас ==<br /> <br /> <br /> == Коротка анотація проекту ==<br /> <br /> <br /> == Спрямовуючі запитання ==<br /> <br /> ===''Ключове запитання''===<br /> <br /> ===''Тематичні запитання''===<br /> <br /> ===''Змістові запитання''===<br /> <br /> == Компетентності, які розвиває навчальний проект ==<br /> <br /> == Дидактичні цілі проекту ==<br /> <br /> ==Методичні завдання проекту ==<br /> <br /> ==Предметні області ==<br /> <br /> 1. Список<br /> <br /> # ...<br /> # ...<br /> <br /> 2. Карти &quot;Інтеграція предметів у навчальному проекті&quot;<br /> <br /> ''Карти навчальних проектів, виконані вчителями або обдарованими учнями в [http://bubbl.us/ Вubbl.us], за допомогою [[Freemind]], за допомогою [[графвіз]]а.<br /> <br /> <br /> == Публікація вчителя ==<br /> <br /> == Візитна картка проекту ==<br /> <br /> == Презентація вчителя для виявлення уявлень й інтересів учнів ==<br /> <br /> ==Самостійні дослідження учнів ==<br /> <br /> == Приклад продукту проектної діяльності учнів ==<br /> <br /> == Матеріали по формуючому й підсумковому оцінюванню ==<br /> <br /> == Матеріали по супроводу й підтримці проектної діяльності ==<br /> <br /> == Інші документи ==<br /> <br /> <br /> [[Категорія:Банк проектів]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/SNMP 2011-12-18T00:31:22Z

<p>Aleksey: Сторінка очищена</p> <hr /> <div></div>

Aleksey https://wiki.cusu.edu.ua/index.php/%D0%9A%D0%BE%D1%80%D0%B8%D1%81%D1%82%D1%83%D0%B2%D0%B0%D1%87:Aleksey 2011-12-18T00:25:28Z

<p>Aleksey: </p> <hr /> <div>Новіков Олексій<br /> <br /> 64 група</div>

Aleksey https://wiki.cusu.edu.ua/index.php/SNMP 2011-12-18T00:10:55Z

<p>Aleksey: </p> <hr /> <div>'''SNMP''' (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури [[TCP/IP]].<br /> <br /> ==Історія створення SNMP==<br /> <br /> Однією з найперших ініціатив з управління мережами була ініціатива ISO Open Systems Interconnection (OSI). Відповідні групи з стандартизації інфраструктури управління OSI (OSI Management Framework) були створені в 1981 році.<br /> <br /> До кінця 1980-х років мережа Інтернет стала досить великою і вимагала стандартів управління. Однак група ISO OSI була далека від завершення робіт над сімейством стандартів. Тому в 1987 році спільнотою IETF було прийнято рішення тимчасово створити набір спрощених стандартів управління в Інтернеті на основі напрацювань ISO OSI. Дані стандарти отримали назву Simple Network Management Protocol (SNMP). Надалі передбачалося перейти на стандарти ISO у міру їх готовності. Таким чином, багато ідей SNMP були взяті зі стандартів ISO:<br /> <br /> *Концепція «менеджер-агент»;<br /> <br /> *Ідея баз керуючої інформації (Management Information Bases, MIBs);<br /> <br /> *Використання синтаксису Abstract Syntax Notation One (ASN.1);<br /> <br /> *Частина термінології;<br /> <br /> Іншими проектом стандарту, на базі якого почалася розробка SNMP, був проект простого протоколу моніторингу шлюзів (Simple Gateway Monitoring Protocol, SGMP) співтовариства IETF.<br /> <br /> Надалі в рамках ISO OSI було запропоновано багато нових ідей, зокрема, об'єктно-орієнтований підхід. Однак ці ідеї вже не ввійшли в стандарти SNMP. Один час IETF продовжувала CMIP over TCP (CMOT), яка передбачала використання загального протоколу керуючої інформації (Common Management Information Protocol, CMIP) стека протоколів ISO OSI в стеку IETF TCP / IP. У 1992 році ця ініціатива була припинена у зв'язку з успіхом і поширеністю SNMP.<br /> <br /> Після багатьох засідань IAB (Internet Architecture Board) опублікував у квітні 1988 року епохальний RFC 1052: IAB Recommendations for the Development of Internet Network Management Standards, в якому закликав до якнайшвидшого створення елементів Простого Мережевого Управління (Simple Network Management).<br /> <br /> Багато ідей, що лежать сьогодні в основі SNMP, були запозичені у попередніх дослідженнях з моніторингу Internet-маршрутизаторів. І вже в серпні 1988 з'явилися три основні документа:<br /> <br /> *[http://tools.ietf.org/html/rfc1065 RFC 1065]: Structure and Identification of Management Information for TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]: Management Information Base for Network Management of TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]: A Simple Network Management Protocol.<br /> <br /> Згодом ці документи було перевидано і доповнено до визначення наступного покоління SNMP: RFC 1155, 1156 і 1157, які в свою чергу, також піддалися переробкам.<br /> <br /> Зрештою, у травні 1991 року була закінчена робота зі створення першої версії протоколу SNMPv1, яка знайшла своє відображення в зведенні таких документів:<br /> <br /> *[http://tools.ietf.org/html/rfc1155 RFC 1155]: Structure and Identification of Management Information for TCP / IP-based internets (Травень, 1990):<br /> - Визначає структуру керуючої інформації у вигляді глобального дерева.<br /> - Являє синтаксис визначення імен змінних управління.<br /> <br /> *[http://tools.ietf.org/html/rfc1212 RFC 1212]: Concise MIB Definitions (Березень, 1991)<br /> - Доповнює RFC 1155 в частині синтаксису визначення імен змінних.<br /> <br /> *[http://tools.ietf.org/html/rfc1213 RFC 1213]: Management Information Base for Network Management of TCP / IP-based internets: MIB-II (Березень, 1991):<br /> - Містить список більше ста найбільш необхідних змінних, що відповідають за конфігурацію, статус і статистику систем, що входять в TCP / IP мережі.<br /> <br /> *[http://tools.ietf.org/html/rfc1157 RFC 1157]: A Simple Network Management Protocol (SNMP) (Травень, 1990)<br /> - Визначає повідомлення, якими обмінюються керуюча станція і об'єкт управління для отримання та оновлення значення змінних.<br /> - Визначає trap (alarm)-повідомлення, що посилаються системою при значних змінах у її конфігурації.<br /> <br /> Опублікування цих стандартів стало поштовхом для виробників мережного обладнання, які розгорнули широкі роботи із забезпечення керованості:<br /> <br /> *всього спектра мережного обладнання - мостів, маршрутизаторів, модемів ...<br /> <br /> *широкого кола інтерфейсів - Point-to-Point, DS1, DS3, X.25, Frame Relay, Ethernet, Token Ring, FDDI, та ін.<br /> <br /> В загальному, стандарти SNMP продовжували розвиватися протягом 1990-х років. Основним напрямком розвитку було вдосконалення питань безпеки. Були розроблені наступні версії SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u і SNMPv3. Їх обговорення буде продовжено в розділі «Версії SNMP».<br /> <br /> ==Задачі==<br /> <br /> Сімейство стандартів SNMP створено для вирішення задач обробки помилок і аналізу продуктивності і надійності.<br /> <br /> '''Обробка помилок'''<br /> <br /> Виявлення, визначення і усунення наслідків збоїв і відмов у роботі мережі. На цьому рівні виконується реєстрація повідомлень про помилки, їх фільтрація, маршрутизація і аналіз на основі деякої кореляційної моделі.<br /> <br /> '''Аналіз продуктивності і надійності'''<br /> <br /> Оцінка на основі статистичної інформації таких параметрів, як час реакції системи, пропускна спроможність каналів зв'язку, інтенсивність трафіку в окремих сегментах мережі, імовірність спотворення даних, коефіцієнт готовності служб мережі. Результати такого аналізу дозволяють контролювати угоду про рівень обслуговування (Service Level Agreement, SLA).<br /> <br /> Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:<br /> <br /> *Повсюдність. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;<br /> <br /> *Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;<br /> <br /> *Стійкість у критичних ситуаціях. Наприклад, при перевантаженні і проблемах в мережі, тобто при множинних помилках.<br /> <br /> ==Архітектура==<br /> <br /> Архітектуру розподіленої системи можна описати в термінах обробних елементів (або компонентів), що з'єднують елементів (або з'єднувачів) і елементів даних. Перерахуємо складові елементи системи управління SNMP:<br /> <br /> 1. компоненти:<br /> <br /> *агент;<br /> <br /> *менеджер;<br /> <br /> 2. з'єднувачі:<br /> <br /> *транспортний протокол;<br /> <br /> *Протокольні блоки даних (Protocol Data Units, PDU) і повідомлення SNMP;<br /> <br /> 3. дані:<br /> <br /> *Керуюча інформація MIB;<br /> <br /> Опишемо детальніше і проаналізуємо архітектуру SNMP з позиції досягнення поставлених перед SNMP цілей. Для цього використовуємо поняття архітектурного стилю мережевого програмного забезпечення. Архітектурний стиль - це узгоджений набір архітектурних обмежень, накладених на ролі і особливості архітектурних елементів (компонентів, з'єднувачів і даних) і відносин між ними, яка проявляється у будь-якій архітектурі, і яка задовольняє цьому стилю.<br /> <br /> [[Засоби моніторингу та аналізу мережі]]</div>

Aleksey https://wiki.cusu.edu.ua/index.php/SNMP 2011-12-18T00:03:48Z

<p>Aleksey: </p> <hr /> <div>'''SNMP''' (англ. Simple Network Management Protocol — простий протокол керування мережею) — це протокол керування мережами зв'язку на основі архітектури [[TCP/IP]].<br /> <br /> ==Історія створення SNMP==<br /> <br /> Однією з найперших ініціатив з управління мережами була ініціатива ISO Open Systems Interconnection (OSI). Відповідні групи з стандартизації інфраструктури управління OSI (OSI Management Framework) були створені в 1981 році.<br /> <br /> До кінця 1980-х років мережа Інтернет стала досить великою і вимагала стандартів управління. Однак група ISO OSI була далека від завершення робіт над сімейством стандартів. Тому в 1987 році спільнотою IETF було прийнято рішення тимчасово створити набір спрощених стандартів управління в Інтернеті на основі напрацювань ISO OSI. Дані стандарти отримали назву Simple Network Management Protocol (SNMP). Надалі передбачалося перейти на стандарти ISO у міру їх готовності. Таким чином, багато ідей SNMP були взяті зі стандартів ISO:<br /> <br /> *Концепція «менеджер-агент»;<br /> <br /> *Ідея баз керуючої інформації (Management Information Bases, MIBs);<br /> <br /> *Використання синтаксису Abstract Syntax Notation One (ASN.1);<br /> <br /> *Частина термінології;<br /> <br /> Іншими проектом стандарту, на базі якого почалася розробка SNMP, був проект простого протоколу моніторингу шлюзів (Simple Gateway Monitoring Protocol, SGMP) співтовариства IETF.<br /> <br /> Надалі в рамках ISO OSI було запропоновано багато нових ідей, зокрема, об'єктно-орієнтований підхід. Однак ці ідеї вже не ввійшли в стандарти SNMP. Один час IETF продовжувала CMIP over TCP (CMOT), яка передбачала використання загального протоколу керуючої інформації (Common Management Information Protocol, CMIP) стека протоколів ISO OSI в стеку IETF TCP / IP. У 1992 році ця ініціатива була припинена у зв'язку з успіхом і поширеністю SNMP.<br /> <br /> Після багатьох засідань IAB (Internet Architecture Board) опублікував у квітні 1988 року епохальний RFC 1052: IAB Recommendations for the Development of Internet Network Management Standards, в якому закликав до якнайшвидшого створення елементів Простого Мережевого Управління (Simple Network Management).<br /> <br /> Багато ідей, що лежать сьогодні в основі SNMP, були запозичені у попередніх дослідженнях з моніторингу Internet-маршрутизаторів. І вже в серпні 1988 з'явилися три основні документа:<br /> <br /> *[http://tools.ietf.org/html/rfc1065 RFC 1065]: Structure and Identification of Management Information for TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1066 RFC 1066]: Management Information Base for Network Management of TCP / IP-based internets.<br /> <br /> *[http://tools.ietf.org/html/rfc1067 RFC 1067]: A Simple Network Management Protocol.<br /> <br /> Згодом ці документи було перевидано і доповнено до визначення наступного покоління SNMP: RFC 1155, 1156 і 1157, які в свою чергу, також піддалися переробкам.<br /> <br /> Зрештою, у травні 1991 року була закінчена робота зі створення першої версії протоколу SNMPv1, яка знайшла своє відображення в зведенні таких документів:<br /> <br /> *[http://tools.ietf.org/html/rfc1155 RFC 1155]: Structure and Identification of Management Information for TCP / IP-based internets (Травень, 1990):<br /> - Визначає структуру керуючої інформації у вигляді глобального дерева.<br /> - Являє синтаксис визначення імен змінних управління.<br /> <br /> *[http://tools.ietf.org/html/rfc1212 RFC 1212]: Concise MIB Definitions (Березень, 1991)<br /> - Доповнює RFC 1155 в частині синтаксису визначення імен змінних.<br /> <br /> *[http://tools.ietf.org/html/rfc1213 RFC 1213]: Management Information Base for Network Management of TCP / IP-based internets: MIB-II (Березень, 1991):<br /> - Містить список більше ста найбільш необхідних змінних, що відповідають за конфігурацію, статус і статистику систем, що входять в TCP / IP мережі.<br /> <br /> *[http://tools.ietf.org/html/rfc1157 RFC 1157]: A Simple Network Management Protocol (SNMP) (Травень, 1990)<br /> - Визначає повідомлення, якими обмінюються керуюча станція і об'єкт управління для отримання та оновлення значення змінних.<br /> - Визначає trap (alarm)-повідомлення, що посилаються системою при значних змінах у її конфігурації.<br /> <br /> Опублікування цих стандартів стало поштовхом для виробників мережного обладнання, які розгорнули широкі роботи із забезпечення керованості:<br /> <br /> *всього спектра мережного обладнання - мостів, маршрутизаторів, модемів ...<br /> <br /> *широкого кола інтерфейсів - Point-to-Point, DS1, DS3, X.25, Frame Relay, Ethernet, Token Ring, FDDI, та ін.<br /> <br /> В загальному, стандарти SNMP продовжували розвиватися протягом 1990-х років. Основним напрямком розвитку було вдосконалення питань безпеки. Були розроблені наступні версії SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u і SNMPv3. Їх обговорення буде продовжено в розділі «Версії SNMP».<br /> <br /> ==Задачі==<br /> <br /> Сімейство стандартів SNMP створено для вирішення задач обробки помилок і аналізу продуктивності і надійності.<br /> <br /> '''Обробка помилок'''<br /> <br /> Виявлення, визначення і усунення наслідків збоїв і відмов у роботі мережі. На цьому рівні виконується реєстрація повідомлень про помилки, їх фільтрація, маршрутизація і аналіз на основі деякої кореляційної моделі.<br /> <br /> '''Аналіз продуктивності і надійності'''<br /> <br /> Оцінка на основі статистичної інформації таких параметрів, як час реакції системи, пропускна спроможність каналів зв'язку, інтенсивність трафіку в окремих сегментах мережі, імовірність спотворення даних, коефіцієнт готовності служб мережі. Результати такого аналізу дозволяють контролювати угоду про рівень обслуговування (Service Level Agreement, SLA).<br /> <br /> Згідно з ідеологією SNMP, управління повинне бути простим, нехай навіть ціною втрати потужності, масштабованості і захищеності. Тому при розробці стандартів SNMP враховувалися наступні умови:<br /> <br /> *Повсюдність. Системи під управлінням SNMP можуть бути будь-якими і можуть бути скрізь: від принтерів до мейнфреймів;<br /> <br /> *Простота додавання керуючих функцій. Керована система обмежена в функціональності управління, дуже проста і не може контролювати себе. Замість цього всі керовані системи контролює складна керуюча система, функціональність якої можна розширювати;<br /> <br /> *Стійкість у критичних ситуаціях. Наприклад, при перевантаженні і проблемах в мережі, тобто при множинних помилках.<br /> <br /> ==Архітектура==<br /> <br /> Архітектуру розподіленої системи можна описати в термінах обробних елементів (або компонентів), що з'єднують елементів (або з'єднувачів) і елементів даних. Перерахуємо складові елементи системи управління SNMP:<br /> <br /> *компоненти:<br /> агент;<br /> <br /> *менеджер;<br /> <br /> *з'єднувачі:<br /> <br /> *транспортний протокол;<br /> <br /> *Протокольні блоки даних (Protocol Data Units, PDU) і повідомлення SNMP;<br /> <br /> *дані<br /> <br /> *Керуюча інформація MIB;<br /> <br /> Опишемо детальніше і проаналізуємо архітектуру SNMP з позиції досягнення поставлених перед SNMP цілей. Для цього використовуємо поняття архітектурного стилю мережевого програмного забезпечення. Архітектурний стиль - це узгоджений набір архітектурних обмежень, накладених на ролі і особливості архітектурних елементів (компонентів, з'єднувачів і даних) і відносин між ними, яка проявляється у будь-якій архітектурі, і яка задовольняє цьому стилю.<br /> <br /> [[Засоби моніторингу та аналізу мережі]]</div>

Aleksey