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

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

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

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

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


Rambler's Top100

  

Надоедливый "писк"

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

Проблема. Недавно в качестве своего рода буферного устройства для маршрутизатора мы задействовали коммутатор Ethernet. Он сегментирует трафик локальных рабочих станций Windows NT, который до этого был сконцентрирован на двух сегментах Ethernet, подключенных к маршрутизатору. Пользователи нашей сети работают с приложением, написанным на языке Visual Basic и обеспечивающим доступ к базам данных на серверах Banyan VINES. Для связи с удаленными подсетями маршрутизатор поддерживает канал T1. После установки коммутатора мы продолжаем использовать два идущих от маршрутизатора сегмента, только теперь они подсоединены к портам коммутатора. Это обеспечивает резервирование связи с маршрутизатором и позволяет выравнивать нагрузку на его интерфейсы. Недавно мы начали периодически контролировать трафик в нашей сети, используя зонды удаленного мониторинга RMON, и заметили, что в сегментах Ethernet маршрутизатора время от времени возникают "штормы" широковещательных сообщений, и они учащаются по мере подключения к сети все большего числа пользователей.

Скотт: Да, иногда эти широковещательные пакеты могут раздражать так же, как комары, которые непрестанно летают и пищат над ухом.

Билл: Даже если на самом деле они не наносят большого вреда, их писк надоедает и возникает непреодолимое желание поскорее избавиться от них.

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

Билл: Анализ, проведенный с помощью зонда RMON, показал очень быстрый рост числа таких сообщений.

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

Билл: Сначала нам показалось, что время от времени рабочие станции Windows NT передают "пачки" широковещательных пакетов с DLC-адресом назначения, который относится ко всем сетевым устройствам (он равнялся FFFFFFFFFFFF), и с адресом сети назначения, соответствующим IP-адресу собственной подсети.

Скотт: После тщательного анализа содержимого IP-заголовков широковещательных пакетов мы увидели, что число в поле "Время жизни" (TTL) в заголовке IP каждого следующего перехватываемого пакета "пачки" на единицу меньше предыдущего и в последнем ее пакете доходит до нуля.

Билл: Мы не сомневались в "причастности" к этому маршрутизатора, поскольку данные устройства уменьшают на единицу значение TTL в заголовках IP-пакетов при их пересылке.

Скотт: Стек в составе Windows NT 3.51 формирует пакеты с TTL, равным 32, а маршрутизатор отбрасывает пакеты с нулевым значением TTL, поэтому их число в "пачке" ограничивается числом 32.

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

Скотт: Два сегмента, идущие от маршрутизатора, относились к разным IP-подсетям — 47 и 48 (см. рисунок).

Билл: Связав их с помощью коммутатора Ethernet, наш клиент фактически сделал свою IP-сеть "плоской" (не имеющей подсетей), так как теперь стало неважно, к какому из ее сегментов подключена та или иная рабочая станция.

Скотт: Поскольку все пакеты "прозрачно" коммутировались на уровне DLC независимо от управления на сетевом уровне, то пакеты с широковещательным адресом DLC посылались во все сегменты, соединенные с коммутатором.

Билл: Включая и те два сегмента, которые подключены к маршрутизатору.

Скотт: Обычно в маршрутизаторах не используют режим работы в качестве моста, поэтому они не пропускают пакеты с широковещательным адресом DLC.

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

Скотт: Это происходило из-за того, что, как уже отмечалось, коммутатор посылал пакеты с широковещательным адресом DLC во все подключенные к нему сегменты.

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

Скотт: Если по сегменту подсети 47 приходил пакет, адресованный всем узлам этой подсети, маршрутизатор, естественно, отбрасывал его, но такой же пакет, пришедший по сегменту подсети 48, передавал в подсеть 47.

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

Скотт: Каждый широковещательный пакет циркулировал до тех пор, пока значение TTL в его IP-заголовке не достигало нуля.

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

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

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

Скотт: Рабочие станции Windows NT проверяемой сети функционировали с клиентским ПО VINES компании Banyan Systems, поэтому в первую очередь мы решили проверить его коммуникационные параметры.

Билл: По умолчанию рабочая станция Windows NT (как и Windows 95) работает в режиме b-узла.

Скотт: Это значит: все запросы станций на получение имен NetBIOS или сведений о сетевых ресурсах и т. п. посылаются в виде широковещательных пакетов.

Билл: Действительно, одна из рассмотренных нами трассировок зафиксировала циркулирующий в сети пакет с запросом NetBIOS на получение списка сетевых ресурсов.

Скотт: Каждые 12 мин рабочие станции передавали свои широковещательные сообщения, которые "зацикливались" в сети нашего клиента, вызывая тем самым увеличение широковещательного трафика. Вывод таков: перед тем как принять решение о превращении своей IP-сети в "плоскую", например с помощью коммутатора, сначала очень хорошо подумайте, не вызовет ли это рост широковещательного трафика?

Билл: Особенно теперь, когда по умолчанию Windows NT 4.0 устанавливает значение параметра TTL, равным 128, а не 32...

Скотт: Да... При таком значении TTL "шторм" в сети нашего клиента стал бы в четыре раза "сильнее"





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

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

• Нарушитель конвенции

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

• Коннектор - "узкое" место кабельной системы

• Коммутируемый Ethernet или разделяемый Fast Ethernet

• Когда не помогает хороший пинок

• Волоконно-оптический кабель - что это и зачем он нужен

• Удаленная загрузка - ваша "палочка-выручалочка"

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

• IP-коммутация: сражение за сетевые высоты

• Надоедливый "писк"

• Связующее ПО: на сцене статисты

• Качество обслуживания, или Как добиться неравенства в мире равноправия

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

• Грядет РИФ'98...

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

• Услуги цифровой связи E1

• Рефлектометры для медных кабелей

• Телефонные гарнитуры: в серьезном бизнесе нет мелочей

• Технологии доступа. Делайте ваши ставки

• Руководство покупателя модемов формата Pc Card

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

• Интернет для среднего офиса

• Мультимедиа в Интернет

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

• Реальные системы для виртуальных коммутируемых частных сетей

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

• Три новинки Lucent Technologies, Парад новинок от HP, Что нам стоит сеть построить..., Быстрый и многофункциональный коммутатор от 3Com

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

• Интернет от... IBM

• Фирменное ПО управления сетевыми устройствами

• Исследуем производительность JDBC - интерфейсов

• В поисках унифицированной почтовой архитектуры



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