Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Загадка маршрутизатора

Билл Алдерсен и Дж. Скотт Хогдал

Проблема. Волею судеб мы оказались в сети, целиком построенной на продукции фирмы Microsoft. В данном случае, типовая рабочая станция функционировала под управлением Windows for Workgroups, а в качестве первичной сетевой операционной системы сервера была установлена Windows NT Server. Основная сетевая инфраструктура состоит из нескольких колец Token Ring (со скоростью передачи данных 16 Мбит/с), поддерживающих тысячи пользователей. Вместо того чтобы применить обычный драйвер NetBIOS Windows for Workgroups, работающий поверх протокола Logical Link Control (LLC), наш клиент пошел по "пути" межсетевого протокола IP, встроив поддержку TCP/IP в рабочие станции и серверы. Поэтому охватывающий сегменты сети трафик NetBIOS, для которого не нужно указывать источник данных и который прозрачно проходит мосты в случае использования NetBIOS, в данном случае направляется посредством IP. Стандарт NetBIOS для работы по TCP/IP приведен в документах RFC 1001 и 1002.

В системе NT Server применяется протокол Server Message Block (SMB) для взаимодействия служб обработки файлов и печати с рабочими станциями Windows for Workgroups. SMB и NetBIOS часто используются вместе, как и нашем случае. Однако есть и исключения, например, SMB в операционных системах VINES и Pathworks .

Проблема нашего клиента состояла в том, что в одном сегменте сети пользователи рабочих станций в среде Windows for Workgroups не могли сохранять файлы на накопителях сервера.

Скотт: Для разрешения сетевой проблемы важно сразу точно указать ее суть, а не довольствоваться банальной формулировкой вроде: "Ах, я не могу сохранить файл".

Билл: В сложившейся ситуации мы определили, что пользователь может зарегистрироваться в сети, запустить приложение на сервере и загрузить из него файл. Однако спустя 15 секунд после попытки пользователя сохранить данные соединение с устройством, указанным на сервере, становится невозможным.

Скотт: Странно, что сохранение небольших файлов (около 1 Кбайт) происходило нормально; проблемы возникали только с записью длинных файлов.

Билл: Странно и то, что у некоторых пользователей на ближайших кольцах проблем не было вообще.

Скотт: Вместо того чтобы посвятить остаток своей жизни изучению и сравнению Windows-файлов с расширением INI, мы решили внедриться в сеть и провести анализ трафика.

Билл: Мы установили режим трассировки пакетов на подозрительной рабочей станции. Все выглядело нормально: процедура входа в систему, загрузка приложения, считывание файла и даже его запись - но до тех пор, пока размер записываемого блока был небольшим.

Скотт: Однако, как только пользователь попытался записать блок объемом, скажем, 2 Кбайта, от сервера не поступило подтверждения SMB.

Билл: Вместо этого уровень ТСР рабочей станции отправил повторный запрос спустя полсекунды, затем секунду, две и т. д. - до шести попыток. Иными словами, после пяти попыток с увеличивающимися экспоненциально интервалами и общим временем почти 16 с соединение разрывалось.

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

Билл: Адреса Data Link Control (DLC) показали, что проверяемая рабочая станция принимала и посылала пакеты по кольцу к маршрутизатору и от него. Интересно отметить, что, поскольку в сети установлен резервный маршрутизатор, первые три запроса были посланы основному маршрутизатору, а последние три - резервному. Адреса IP выявили правильные концевые точки, т. е. рабочую станцию и серверы.

Скотт: Затем по счетчику скачков IP мы обнаружили три скачка (изменения маршрута) между источником и адресатом. Пакет мог быть потерян в любом из этих мест.

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

Скотт: На этой рабочей станции никогда не возникало проблем с записью больших блоков данных. Однако выяснилось, что эта станция работала с другим маршрутизатором и максимальный размер ее пакетов обычно не превышал 1500 байт.

Билл: Отступив немного назад и проанализировав регистрацию, загрузку и сохранение файлов "хорошей" комбинации рабочей станции и маршрутизатора, мы наконец нашли ответ.

