2.2. Влияние широковещательного служебного трафика на производительность сети

2.2.1. Назначение широковещательного трафика

Пропускная способность любого канала локальной сети ограничивается максимальной эффективной пропускной способностью используемого канального протокола. Если же часть этой пропускной способности используется не для передачи пользовательских данных, а для передачи служебного трафика, то эффективная пропускная способность сети еще уменьшается. Обычно некоторую часть доступной пропускной способности сети отнимает у пользовательских данных широковещательный служебный трафик, который является неотъемлемой частью практически всех стеков протоколов, работающих в локальных сетях.

Широковещательная рассылка кадров и пакетов используется протоколами для того, чтобы в сети можно было бы находить ресурсы не с помощью запоминания их числовых адресов, а путем использования более удобных для пользователя символьных имен. Еще одним удобным способом поиска ресурсов в сети является их автоматическое сканирование и предоставление пользователю списка обнаруженных ресурсов с символьными именами. Пользователь может просмотреть список текущих ресурсов сети - файл-серверов, серверов баз данных или разделяемых принтеров - и выбрать любой из них для использования.

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

2.2.2. Поддержка широковещательного трафика на канальном уровне

Практически все протоколы, используемые в локальных сетях, поддерживают широковещательные адреса (кроме протоколов АТМ). Адрес, состоящий из всех единиц (111...1111), имеет один и тот же смысл для протоколов Ethernet, TokenRing, FDDI, FastEthernet, 100VG-AnyLAN: кадр с таким адресом должен быть принят всеми узлами сети. Ввиду особого вида и регулярного характера широковещательного адреса вероятность его генерации в результате ошибочной работы аппаратуры (сетевого адаптера, повторителя, моста, коммутатора или маршрутизатора) оказывается достаточно высокой. Иногда ошибочный широковещательный трафик генерируется в результате неверной работы программного обеспечения, реализующего функции протоколов верхних уровней.

Широковещательный трафик канального уровня распространяется в пределах не только сегмента, образованного пассивной кабельной системой или несколькими повторителями/концентраторами, но и в пределах сети, построенной с использованием мостов и коммутаторов. Принципы работы этих устройств обязывают их передавать кадр с широковещательным адресом на все порты, кроме того, откуда этот кадр пришел. Такой способ обработки широковещательного трафика создает для всех узлов, связанных друг с другом с помощью повторителей, мостов и коммутаторов, эффект общей сети, в которой все клиенты и серверы "видят" друг друга.

2.2.3. Широковещательный шторм

Обычно протоколы проектируются таким образом, что уровень широковещательного трафика составляет небольшую долю общей пропускной способности сети. Считается, что нормальный уровень широковещательного трафика не должен превышать 8% - 10% пропускной способности сети. Однако, уже при достижении порога в 5% считается целесообразным провести анализ узлов, которые генерируют наибольщую долю широковещательного трафика - возможно, они нуждаются в реконфигурации.

Каждый протокол-источник широковещательных пакетов чаще всего порождает широковещательный трафик постоянной интенсивности, так как посылает в сеть пакеты фиксированного размера через определенные промежутки времени. Например, протокол SAP объявляет о существовании конкретного файл- или принт- сервиса каждые 60 секунд с помощью широковещательного сообщения фиксированного размера. Можно привести пример источника, порождающего широковещательный трафик переменной интенсивности. Таким источником является протокол обмена маршрутной информации RIP, который раз в 30 или 60 секунд рассылает по сети содержимое таблицы маршрутизации, а так как эта таблица может иметь переменный размер, то и интенсивность трафика, создаваемого протоколом RIP, может изменяться.

Общая интенсивность широковещательного трафика в сети будет определяться двумя факторами - количеством источников такого трафика и средней интенсивностью каждого источника. Протоколы локальных сетей разрабатывались в начале 80-х годов в расчете на сравнительно небольшое число компьютеров, генерирующих широковещательный трафик, а также с учетом большого запаса пропускной способности каналов локальных сетей (10 Мб/c) по сравнению с потребностями файлового сервиса миникомпьютеров и настольных компьютеров того времени. Поэтому стеки протоколов, которые проектировались исключительно для применения в локальных сетях - NovellNetWareIPX/SPX и стек NetBIOS/SMB компаний IBM и Microsoft - широко пользовались широковещательными рассылками для создания максимума удобств для пользователей, которым не нужно было запоминать имена и адреса серверов.

