Инструменти за анализ и управление на мрежи, стандарти, системи за управление

Следваща SNMP стандарт определя формат съответно GetRequest-PDU единични променливи. Променлива ID Заявка - е 4 байта цяло число (използва се за да съответства на заявката за отговор), ErrorStatus и Errorlndex - това байтове числа които заявката трябва да бъде 0. VarBindList - списък на цифровите имена на обекти, чиито стойности интерес мениджър. нотацията на ASN.1 Този списък се състои от двойки "име - стойност". При искане на променливата трябва да бъде настроен на нула.

Ето един пример на SNMP съобщения, което е искане за стойността на обекта SysDescr (с цифри име 1.3.6.1.2.1.1.1).

Както се вижда от описанието, съобщение започва с код 30 (всички шестнадесетичен кодове), което съответства на ключовата дума секвенция (последователност). Дължината на последователност е показана в следващия байт (41 байта). Това, което следва е цяло число от 1 байт - версия на протокола SNMP (в този случай около, т.е. SNMP v.l, на 1 би означавало, SNMP v.2). поле общност е от тип низ (символен низ) дължина 6 байта от обществения стойност. В останалата част от съобщението е блок GetRequest-PDU данни на. Фактът, че тази операция е Get-заявка, твърдят код AB (това е определено в протокола SNMP, а не в нотация ASN.1) и общата дължина на данните - 28 байта. В съответствие с структурата Getrequest-PDU единица. допълнително има идентификатор на искане (дефинирани като цяло число от 4 байта). След това, в блока, последван от два байта числа статус и индекс грешка, че заявката се на 0. И накрая, допълни списъкът с обекти съобщение, състоящо се от един чифт - име 1.3.6.1.2.1.1.1.0 и нулевата стойност.

Най-новото допълнение към функционалността SNMP е RMON спецификация, която осигурява взаимодействие с дистанционно база MIB. Преди появата на SNMP RMON протокол не може да се използва от разстояние, тя позволява само локални устройства за контрол. База RMON MIB има подобрена набор от имоти за дистанционно управление, тъй като тя съдържа информация за обобщена устройство без да се изисква предаване на големи количества данни мрежа. RMON MIB обекти включват допълнителни гишета за грешки в пакети, по-гъвкави средства за анализ на тенденциите и статистиката, по-мощен филтриране средства за улавяне и анализ на индивидуалните пакети, както и по-сложни условия за установяване на предупредителните сигнали. Представители RMON MIB-интелигентни сравнение с агенти MIB-I или MIB-II и изпълнява голяма част от работата на устройството за обработка на информация, която се извършва преди мениджърите. Тези средства могат да бъдат разположени в различни комуникационни устройства, както и да бъдат приложени като отделни софтуерни модули, работещи на общо предназначение персонални компютри и лаптопи.

RMON обект като се има предвид броя 16 в набора от MIB обекти, а съоръжението RMON включва 10 групи от тези обекти.

Статистика - сегашните натрупаните статистически данни за характеристиките на опаковки, броят на сблъсъци и др ...

История - статистическите данни, съхранявани на редовни интервали за анализ на тенденциите във времето.

Аларми - статистика прагове, над които RMON агент изпраща съобщение до управителя.

HostTopN - маса от най-натоварените Домакините на мрежата.

Трафик Matrix - Статистически данни за интензивността на трафика между всяка двойка мрежови Силите, подредени в матрица.

Филтър - условията за филтриране на пакети.

Packet Capture - условия за улавяне на пакети.

Събитие - условия за регистрация и генериране на събитие.

Тези групи са номерирани с цел, следователно, например, група с Силите цифров име 1.3.6.1.2.1.16.4.

Десетият група се състои от специални предмети Token Ring протокол.

Всички стандарт RMON MIB определя на около 200 съоръжения в 10 групи, определени в два документа - RFC 1271 за Ethernet мрежи и RFC 1513 за Token Ring мрежи.

Отличителна черта на RMON MIB стандарт е неговата независимост от мрежовия протокол слой (за разлика от стандартите за MIB-I и MIB-II се фокусира върху TCP / IP протоколи). Следователно, той е подходящ за хетерогенни среди, които използват различни протоколи мрежа слой.

Помислете за по-подробно Статистика група. който определя каква информация за рамки (посочени в стандартния комплект) Ethernet може да осигури RMON агент. История Group е основана на групови обекти статистиката. защото неговите съоръжения позволяват да се изгради динамичен ред Статистика за групата на обектите.

В групата Статистика включва, заедно с някои от следните други обекти.

etherStatsDropEvents - общия брой на събитията, в които пакети бяха игнорирани от агента, поради липсата на ресурси. Самите торбички в същото време не са били непременно загубили интерфейс.

etherStatsOrtets - на общия брой байтове (включително лоши пакети), получени от мрежата (с изключение на преамбюла н включително байт контролна).

etherStatsPkts - общият брой на пакети (включително грешка).

etherStatsCRCAlign грешки - общият брой на пакетите, получени че имаше дължина (с изключение на преамбюла) между 64 и 1518 октета, не съдържат цяло число брой байтове (грешка изравняване) или имат лоша контролна (FCS грешка).

etherStatsUndersizePkts - общият брой на опаковките, които са с дължина по-малко от 64 байта, но са правилно оформени.

etherStatsOversizePkts - общият брой на опаковките, които са с дължина по-голяма от 1518 байта, но въпреки това са правилно форматирани.

etherStatsFragments - общият брой на пакети, които не се състоят от неразделна брой байтове, или са останали с лоши контролна и разполагат също с дължина по-малко от 64 байта.

etherStatsJabbers - общият брой на пакети, които не се състоят от неразделна брой байтове, или са останали с лоши контролна и разполагат също с дължина по-голяма от 1518 байта.

etherStatsCollisions - най-добрата приблизителна оценка на броя на сблъсъци по този Ethernet сегмент.

etherStatsPkts640ctets - общият брой на пакети (включително лошо) от 64 байта.

etherStatsPkts65to1270ctets - общият брой на пакети (включително лошо) с площ от 65 до 127 байта.

etherStatsPktsl28to2550ctets - общият брой на пакети (включително лошо) с площ от 128 до 255 байта.

etherStatsPkts256to5110ctets - общият брой на пакети (включително лошо) с площ от 256 до 511 байта.

etherStatsPkts512tol0230ctets - общият брой на пакети (включително лошо), вариращи по размер от 512 до 1023 байта.

etherStatsPktsl024tol5180ctets - общият брой на пакети (включително лошо), вариращи по размер от 1024 до 1518 байта.

Както се вижда от описанието на обекта, като се използват RMON агент вграден в усилвателя, или друго средство за комуникация, може да се направи много подробен анализ на Ethernet сегмент или Fast Ethernet. Първо, можете да получите информация за грешките, възникнали във вида сегмент в рамки, а след това е препоръчително да се събира с помощта на исторически Група на интензитета на тези грешки от време на време (включително и обвързването им в момента). След анализ на времето зависимостта често може да има някои предварителни изводи за източника на грешни кадри и на тази основа да се формулира по-тънка рамкови условия за улавяне със специфични характеристики (условия определящи Филтър група), съответстващи разширена версия. След това можете да прекарате още по-задълбочен анализ чрез разглеждане на заснетите кадри, извличането им от обекти Packet Capture група.

RMON 2 стандарт по-късно е приет, който се простира на MIB RMON интелектуални идеи в горните нива на протоколи, извършване на анализаторите работа протокол.

Протоколът SNMP е в основата на много от системите за управление, въпреки че има няколко основни пропуски, които са изброени по-долу.

Липса на средства за взаимно удостоверяване агенти и мениджъри. Единственият инструмент, който може да се дължи на средствата за удостоверяване е използването на съобщенията на така наречените "обществени струни» - «низ общност». Тази поредица е изпратено по мрежата в открита форма в съобщението SNMP и служи като основа за разделянето на агенти и мениджъри в "общността", така че агентът взаимодейства с само онези мениджъри, които показват в областта на низ общност от една и съща поредица от букви, като низ съхранява в памет агент. Това със сигурност не е метод за идентификация, както и метода на структуриращите агенти и мениджъри. SNMP v.2 версия е трябвало да бъде премахнато това неблагоприятно, но в резултат на разногласия между разработчиците на нови стандартни средства за идентификация, въпреки че се появява в тази версия, но задължително.

Работа чрез UDP ненадежден протокол (това е най-голямата част от делата за изпълнение SNMP агенти) води до загуба на аларми (капан съобщения) от агент на управителя, което може да доведе до лошо управление. Възстановяване на положението, като премине към надежден транспорт протокол е връзка ориентирана комуникация е изпълнен със загубата на огромно количество вградени SNMP агенти на разположение в резултат на мрежово оборудване. (CMIP протокол първоначално работи над надежден транспорт на стека OSI, и този недостатък не е засегната.) Платформи за управление на разработчиците се опитват да преодолеят тези недостатъци. Така например, в платформата HP 0V Telecom DM TMN, която е платформа за развитието на многостепенно управление в съответствие с TMN и ISO стандарти, прави нов изпълнението SNMP, организиране на надеждна съобщения между агенти и мениджъри за сметка на самоорганизация на препредаването на SNMP съобщения с техните загуби.