Скотт: Отлично! Не томите читателей ожиданием. Это рабочая станция? Маршрутизатор? ЛВС? Солнечные пятна?

Билл: Проблема в маршрутизаторе. Каждый маршрутизатор подключается к непрерывному последовательному каналу. Если максимальный размер передаваемого блока (Maximum Transmission Unit - MTU) превышает определенную величину, "хороший" порт маршрутизатора возвращает пакет Internet Control Message Protocol (ICMP), указывающий на недоступность места назначения из-за необходимости фрагментации данных.

Скотт: Однако, "плохой" маршрутизатор не проинформировал отправителя об этой небольшой проблеме, потеряв тем самым пакет.

Билл: Естественно, отправитель, не получив подтверждения, начинает "проявлять беспокойство" и направляет пакет вновь. Та же самая проблема "подстерегает" в маршрутизаторе и этот пакет, вызывая цикл повторных попыток, вплоть до прекращения работы рабочей станции.

Скотт: Если заглянуть внутрь пакета, посылаемого рабочей станции, то можно увидеть, что бит, запрещающий маршрутизатору фрагментировать пакет, установлен. Это и приводит к передаче в обратном направлении пакета ошибки ICMP. В нашем случае MTU последовательного канала передачи данных был установлен на 1500 байт. Поскольку в кольце Token Ring станция может в принципе создать пакет размером до 17 800 байт, маршрутизатор должен фрагментировать пакет самостоятельно или, как в данном случае, информировать рабочую станцию о MTU-проблеме и потере пакета.

Билл: Правильно! Если пакет IP превышает размер MTU следующего сегмента с установленным битом DF, маршрутизатор должен переслать ICMP назад к отправителю. Получив уведомление о сбросе пакета ICMP DF, станция автоматически уменьшает значение MTU, повторно передает данные с подтверждением прохождения и с этого момента пользуется меньшим значением MTU при записи больших размеров блоков .

Билл: Мы проверили все параметры конфигурации маршрутизаторов, версии программного обеспечения и не смогли обнаружить разницу между портами нормального и сбойного маршрутизатора.

Скотт: Итак, каково же было решение?

Билл: Пришло время обратиться к производителю маршрутизатора. Технический специалист соединился с подозрительным маршрутизатором по коммутируемой линии и "не отыскал ничего неправильного" и "ничего не изменил". Однако на следующий день маршрутизатор, словно по волшебству, стал работать правильно, обрабатывая бит DF с откликом ICMP.

Скотт: Чудеса!


распечатать статью




  
1 '1996
СОДЕРЖАНИЕ

колонка редактора

• Говорит и показывает Интервидение

открытые системы

• Мир TCP/IP. Internet Protocol

• Пятая волна компьютеризации: открытые сети общего пользования

• DCE. Скорее жива, чем мертва?

• Ява - остров восходящего солнца

• Проблемы маршрутизации трафика в Internet

• Удаленный доступ по PPP

• Будущее мультимедиа в Internet

• Интеграция Unix и Windows NT средствами NFS

• Internet: каково же будущее?

корпоративные сети

• Переход к коммутируемым сетям

• Загадка маршрутизатора

• Мост над бурным потоком

• Технология управления распределенными сетями

локальные сети

• Дисковые массивы RAID типа SCSI-to-SCSI

• Ленточные системы с автоматической сменой кассет

• Сетевые адаптеры Ethernet для шины PCI

услуги сетей связи

• Системы низкоорбитальных спутников

• Кодирование речи в цифровой телефонии

• Архитектура и функциональные модули сетей SDH

приложения клиент-сервер

• Однопользовательские СУРБД

• SQL Server 6.0: взаимодействие клиента с сервером

• Комплексная автоматизация производства на основе систем SCADA

защита данных

• А в вашей сети живут драконы?

• Испытание антивирусных программ для NetWare

новые продукты

• RAID без компромиссов, Эмулятор SunPC для DOS и Windows, Коммутатор LinkSwitch 1000 фирмы 3Com, Маршрутизаторы 7500 фирмы Cisco, MultiNet for Windows фирмы TGV



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх