Билл Алдерсен
Проблема. Волею судеб мы оказались в сети, основанной на ОС фирмы Microsoft. В данном случае типовая рабочая станция функционировала под управлением Windows for Workgroups, а в качестве сетевой операционной системы сервера была установлена Windows NT Server. Сетевая инфраструктура состояла из нескольких колец Token Ring (со скоростью передачи данных 16 Мбит/с), поддерживающих тысячи пользователей. Вместо того чтобы применить обычный для Windows for Workgroups драйвер NetBIOS, работающий непосредственно поверх протокола Logical Link Control (LLC), наш клиент выбрал TCP/IP для связи рабочих станций и сервера. Поэтому трафик NetBIOS между сегментами сети в данном случае маршрутизировался по протоколу IP. Обычно же для его передачи используются алгоритмы маршрутизации из источника (source routing) или установления прозрачного моста (transparent bridging). Стандарт, описывающий работу NetBIOS поверх TCP/IP, приведен в документах RFC 1001 и 1002.
В системе NT Server для взаимодействия служб обработки файлов и печати с рабочими станциями Windows for Workgroups применяется протокол Server Message Block (SMB). SMB и NetBIOS часто используются вместе, как и в нашем случае (рис. 1). Однако есть и исключения, например SMB в сетевых операционных системах VINES и Pathworks.
Проблема нашего клиента состояла в том, что в одном сегменте сети пользователи рабочих станций в среде Windows for Workgroups не могли сохранять файлы на накопителях сервера. Однако виновником оказался маршрутизатор.
Скотт: Для разрешения сетевой проблемы важно сразу точно указать ее суть, а не довольствоваться банальной формулировкой вроде: "Ах, я не могу сохранить файл".
Билл: В сложившейся ситуации мы определили, что пользователь может зарегистрироваться в сети, запустить приложение на сервере и загрузить из него файл. Однако спустя 15 секунд после попытки пользователя сохранить данные соединение с сервером пропадало.
Скотт: Странно, что сохранение небольших файлов (около 1 Кбайт) происходило нормально; проблемы возникали только с записью длинных файлов.
Билл: Удивительно и то, что у некоторых пользователей на ближайших кольцах проблем не было вообще.
Скотт: Вместо того чтобы посвятить остаток своей жизни изучению и сравнению Windows-файлов с расширением INI, мы решили провести анализ трафика.
Билл: Мы установили режим трассировки пакетов на подозрительной рабочей станции. Все выглядело нормально: процедура входа в систему, загрузка приложения, считывание файла и даже его запись - но до тех пор, пока размер записываемого блока был небольшим.
Скотт: Однако, как только пользователь попытался записать блок объемом, скажем, 2 Кбайта, от сервера не поступило подтверждения SMB.
Билл: Вместо этого уровень ТСР рабочей станции отправил повторный запрос спустя полсекунды, затем секунду, две и т. д. - до шести попыток. Иными словами, после пяти попыток с увеличивающимися экспоненциально интервалами и общим временем почти 16 секунд соединение разрывалось.
Скотт: В то время как контролируемая станция сделала несколько безответных запросов серверу, другие рабочие станции продолжали успешно с ним взаимодействовать. Поэтому мы заподозрили, что проблема возникает на пути связи рабочей станции и сервера.
Билл: Адреса Data Link Control (DLC) показали, что проверяемая рабочая станция принимала и посылала пакеты по кольцу к маршрутизатору и от него. Интересно отметить, что, поскольку в сети установлен резервный маршрутизатор, первые три запроса были посланы основному маршрутизатору, а последние три - резервному. Адреса IP выявили истинные конечные точки, т. е. рабочую станцию и сервер. Уже производя анализ, мы решили проверить серию транзакций из другой рабочей станции, считывающей и записывающей данные в тот же сервер из другого кольца.
Скотт: На этой рабочей станции никогда не возникало проблем с записью больших блоков данных. Однако выяснилось, что эта станция работала с другим маршрутизатором и максимальный размер ее пакетов обычно не превышал 1500 байт.
Билл: Отступив немного назад и проанализировав регистрацию, загрузку и сохранение файлов "хорошей" комбинации рабочей станции и маршрутизатора, мы наконец нашли ответ.
Скотт: Отлично! Не томите читателей ожиданием. Это рабочая станция? Маршрутизатор? ЛВС? Солнечные пятна?
Билл: Проблема в маршрутизаторе. Маршрутизаторы соединены последовательными каналами. Если максимальный размер передаваемого блока (Maximum Transmission Unit - MTU) превышает определенную величину, "хороший" маршрутизатор возвращает пакет Internet Control Message Protocol (ICMP), указывающий на недоступность места назначения из-за необходимости фрагментации данных.
Скотт: Однако "плохой" маршрутизатор не проинформировал отправителя об этой небольшой проблеме, потеряв тем самым пакет.
Билл: Естественно, отправитель, не получив подтверждения, начинает "проявлять беспокойство" и направляет пакет вновь. Та же самая проблема "подстерегает" в маршрутизаторе и этот пакет, вызывая цикл повторных попыток, вплоть до разрыва соединения рабочей станции с сервером.
Скотт: Если заглянуть внутрь пакета, посылаемого рабочей станции, то можно увидеть, что бит, запрещающий маршрутизатору фрагментировать пакет, установлен. Это и приводит к передаче в обратном направлении пакета ошибки ICMP. В нашем случае MTU последовательного канала передачи данных был установлен на 1500 байт. Поскольку в кольце Token Ring станция может в принципе создать пакет размером до 17 800 байт, маршрутизатор должен фрагментировать пакет самостоятельно или, как в данном случае, информировать рабочую станцию о проблеме с MTU и потере пакета.
Билл: Правильно! Если пакет IP с установленным битом DF превышает размер MTU следующего сегмента, маршрутизатор должен переслать ICMP назад к отправителю. Получив уведомление ICMP о сбросе пакета, станция автоматически уменьшает значение MTU, повторно передает данные с подтверждением прохождения и с этого момента пользуется меньшим значением MTU при записи файлов (рис. 2).
Билл: Мы проверили все параметры конфигурации маршрутизаторов, версии программного обеспечения и не смогли обнаружить разницу между портами нормального и сбойного маршрутизатора.
Скотт: Итак, каково же было решение?
Билл: Пришло время обратиться к производителю маршрутизатора. Технический специалист соединился с подозрительным маршрутизатором по коммутируемой линии и "не отыскал ничего неправильного" и "ничего не изменил". Однако на следующий день маршрутизатор, словно по волшебству, стал работать правильно, обрабатывая бит DF с откликом ICMP.
Скотт: Чудеса!