Стек TCP/IP проектировался в расчете на работу в любых условиях - как в локальных сетях, так и в глобальных сетях с низкоскоростными каналами. Поэтому стек TCP/IP гораздо реже пользуется широковещательными сообщениями - в основном только тогда, когда это крайне необходимо. Это гарантирует стеку TCP/IP приемлемый уровень широковещательности даже на низкоскоростных каналах, в то время как в сетях NetWare уровень широковещательности на глобальных каналах может достигать нежелательной цифры в 20%.

Превышение широковещательным трафиком уровня более 20% называется широковещательным штормом (bradcaststorm). Это явление крайне нежелательно, так как приводит к возрастанию коэффициента использования сети, а, следовательно, и к резкому увеличению времени ожидания доступа.

2.2.4. Поддержка широковещательного трафика на сетевом уровне

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

Принципы работы маршрутизатора не требуют от него обязательной передачи кадров с широковещательным адресом через все порты. Маршрутизатор при принятии решения о продвижении кадра руководствуется информацией заголовка не канального уровня, а сетевого. Поэтому широковещательные адреса канального уровня маршрутизаторами просто игнорируются. На сетевом уровне также существует понятие широковещательного адреса, но этот адрес имеет ограниченное действие - пакеты с этим адресом должны быть доставлены всем узлам, но только в пределах одной сети. В силу этого такие адреса называются ограниченными широковещательными адресами (limitedbroadcast). По таким правилам работают наиболее популярные протоколы сетевого уровня IP и IPX.

Однако, для нормальной работы сети часто оказывается желательной возможность широковещательной передачи пакетов некоторого типа в пределах всей составной сети. Например, пакеты протокола объявления сервисов SAP в сетях NetWare требуется передавать и между сетями, соединенными маршрутизаторами, для того, чтобы клиенты могли обращаться к серверам, находящимся в других сетях. Именно так работает программное обеспечение маршрутизации, реализованное компанией Novell в ОС NetWare. Для поддержания этого свойства практически все производители аппаратных маршрутизаторов также обеспечивают широковещательную передачу трафика SAP.

Подобные исключения делаются не только для протокола SAP, но и для многих других служебных протоколов, выполняющих функции автоматического поиска сервисов в сети или же другие не менее полезные функции, упрощающие работу сети.

Ниже описаны наиболее популярные в локальных сетях протоколы, порождающие широковещательный трафик.

2.2.5. Виды широковещательного трафика

2.2.5.1. Широковещательный трафик сетей NetWare

Стек протоколов сетей NetWare использует наибольшее число различных типов широковещательного трафика:

• SAP (Service Advertising Protocol). Включает два типа сообщений - сообщения серверов о предоставляемых ими сервисах и запросы клиентских станций о поиске соответствующих сервисов в сети. Сообщения серверов включают информацию об имени сервера, типе сервиса (например, файл-сервис или принт-сервис), а также о полном сетевом адресе сервиса, включающем номер сети, номер узла и номер сокета. Сообщения сервера распространяются раз в 60 секунд.
• RIP IPX (Routing Information Protocol). Распространяет по интерсети информацию о составляющих сетях IPX, известных данному маршрутизатору, а также о расстоянии от данного маршрутизатора до каждой сети. Инормация распространяется каждые 60 секунд. Так как каждый сервер NetWare всегда является и маршрутизатором, то уровень трафика RIPIPX прямо пропорционален количеству серверов NetWare в интерсети, к которому следует добавить также количество установленных аппаратных маршрутизаторов, работающих по протоколу RIP.
• NLSP (NetWare Link State Protocol). Новый протокол обмена маршрутной информацией, который серверы NetWare и IPX-маршрутизаторы независимых производителей могут использовать вместо протокола RIP. Протокол NLSP создает меньший уровень широковещательного трафика, так как основную часть его широковещательных сообщений представляют сообщения об изменении состояния связей в сети и состояния самих маршрутизаторов. Очевидно, что в надежной сети такие сообщения генерируются достаточно редко. Протокол NLSP создает также и периодически генерируемый трафик, но он используется только для тестирования связей между соседними маршрутизаторами и порождает пакеты очень небольшой длины.
• NDS (NetWare Directory Services). Служба NDS сетей NetWare представляет собой централизованную справочную службу, хранящую информацию о всех пользователях и ресурсах сети. При наличии в сети сервера, выполняющего функции NDS, отпадает необходимость постоянной генерации трафика протокола SAP остальными серверами сети. Однако сам сервер службы NDS пользуется протоколом SAP для того, чтобы клиенты сети NetWare автоматически смогли узнать о его существовании и адресе. Поэтому служба NDS создает в сети собственный широковещательный трафик взамен трафика, создаваемого отдельными серверами. В сети может существовать несколько серверов NDS, реализующих распределенную и резервируемую структуру справочной службы, поэтому уровень широковещательного трафика NDS может быть значительным.
• Пакеты Keepalive протокола NCP (другое название - watchdog). С помощью пакетов этого типа сервер и клиент сообщают друг другу о том, что они работают и намерены поддерживать логическое соединенение. Пакеты keepalive используются в том случае, когда между сервером и клиентом длительное время (более 5 минут) нет обмена другими данными, что бывает в том случае, когда пользователь на длительное время отлучается от своего компьютера, оставляя его включенным.

