Сетевая диагностика с помощью SNMP и ICMP

Обслуживание и диагностирование больших многосегментных, многопротокольных сетей, размещенных на большой территории, а в некоторых случаях и в нескольких городах (например, корпоративные сети типа Интранет), представляет собой определенную проблему.

Так как сеть может быть построена с применением различных физических сред и протоколов, наиболее привлекательным, если не единственным, средством диагностики представляется протокол SNMP, который служит для целей управления в Ethernet, ISDN, X.25, FDDI, ATM, SDH, TCP/IP и других сетях. Протокол SNMP ( std15, RFC- 1448, -1592, -1901, 1902-1907, 1908-1910, -3411-18, std0062 ) использует управляющую базу данных MIB (RFC- 1213, - 1158, -1792, -1042; std16, std17 ), доступ к которой определяется администратором локальной сети или конкретной ЭВМ (ссылки, выделенные полужирным шрифтом, являются стандартами Интернет). Чтобы база данных была доступна, необходимо наличие snmp -демона. Рассмотрим сеть, изображенную на рис. 10.1.

Рис. 10.1. Пример диагностируемой сети

Для диагностики сегмента, непосредственно связанного с ЭВМ-тестером, можно использовать режим 6 Ethernet-интерфейса ЭВМ-тестера. Этот режим, при котором принимаются все пакеты, следующие по сегменту, позволяет регистрировать распределение пакетов по адресам отправителя и получателя, протоколам, длинам пакетов и т.д.. Запуская определенные программы на ЭВМ 1 или 2 (сегмент С-1), можно получить исчерпывающую информацию о состоянии сегмента. Этот способ диагностики не пригоден для сегментов, к которым подключены ЭВМ 3 (сегмент С-2), 4 и 5 (сегмент С-3). В случае, если все ЭВМ сети поддерживают протокол TCP/IP, возможно применение для целей диагностики протокола ICMP (RFC- 1256, -1788, -1885, -792). Этот протокол, так же, как и SNMP, пригоден для диагностики не только локальной сети, но и каналов Интернет. Если использовать ICMP не только для трассировки маршрутов, но и для измерения процента испорченных пакетов, можно получить весьма полезную информацию, например, о DoS-атаке или ухудшении ситуации в отдельных сетевых сегментах. Но применение ICMP ограничено ЭВМ, поддерживающими протоколы Интернет, да и получаемые данные весьма не обширны.

Следует иметь в виду, что в многопротокольных средах структуры MIB могут заметно отличаться, варьируется несколько и формат SNMP -пакетов. В настоящее время существует достаточно большой выбор коммерческих программ сетевой SNMP -диагностики. Особую ценность представляют аппаратно-программные комплексы, которые способны диагностировать состояние оборудования и кабельных сегментов.

Сеть ИТЭФ, которая была зарегистрирована в качестве узла Интернет в 1991 году, в настоящее время содержит более 1000 ЭВМ при суммарной длине кабельных сегментов около 15 км. Проблема диагностики такой сети достаточно актуальна. Мы сначала использовали традиционные программные средства типа ping, traceroute, netstat, arp, snmpi, dig, hosts, nslookup, ifconfig, ripquery, поставляемые со многими сетевыми пакетами. Позднее пытались адаптировать общедоступные диагностические средства типа: netwatch, snmpman, netguard, ws_watch. Среди наиболее часто встречающихся проблем: разрывы кабельных сегментов, несанкционированное применение IP-адресов, некачественное питание сетевого оборудования, отказы тех или иных устройств.

Не все ЭВМ имеют активные SNMP -резиденты, это происходит по причине экономии оперативной памяти или по соображениям безопасности. Но для контроля ситуации достаточно иметь по одному активному SNMP -резиденту на каждом из кабельных сегментов. При этом не обязательно ставить их в общедоступный режим, можно использовать для получения диагностической информации и пароль.

При написании диагностической программы не нужно пытаться считывать все переменные и таблицы MIB. База данных весьма велика, и для целей диагностики не все ее записи представляют интерес. Для написания нашей диагностической программы были отобраны 35 переменных (ниже приводится сокращенный список):

Выбор определялся тем, что именно эти переменные варьируются динамически в течение суток. Ставилась задача исследования временных вариаций потоков в заданном сегменте и выработки критериев для диагностики потенциально опасных ситуаций. Измерения проводились каждые полчаса в течение недели.

Многие переменные базы MIB не меняются или меняются незначительно, но определяют режим работы и состояние ЭВМ-сервера. Так, переменная snmpinbadcommunityuses { snmp 5} может сообщить о попытках несанкционированного доступа к базе MIB. Переменные snmpintoobigs { snmp 8}, snmpingenerrs { snmp 12} или ifadminstatus {ifentry 7} и многие другие характеризуют текущее состояние системы, и длительное их отслеживание чаще всего не дает полезной информации. Другие переменные, например, ipnettomedianetaddress {ip 22}, ipnettomediaentry или iproutedest и т.д., полезно контролировать при серьезных сбоях и сравнивать их с эталонными значениями. Некоторые переменные важны при анализе эффективности системы, например, ipfragcreate {ip 19} или ipfragfails {ip 18}, — последняя переменная говорит о том, сколько встретилось пакетов с флагом, запрещающим фрагментацию, в условиях, когда она необходима, что может свидетельствовать о неверном выборе MTU.

Рассмотрим средние значения некоторых переменных за сутки. Так, переменные ip.ipinreceives=1379552, ifentryifinucastpkts=1278232, ifentry.ifinnunicastpkts=5083 характеризуют средний поток пакетов на входе сетевого интерфейса. Видно, что широковещательные и мультикастинг-пакеты составляют малую долю потока, что и следует ожидать. Большой поток пакетов типа nonunicast обычно говорит о неисправности в сети. Величины ifentry.ifoutunicastpkts=1369809 и ifentry.ifoutnunicastpkts=90 характеризуют выходной поток пакетов, соотношение обычных и nonunicast-пакетов и здесь нормальное. Сравнимое их значение говорило бы о неисправности сетевого интерфейса данной ЭВМ или о порче сетевого программного драйвера. Блок переменных ip.ipinhdrerrors=8, icmp.icmpouterrors=45, icmp.icmpoutdestunreachs=22 и ifentry.ifinunknownprotos=81 указывает на число сбоев в сети; если соотнести эти цифры с входным и выходным потоками пакетов, можно сделать вывод о благополучии в данном кабельном сегменте, во всяком случае на протяжении данных суток. Такие ошибки возможны из-за всплеска шумов или наводок (например, по сети переменного тока или в результате грозы). Определенное беспокойство может вызвать значение icmpoutdestunreachs, но это может быть результатом работы программы ping или traceroute для недоступного узла или опечатка в IP-адресе. Переменная icmp.icmpinsrcquenchs=19 весьма важна, так как она отмечает случаи перегрузки. В данном случае таких ситуаций за сутки было мало. Отслеживая эту переменную для разных ЭВМ, можно выявить слабые элементы в сети и скорректировать их параметры (например, увеличить буферную память). Переменные tcp.tcpinsegs=762696, tcp.tcpoutsegs=803676 и tcp.tcpretranssegs=3554 говорят о потоках TCP-пакетов (главного транспортного средства Интернет). Число tcpretranssegs характеризует надежность и правильность настойки параметров сети: чем меньше это число, тем лучше. udp.udpindatagrams=378119, udp.udpoutdatagrams=59429 указывают на входной и выходной потоки UDP-дейтограмм (сравните с потоками TCP-сегментов). Запись в MIB udp.udpnoports является важным диагностическим показателем. Переменные, регистрирующие число тех или иных ошибок и не упомянутые в этом абзаце, оказались равными нулю. Количество пакетов snmp в точности совпадает с их числом, посланным и полученным данной программой-тестером, что говорит об отсутствии какой-либо другой SNMP -активности. Контролировать это время от времени также полезно из соображений сетевой безопасности.

увеличить изображение
Рис. 10.2. Вариации tcpinsegs и udpindatagrams в течение недели