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

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

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

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

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


Rambler's Top100

  

Два плохих модуля

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

Проблема. Взаимодействуя с удаленной сетью Ethernet, которая подключена к нашей основной сети через два маршрутизатора и дробный канал Т-1 с пропускной способностью 768 Кбит/с, мы постоянно сталкиваемся с трудностями. Пользователи основной сети, работающие с Windows 95, "видят" удаленные серверы Windows NT и их каталоги, но попытки скопировать файлы с помощью "перетаскивания" соответствующих пиктограмм мышью (drag-and-drop) оканчиваются неудачей и выдачей сообщения об ошибке: "Network resource is no longer available" ("Сетевой ресурс более не доступен"). Запустив сетевой тест (ping), мы увидели следующее: при увеличении пакетов до размера максимального блока передачи (MTU) сети Ethernet их потери достигают 50%. Если MTU обоих маршрутизаторов установить равными 1100 байт, то при использовании средств TCP/IP связь нормализуется, но при передаче файлов по протоколу NetBEUI проблема остается. Специалисты фирмы-оператора дальней связи протестировали канал Т-1 и заявили, что с ним все в порядке. В основной сети мы используем магистраль FDDI, к которой через свои мосты Ethernet-FDDI подключены концентраторы Ethernet. Наши маршрутизаторы настроены на маршрутизацию IP и работают в режиме моста для трафика NetBEUI.

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

Билл: При быстром анализе трафика сегментов Ethernet пользователя и маршрутизатора, подключенных к магистрали FDDI, не было обнаружено потери пакетов и искаженных пакетов, содержащих ошибки циклического избыточного кода (CRC). Несмотря на это, при попытке рабочей станции по протоколу NetBEUI передать файл на удаленный сервер Windows NT трассировка пакетов показывала несколько неудачных попыток записи блока данных Server Message Block (SMB), после чего возникала ошибка.

Скотт: При этом пользователи, которые применяют средства TCP/IP, успешно передавали файлы. Следовательно, одним из решений проблемы мог бы стать полный переход всей сетевой среды на TCP/IP.

Билл: Но тогда мы не получили бы ответа на вопрос: почему не работает связь по NetBEUI? К тому же, наши заказчики не намерены были полностью переходить на TCP/IP.

Скотт: Мы также хотели разобраться с NetBEUI, поскольку за внешне нормальной работой средств TCP/IP могла скрываться серьезная сетевая проблема.

Билл: Трассировка наглядно показывала, что размер IP-пакетов никогда не превышал 1100 байт, т. е. не был выше размера MTU, установленного на интерфейсе Т-1 маршрутизатора.

Скотт: В то же время данные SMB размещались в пакетах размером 1504 байт, что превышало MTU.

Билл: Маршрутизатор просто отбрасывал все пакеты с данными SMB, поскольку протокол NetBEUI не обрабатывает ситуацию несовпадения размеров пакетов и MTU.

Скотт: Напротив, стек TCP/IP отправителя автоматически уменьшал размер пакетов и успешно доставлял их в удаленную сеть.

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

Скотт: Теперь пакеты SMB иногда стали проходить.

Билл: Но появилась другая неприятность — возникли трудности с передачей пакетов у пользователей, применяющих TCP/IP. Мы наблюдали по нескольку неудачных попыток записи больших IP-пакетов.

Скотт: С помощью анализатора протокола мы протестировали канал Т-1 на интерфейсе V.35 маршрутизатора.

Билл: И опять мы не увидели ни потерянных пакетов, ни пакетов с ошибками CRC при любых запросах на запись данных SMB.

Скотт: Тогда почему же не отвечал удаленный сервер?

Билл: Ключ к разгадке могло дать посещение удаленного офиса (слава Богу, он находился на расстоянии всего нескольких миль). Но, прежде чем поехать туда, мы запустили сетевой тест, посылающий раз в секунду на удаленный сервер Windows NT пакеты с максимальным размером MTU. Как и ожидалось, потери составляли где-то около 50%.

Скотт: В удаленном офисе мы проверили тестовые пакеты на интерфейсе канала Т-1 и в сети Ethernet.

Билл: Мы выяснили, что приходящие пакеты не содержат ошибок.

Скотт: Однако сервер отвечал не на все запросы.

Билл: Может быть, не в порядке были какие-либо другие средства, например адаптер, сетевые драйверы или стек протоколов сервера?

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

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

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

Билл: Ура! Проблема стала проясняться. Но откуда берутся ошибки CRC?

Скотт: Ответ дало более пристальное изучение плохих пакетов.

Билл: Пакеты, содержащие ошибки CRC, и хорошие пакеты имели одинаковую длину. Это означало наличие в них одной или нескольких ошибок.

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

Билл: Очевидно, модуль концентратора работал неправильно, но только при передаче последних байтов больших пакетов.

Скотт: Проверив другой модуль концентратора, мы установили, что и он неправильно повторял пакеты.

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

Скотт: После того, как мы подключили сервер к порту исправного модуля, доля успешных передач тестовых запросов сразу же возросла с 50 до 100% и появилась возможность для успешной передачи файлов с использованием как TCP/IP, так и NetBEUI. При этом скорость их передачи через дробный канал Т-1 составила приблизительно 500 Кбит/с. Теперь осталось только заменить два неисправных концентраторных модуля на исправные





  
8 '1997
СОДЕРЖАНИЕ

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

• Пираты электронных морей

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

• Модернизация кабельных систем

• Оптические дисковые системы

• Два плохих модуля

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

• Интервью с вице-президентом компании Bay Networks

• Передовые технологии: Layer 3 Switching (часть I)

• Пограничные коммутаторы АТМ: заранее подготовьтесь к росту сетевого трафика

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

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

• Анатомия модемных "56К-технологий"

• Полезные и доступные офисные системы речевой почты

• Спутниковые модемы

• Маршрутизаторы ISDN BRI для малого офиса

интернет и интрасети

• Технологии "выталкивания" в информационных службах Интернет

• Microsoft у "последней черты"

• Метаморфозы Интернет

• Разработка Web-приложений с помощью мощных CGI-инструментов

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

• IP-шлюз для "игры в прятки"

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

• Тестер двухмегабитных потоков "Морион-Е1", RemoteVU: видео по каналу 2,4 Кбит/с, SmartSTACK 10 фирмы Cabletron Systems, NUCLON - третье поколение отечественных СПРВ, Новый мощный Web-сервер фирмы Netscape, Dell PowerEdge 2200

только на сервере

• Novell и Netscape начинают совместный проект

• NT CONPAS - маленький, но мощный

• Stac Replica предотвращает потерю данных



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