- •Вступление
- •Основные задачи технической диагностики
- •Системы диагноза технического состояния
- •Диагностические системы управления
- •Объекты диагноза
- •Математические модели объектов диагноза
- •Функциональные схемы систем тестового и функционального диагноза
- •Методы и технические средства диагностирования элементов и устройств вычислительной техники и систем управления Общие сведения
- •Тестовое тестирование узлов, блоков и устройств.
- •Структуры автоматизированных систем.
- •Программное обеспечение процессов диагностирования.
- •Логические анализаторы.
- •Микропроцессорные анализаторы (ма).
- •Способы запуска.
- •Подключающие устройства.
- •Ввод начальных данных.
- •Проверка отдельных триггеров.
- •Проверка содержимого постоянных запоминающих устройств (пзу).
- •Проверка оперативных запоминающих устройств (озу).
- •Проверка работы линии коллективного пользования (лкп).
- •Проверка аналого-цифровых преобразователей (ацп).
- •Проверка печатных плат.
- •Проверка микропроцессорной системы.
- •Сигнатурные анализаторы
- •Процесс формирования сигнатур.
- •Аппаратурная реализация сигнатурного анализатора.
- •Тестовое диагностирование устройств в составе эвм.
- •Диагностирование оборудования процессоров.
- •Способы диагностирования периферийных устройств.
- •Диагностирование упу/пу с помощью процессора.
- •Проверки упу/пу с помощью диагностических приказов.
- •Диагностирование упу/пу с помощью тестеров.
- •Способы тестирования зу.
- •Принципы построения стандартных проверяющих тестов полупроводниковых зу.
- •Аппаратурные средства функционального диагностирования узлов и блоков. Основные принципы построения.
- •Кодовые методы контроля.
- •Контроль передач информации.
- •Контроль по запрещенным комбинациям.
- •Самопроверяемые схемы контроля.
- •Контроль по модулю
- •Организация аппаратурного контроля озу.
- •Организация аппаратурного контроля внешних зу.
- •Средства функционального диагностирования в составе эвм.
- •Контроль методом двойного или многократного счета
- •Экстраполяционная проверка
- •Контроль по методу усеченного алгоритма (алгоритмический контроль).
- •Способ подстановки.
- •Проверка предельных значений или метод "вилок".
- •Проверка с помощью дополнительных связей.
- •Метод избыточных переменных
- •Контроль методом обратного счета.
- •Метод избыточных цифр.
- •Метод контрольного суммирования.
- •Контроль методом счета записи.
- •Контроль по меткам
- •Метод обратной связи
- •Метод проверки наличия формальных признаков (синтаксический метод, метод шаблонов).
- •Метод проверки запрещенных комбинаций.
- •Метод an-кодов
- •Методы на основе циклических кодов и кодов Хэмминга и др.
- •Структурные методы обеспечения контролепригодности дискретных устройств.
- •Введение контрольных точек.
- •Размножение контактов.
- •Использование блокирующей логики.
- •Применение параллельных зависимых проверок
- •Замена одним элементом состояний группы элементов памяти.
- •Методы улучшения тестируемой бис. Сокращение числа тестовых входов.
- •Двухуровневое сканирование.
- •Микропроцессорные встроенные средства самотестирования.
- •Контроль и диагностирование эвм Характеристики систем диагностирования
- •Системы контроля в современных эвм
- •Применение аналоговых сигнатурных анализаторов
- •Работа локализатора неисправностей pfl780 в режиме "Pin by Pin"
- •Работа в режиме Pin by Pin
- •Работа с торцевыми разъемами
- •Среда тестирования
- •Индивидуальное тестирование или режим Pin by Pin?
- •Тестирование специальных устройств
- •Устранение ложных отказов путем использования эталонных сигнатур компонентов от разных производителей
- •Тестирование цифровых компонентов методом asa
- •Вариации сигнатур.
- •Входные цепи защиты
- •Набор альтернативных сигнатур
- •Тестирование подключенных к общей шине компонентов путем их изоляции специальными блокирующими напряжениями.
- •Системы с шинной архитектурой
- •Устройства с тремя логическими состояниями
- •Разрешение работы и блокирование компонентов
- •Применение "блокирующих" напряжений
- •Отключение тактовых импульсов.
- •Отключение шинных буферов.
- •Опция Loop until Pass
- •Локализация дефектных компонентов в системах с шинной архитектурой без их удаления из испытываемой цепи
- •Поиск неисправностей методами asa и ict в системах с шинной архитектурой
- •Сравнение шинных сигнатур
- •Шинные сигнатуры
- •Изоляция устройств.
- •Локализация коротких замыканий шины и неисправностей нагрузки прибором toneohm 950 в режиме расширенного обнаружения неисправностей шины
- •Типы шинных неисправностей
- •Короткие замыкания с низким сопротивлением
- •Измерение протекающего через дорожку тока.
- •Измерение напряжения на дорожке печатной платы
- •Обнаружение кз и чрезмерных токов нагрузки в труднодоступных для тестирования местах
- •Короткие замыкания на платах
- •Обнаружение сложных неисправностей тестируемой платы путем сравнения импедансных характеристик в режиме asa
- •Импедансные сигнатуры
- •Локализация неисправностей методом Аналогового сигнатурного анализа
- •Методы сравнения
- •Основы jtag Boundary Scan архитектуры
- •АрхитектураBoundaryScan
- •Обязательные инструкции
- •Как происходитBoundaryScanтест
- •Простой тест на уровне платы
- •Граф состояний тар – контроллера
- •Мониторинг сети Управление сетью
- •Предупреждение проблем с помощью планирования
- •Утилиты мониторинга сети
- •Специальные средства диагностики сети
- •Источники информации по поддержке сети
- •Искусство диагностики локальных сетей
- •Организация процесса диагностики сети
- •Методика упреждающей диагностики сети
- •Диагностика локальных сетей и Интернет Диагностика локальных сетей
- •Ifconfig le0
- •Сетевая диагностика с применением протокола snmp
- •Диагностика на базеIcmp
- •Применение 6-го режима сетевого адаптера для целей диагностики
- •Причины циклов пакетов и осцилляции маршрутов
- •Конфигурирование сетевых систем
- •Методы тестирования оптических кабелей для локальных сетей.
- •Многомодовый в сравнении с одномодовым
- •Нахождение разрывов
- •Измерение потери мощности
- •Использование тестовOtdRдля одномодовых приложений
- •Источники
- •Словарь терминов а
Сетевая диагностика с применением протокола snmp
Обслуживание и диагностирование больших многосегментных, многопротокольных сетей, размещенных на большой территории, а в некоторых случаях и в нескольких городах (например, корпоративные сети типа Интранет), представляет собой тяжелую проблему.
Так как сеть может быть построена с использованием различных физических сред и протоколов, наиболее привлекательным, если не единственным, средством диагностики представляется протокол snmp, который служит для целей управления в ISDN, X.25, FDDI, ATM, TCP/IP и других сетях. Протокол SNMP (std15, RFC-1448, -1592, -1901,1902-1907, 1908-1910) использует управляющую базу данных mib (RFC-1213, -1158, -1792, -1042;std16,std17), доступ к которой определяется администратором локальной сети или конкретной ЭВМ (ссылки, выделенные полужирным шрифтом, являются стандартами Интернет). Для того чтобы база данных была доступна, необходимо наличие snmp-демона с режимом свободного доступа (поле community = public). Рассмотрим сеть, изображенную на рис. 4.1.1.
Рис. 4.1.1. Пример диагностируемой сети
Для диагностики сегмента, непосредственно связанного с ЭВМ-тестером, можно использовать режим 6 Ethernet-интерфейса ЭВМ-тестера. Этот режим, при котором принимаются все пакеты, следующие по сегменту, позволяет регистрировать распределение пакетов по адресам отправителя и получателя, протоколам, длинам пакетов и т.д.. Запуская определенные программы на ЭВМ 1 или 2 (сегмент С-1), можно получить исчерпывающую информацию о состоянии сегмента. Этот способ диагностики не пригоден для сегментов, к которым подключены ЭВМ 3 (сегмент С-2), 4 и 5 (сегмент С-3). В случае, если все ЭВМ сети поддерживают протокол tcp/ip, возможно применение для целей диагностики протокола icmp (RFC-1256, -1788, -1885, -792). Этот протокол также как и snmp пригоден для диагностики не только локальной сети но и каналов Интернет. Если использовать icmp не только для трассировки маршрутов, но и для измерения процента испорченных пакетов, можно получить весьма полезную информацию, а при длинных сегментах зарегистрировать ухудшение качества сегмента при подключении слишком большого числа ЭВМ. Такая техника может прогнозировать ухудшение пропускной способности канала при подключении дополнительных ЭВМ. Но применение icmp ограничено ЭВМ, поддерживающими протоколы Интернет, да и получаемые данные весьма ограничены.
Следует иметь в виду, что в многопротокольных средах структуры MIB могут заметно отличаться, варьируется несколько и формат SNMP-пакетов. В настоящее время существует достаточно большой выбор коммерческих программ сетевой SNMP-диагностики (их цены лежат в диапазоне 5-45 тыс. дол.). Особую ценность представляют аппаратно-программные комплексы (15-55 тыс. дол.), которые способны диагностировать состояние оборудования и кабельных сегментов. К сожалению, для отечественных пользователей они по причине цены практически недоступны.
Сеть ИТЭФ, которая была зарегистрирована одной из первых в качестве узла Интернет в 1991 году, в настоящее время содержит более 400 ЭВМ при суммарной длине кабельных сегментов около 10 км и обслуживается 6 сотрудниками. В сети используются протоколы TCP/IP, Novell, Arcnet и др.. Проблема диагностики такой сети достаточно актуальна. Мы сначала использовали традиционные программные средства типа ping,traceroute,netstat, arp, snmpi, dig(venera.isi.edu/pub),hosts, nslookup, ifconfig, ripquery, поставляемые со многими сетевыми пакетами. Позднее пытались адаптировать общедоступные диагностические средства типа:netwatch(windom.ucar.edu),snmpman(http:// www.smart.is/pub/mirror-indstate/snmp),netguard(oslo-nntp,eunet.no/pub/msdos/winsock/apps),ws_watch(bwl.bwl.th-harmstadt.de/windows/util). Среди наиболее часто встречающихся проблем: разрывы кабельных сегментов, несанкционированное использование IP-адресов, некачественное питание сетевого оборудования, отказы тех или иных устройств.
Не все ЭВМ имеют активные SNMP-резиденты, это происходит по причине экономии оперативной памяти или по соображениям безопасности. Еще меньше snmp-агентов, доступных в режиме public (поле SNMP-пакета community;формат пакетов описан, например, в книге Семенова Ю.А. ротоколы и ресурсы ИнтернетМосква, адио и связь996). Но для контроля ситуации достаточно иметь по одному активному SNMP-резиденту на каждом из кабельных сегментов. При этом не обязательно ставить их в общедоступный режим, можно использовать для получения диагностической информации и пароль.
При написании диагностической программы не нужно пытаться считывать все переменные и таблицы MIB. База данных весьма велика и для целей диагностики не все ее записи представляют интерес. При написании нашей диагностической программы были отобраны 35 переменных (ниже приводится сокращенный список):
interface.iftable.ifentry.ifinucastpkts |
Число полученных обычных пакетов; |
interface.iftable.ifentry.ifinnucastpkts |
Число полученных широковещательных и мультикаст-пакетов; |
interface.iftable.ifentry.ifinerrors |
Число ошибок при приеме пакетов; |
interface.iftable.ifentry.ifoutucastpkts |
Число посланных обычных пакетов; |
interface.iftable.ifentry.ifinnucastpkts |
Число посланных широковещательных и мультикаст-пакетов; |
interface.iftable.ifentry.ifinunknownprotos |
Число полученных пакетов с неизвестным кодом протокола; |
ip.ipinreceives |
Полное число ip-дейтограмм, включая полученные с ошибкой; |
ip.ipinhdrerrors |
Число входных ip-дейтограмм с ошибками в заголовке пакета, включая ошибки контрольной суммы, ttl и т.д. |
ip.ipinaddrerrors |
Число полученных пакетов с ошибкой в адресе; |
ip.ipinunknownprotos |
Число входных ip-дейтограмм, с кодами протоколов, которые не поддерживаются данной системой; |
ip.ipreasmreqds |
Число полученных фрагментов, которые требуют сборки; |
ip.ipindelivers |
Число ip-дейтограмм, принятых без ошибок (включая icmp); |
icmp.icmpinmsgs |
Число полученных icmp-пакетов;(другие 10 контролируемых переменных icmp-группы из соображений экономии места из списка исключены); |
udp.udpindatagrams |
Число принятых udp-дейтограмм; |
udp.udpoutdatagrams |
Число отправленных udp-дейтограмм; |
udp.udpnoports |
Полное число udp-дейтограмм, для которых не существует приложения для указанного номера порта; |
udp.udpinerrors |
Число udp-дейтограмм, которые не могут быть доставлены не по причине отсутствия приложения по указанному порту; |
tcp.tcpinsegs |
Число принятых tcp-сегментов; |
tcp.tcpoutsegs |
Число отправленных TCP-сегментов; |
tcp.tcpretranssegs |
Число tcp-сегментов с повторной пересылкой; |
tcp.tcpoutrsts |
Число сегментов с флагом rst=1; |
tcp.tcpinerror |
Число tcp-сегментов, полученных с ошибкой. |
Выбор определялся тем, что именно эти переменные варьируются динамически в течение суток. Ставилась задача исследования временных вариаций потоков в заданном сегменте и выработки критериев для диагностики потенциально опасных ситуаций. Измерения проводились каждые полчаса в течение недели.
Многие переменные базы 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}, последняя переменная говорит о том, сколько встретилось пакетов с флагом, запрещающим фрагментацию, в условиях, когда она необходима, что может свидетельствовать, еслиipfragfailsвелико, о неверном выборе 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-сегментов). Запись в MIBudp.udpnoportsявляется важным диагностическим показателем. Переменные, регистрирующие число тех или иных ошибок, неупомянутые в этом абзаце, оказались равными нулю. Количество пакетов snmp в точности совпадает с их числом, посланным и полученным данной программой-тестером, что говорит об отсутствии какой-либо другой SNMP-активности. Контролировать это время от времени также полезно из соображений сетевой безопасности.
Рис. 4.1.2. Вариации tcpinsegs и udpindatagrams в течение недели
Для защищенных систем доступ к snmp-резиденту в пакетах должно использоваться поле community = паролю. Но даже эта мера не может блокировать вторжение со стороны LAN, так как в результате перехвата snmp-пакетов пароль может быть открыт. При написании таких программ нужно учитывать версии MIB, используемые анализируемыми узлами, а также тот факт, что snmp-отклики могут иметь для разных операционных сред. Рассмотрим, как варьируются некоторые из перечисленных переменных в течении суток и недели. На рис. 4.1.2 видны спады сетевой активности в ночное время и в выходные дни. Левый край диаграммы соответствует понедельнику 9 сентября (ночь), правый - понедельнику, но уже следующей недели. На рис. 4.1.3 приведена диаграмма вариации некоторых переменных за сутки. Сетевая активность захватывает период от 10 часов утра и спадает почти до нуля к 9-10 вечера, хотя бывают и исключения. Для эффективной интерпретации временных зависимостей можно использовать программу мониторинга last(или любой ее эквивалент), которая позволяет отслеживать появление новых пользователей или процессов (например, ftp). Фрагмент распечатки, выданной программойlastна ЭВМ, snmp-резидентом которой пользовалась наша программа, приведен ниже.
ms977 |
pts/0 |
vitep5.itep.ru |
tue sep 10 23:49 - 00:16 (00:27) |
ms977 |
pts/2 |
vitep5.itep.ru |
tue sep 10 22:20 - 23:46 (01:26) |
ostrouh |
pts/0 |
athene.itep.ru |
tue sep 10 18:30 - 18:43 (00:13) |
titovich |
pts/0 |
athene.itep.ru |
tue sep 10 18:30 - 18:30 (00:00) |
vita |
pts/3 |
athene.itep.ru |
tue sep 10 14:55 - 15:56 (01:00) |
checho |
pts/12 |
itep05.itep.ru |
tue sep 10 13:35 - 13:37 (00:01) |
fomin |
pts/10 |
hydra.ifh.de |
tue sep 10 13:16 - 13:22 (00:06) |
checho |
pts/7 |
itep05.itep.ru |
tue sep 10 13:09 13:16 (00:07) |
illarion |
pts/7 |
xt07.itep.ru |
tue sep 10 12:45 12:45 (00:00) |
vita |
pts/9 |
athene.itep.ru |
tue sep 10 11:55 13:03 (01:07) |
bely |
pts/12 |
pcx01.itep.ru |
tue sep 10 11:49 12:02 (00:13) |
vita |
pts/13 |
athene.itep.ru |
tue sep 10 11:49 11:52 (00:03) |
efre |
pts/4 |
pcx10.itep.ru |
tue sep 10 10:05 10:24 (00:18) |
checho |
pts/0 |
169-151-147.ipt. |
tue sep 10 05:07 05:09 (00:01) |
ssemen |
ftp |
clotho.itep.ru |
mon sep 09 20:14 20:15 (00:01) |
ssemen |
ftp |
clotho.itep.ru |
mon sep 09 19:34 19:35 (00:00) |
ostrouh |
pts/3 |
athene.itep.ru |
mon sep 09 19:20 19:40 (00:20) |
ozero |
pts/0 |
athene.itep.ru |
mon sep 09 19:13 22:44 (03:30) |
ozero |
pts/5 |
itep05.itep.ru |
mon sep 09 18:05 18:32 (00:27) |
olyalin |
pts/6 |
itep05.itep.ru |
mon sep 09 16:19 16:27 (00:08) |
efre |
ftp |
pcx10.itep.ru |
mon sep 09 16:14 16:15 (00:00) |
mara |
pts/1 |
hpl3pur2.cern.ch |
mon sep 09 16:02 16:27 (00:24) |
mara |
pts/1 |
hpl3pur2.cern.ch |
mon sep 09 15:50 15:54 (00:04) |
itep977 |
pts/2 |
1mars.itep.ru |
mon sep 09 15:22 15:23 (00:00) |
ozero |
pts/20 |
aix0.itep.ru |
mon sep 09 15:06 15:36 (00:29) |
ozero |
pts/12 |
itep05.itep.ru |
mon sep 09 14:56 14:56 (00:00) |
galy |
pts/16 |
athene.itep.ru |
mon sep 09 14:27 14:31 (00:03) |
bely |
pts/15 |
vitep5.itep.ru |
mon sep 09 14:09 10:36 (20:27) |
sed |
pts/5 |
pcx11.itep.ru |
mon sep 09 14:01 14:01 (00:00) |
kisel |
pts/1 |
vxitep.itep.ru |
mon sep 09 13:59 15:22 (01:22) |
ozero |
pts/12 |
itep05.itep.ru |
mon sep 09 13:53 14:55 (01:02) |
ozero |
pts/2 |
193.148.166.214 |
mon sep 09 13:40 13:41 (00:00) |
ozero |
pts/8 |
193.148.166.214 |
mon sep 09 13:32 13:37 (00:04) |
vita |
pts/9 |
aix0.itep.ru |
mon sep 09 13:32 13:32 (00:00) |
vita |
pts/2 |
vitep5.itep.ru |
mon sep 09 13:32 13:32 (00:00) |
checho |
pts/3 |
itep05.itep.ru |
mon sep 09 13:11 13:12 (00:00) |
efre |
pts/3 |
pcx10.itep.ru |
mon sep 09 12:12 12:23 (00:10) |
kisel |
pts/2 |
vxitep.itep.ru |
mon sep 09 12:11 12:43 (00:32) |
checho |
pts/6 |
itep05.itep.ru |
mon sep 09 12:02 12:03 (00:00) |
kisel |
ftp |
pcx11.itep.ru |
mon sep 09 11:42 11:43 (00:00) |
kisel |
ftp |
ion04.cern.ch |
mon sep 09 10:59 11:06 (00:06) |
galy |
pts/1 |
athene.itep.ru |
mon sep 09 10:57 10:58 (00:00) |
titovich |
pts/4 |
athene.itep.ru |
mon sep 09 10:20 10:21 (00:01) |
korol |
pts/0 |
193.124.225.174 |
mon sep 09 05:20 05:57 (00:37) |
Первая колонка содержит имена пользователей, вторая - тип задачи (PTS/n - удаленный доступ с терминала с номером n), далее следует имя узла или его IP-адрес, с которого осуществлен доступ, дата, время работы и длительность сессии. Как правило, сессии типа FTP или NFS дают большую сетевую загрузку. Нужно учитывать возможность запуска FTP-сессии или другой информационно-емкой процедуры после входа в систему с помощью telnet (PTS). Рассматривая эту распечатку совместно с временными зависимостями переменных базы данных MIB, можно интерпретировать результаты, определить, какая из сессий загружает данный сегмент сети более других. Рассмотрев, например, результаты работы программы last и рис. 1.1.3а, можно видеть, что максимум в период с 18 до 20 часов связан с активностью пользователей ozero, ostrouh и ssemen. Но даже в отсутствии сессий, зафиксированных last, можно наблюдать заметную сетевую активность. Это может быть доставка почтовых сообщений или зондирование сервера пакетами-роботами со стороны удаленных www-клиентов.
Рис. 1.1.3(а, б). Временная зависимость ifinucastpkts, ifoutucastpkts и ifinnucastpkts
По горизонтальной оси отложено время от начала суток. Кривая, отмеченная треугольниками, соответствует правой шкале диаграммы, это справедливо для всех последующих рисунков. Входной и выходной потоки через данный интерфейс практически равны. На рис. 1.1.4(а,б) показана вариация со временем входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers). Пик в правой части рис. 1.1.4а (19:00 - 20:00) показывает, что поток ipinreceives превосходит поток ipindelivers почти в два раза. Можно было бы предположить, что разница определяется числом ошибок, но так как по времени это совпадает с пиком в диаграмме ipinreasmreqd, различие следует интерпретировать, как необходимость сборки сообщений. Сопоставление значений ipinreceives, ipinreasmreqd и ipindelivers подтверждает такое предположение. Если такого рода ситуация в сети повторяется часто, нужно просмотреть корректность выбора mtu для объектов, участвующих в данном обмене. Для областей вне указанного пика значения ipinreceives и ipindelivers почти совпадают, что говорит о низком уровне ошибок (это подтверждается и значением потока icmpouterrors, icmpoutdestunreachs и ifinunknownprotos.
На рис. 1.1.5(а и б) показаны суточные вариации потоков udp-дейтограмм, а на рис. 1.1.6(а и б) представлены аналогичные временные зависимости для TCP-сегментов. Если входные и выходные потоки UDP-дейтограмм отличаются друг от друга временами в несколько раз (что вполне естественно), то входные и выходные потоки TCP-сегментов почти не отличаются (ведь каждому посланному пакету в этом протоколе должен соответствовать пакет-подтверждение).
Рис. 1.1.4(а,б). Временные зависимости входных потоков IP-дейтограмм (ipinreceives, ipinreasmreqd и ipindelivers)
Рис. 1.1.5(а,б). Суточные вариации потоков UDP-дейтограмм.
Рис. 1.1.6(а, б). Суточные вариации потоков TCP-сегментов