2.2.5.2. Широковещательный трафик сетей TCP/IP

Как уже отмечалось, в сетях TCP/IP широковещательный трафик используется гораздо реже, чем в сетях NetWare. Широковещательный трафик в сетях TCP/IP создают протоколы разрешения IP-адресов ARP и RARP (реверсивный ARP), а также протоколы обмена маршрутной информацией RIPIP и OSPF. Протоколы ARP и RARP используются только в локальных сетях, где широковещательность поддерживается на канальном уровне. Протокол RIPIP принципиально ничем не отличается от протокола RIPIPX, а протокол OSPF является протоколом типа "состояния связей" как и протокол NLSP, поэтому он создает широковещательный трафик гораздо меньшей интенсивности, чем RIP.

2.2.5.3. Широковещательный трафик сетей NetBIOS

Протокол NetBIOS широко используется в небольших сетях, не разделенных маршрутизаторами на части. Этот протокол поддерживается в операционных системах WindowsforWorkgroups и WindowsNT компании Microsoft, в операционной системе OS/2 Warp компании IBM, а также в некоторых версиях Unix. NetBIOS используется не только как коммуникационный протокол, но и как интерфейс к протоколам, выполняющим транспортные функции в сети, например, к протоколам TCP, UDP или IPX. Последняя роль NetBIOS связана с тем, что в ОС, традиционно использовавших NetBIOS в качестве коммуникационного протокола, многие приложения и протоколы прикладного уровня были написаны в расчете на API, предоставляемый протоколом NetBIOS. При замене протокола NetBIOS на другие транспортные протоколы разработчики приложений и ОС захотели оставить свои программные продукты в неизменном виде, поэтому появились реализации интерфейса NetBIOS, оторванные от его функций как коммуникационного протокола, и выполняющие роль некоторой прослойки, транслирующей запросы одного API в другой.

Основным источником широковещательного трафика в сетях, использующих NetBIOS либо в качестве интерфейса, либо в качестве протокола, является служебный протокол разрешения имен, который ставит в соответствие символьному имени компьютера его МАС-адрес. Все компьютеры, поддерживающие NetBIOS, периодически рассылают по сети запросы и ответы NameQuery и NameRequest, с помощью которых это соответствие поддерживается. При большом количестве компьютеров уровень широковещательного трафика может быть весьма высоким.

Маршрутизаторы обычно не пропускают широковещательный трафик NetBIOS между сетями.

Для уменьшения уровня этого трафика необходимо использовать централизованную службу имен, подобную службе WINS компании Microsoft.

2.2.5.4. Широковещательный трафик мостов и коммутаторов, поддерживающих алгоритм SpanningTree

Мосты и коммутаторы используют алгоритм покрывающего дерева SpanningTree для поддержания в сети резервных избыточных связей и перехода на них в случае отказа одной из основных связей. Алгоритм работы мостов и коммутаторов не позволяет использовать избыточные связи в основном режиме работы (при такой топологии связей кадры могут зацикливаться или дублироваться), поэтому основной задачей алгоритма SpanningTree является нахождение топологии дерева, покрывающей исходную топологию сети.

Для создания древовидной конфигурации мосты и коммутаторы, поддерживающие алгоритм SpanningTree постоянно обмениваются специальными служебными кадрами, которые вкладываются в кадры MAC-уровня. Эти кадры рассылаются по всем портам моста/коммутатора, за исключением того, на который они пришли, точно так же, как и пакеты протоколов RIP или OSPF маршрутизаторами. На основании этой служебной информации некоторые порты мостов переводятся в резервное состояние, и тем самым создается топология покрывающего дерева.

После установления этой топологии широковещательный трафик алгоритма SpanningTree не прекращается. Мосты/коммутаторы продолжают распространять по сети кадры протокола SpanningTree для контроля работоспособности связей в сети. Если какой-либо мост/коммутатор перестает периодически получать такие кадры, то он снова активизурует процедуру построения топологии покрывающего дерева.

Уровень широковещательного трафика протокола SpanningTree прямо пропорционален количеству мостов и коммутаторов, установленных в сети.

Маршрутизаторы трафик алгоритма SpanningTree не передают, ограничивая топологию покрывающего дерева одной сетью.

2.2.5.5. Ограничение уровня широковещательного трафика в составных сетях с помощью техники спуфинга

Если уровень широковещательного трафика слишком высок, то уменьшить его можно двумя спсособами. Первый состоит в применении других протоколов, реже пользующихся широковещательностью, например, протоколов стека TCP/IP. Однако, это не всегда возможно, так как приложения или операционные системы могут уметь работать только с определенными протоколами. В этом случае можно воспользоваться другим способом - техника спуфинга.

Эта техника была развита производителями коммуникационного оборудования, объединяющего локальные сети по низкоскоростным глобальным каналам, а именно, производителями удаленных мостов и маршрутизаторов.

Техника спуфинга (spoofing - обман, надувательство) основана на снижении интенсивности передачи служебных сообщений по глобальному каналу, в то время как локальные сети получают эти сообщения с нужной периодичностью. Маршрутизаторы и удаленные мосты, поддерживающие спуфинг, генерируют служебные пакеты для подключенной к ним локальной сети с нужной интенсивностью сами, но от имени узлов, которые расположены в удаленной сети.

Например, пакеты SAP и RIP могут передаваться по низкоскоростному каналу только один раз - при установлении связи между центральным офисом и филиалом. В дальнейшем эти пакеты генерируются маршрутизатором локальной сети филиала, имитируя сообщения, которые должны были бы в исходном варианте исходить от реальных устройств центрального офиса. При изменениях в сетевой структуре в сеть передается обновленный пакет SAP/RIP, который снова начинает генерироваться маршрутизатором с тем периодом, который принят в данном протоколе, например, 60 секунд.

Существуют различные реализации спуфинга. Наиболее его простой вариант заключается в простом исключении некоторого количества циклов передачи служебных пакетов между сетями, когда, например, в другую сеть передается только каждый 5-й или 10-й пакет SAP, поступающий из исходной локальной сети.

Спуфинг можно применять и в локальной составной сети для уменьшения уровня широковещательного трафика.

Техника спуфинга может приводить не только к повышению, но и к снижению производительности сети. Это может произойти в том случае, когда пара взаимодействующих в режиме спуфинга маршрутизаторов или мостов имеют различные параметры настройки этого алгоритма. Так, если один маршрутизатор настрен на передачу каждого 10-го пакета SAP, а второй маршрутизатор ждет прихода нового пакета SAP через каждые 5 периодов его нормальной передачи, то второй маршрутизатор будет периодически считать связь с серверами первой сети утерянной и объявлять об этом во второй сети, что приведет к разрыву логических соединений между клиентами и серверами, находящимися в разных сетях, а, значит, и к потере производительности. К такому же результату приведет ситуация, когда один маршрутизатор поддерживает режим спуфинга, а второй - нет.

Назад | Содержание | Вперед