Билл Алдерсон и Дж. Cкотт Хогдал
Специалисты по сетевым технологиям Билл Алдерсон и Скотт Хогдал обсуждают проблему, возникшую в одной распределенной сети:"Совсем недавно, во время проводимого нами учебного занятия при анализе работы сети учебного центра пригласившей нас организации мы столкнулись с большой силы "штормом" широковещательных сообщений. Поскольку это был наш первый курс, читаемый в этой организации, то на занятиях присутствовали ее руководящий персонал и ведущие специалисты, оценивающие эффективность курса. Служащие, ответственные за конфигурирование маршрутизаторов, напряженно следили за тем, как мы исследовали сеть, работа которой периодически прекращалась.
Во время занятий нередко возникает что-либо непредвиденное, но это хорошо, так как решения реальных проблем ю прекрасные учебные примеры. В данном случае имел место "шторм" широковещательных сообщений в сети IPX. Печально только, что аналогичное явление имеет место и в рабочей сети этой организации".
Скотт: Эта проблема напомнила мне предупреждения, передаваемые иногда по телевидению: "Мы прерываем программу, чтобы сообщить вам о резком изменении погоды. В нашем районе наблюдаются сильные грозы. Мы настоятельно просим вас..."
Билл: Но в этот раз "катаклизм" случился в сети нашего клиента. Мы сразу поняли серьезность случившегося, когда обнаружили тысячи широковещательных сообщений, передаваемых по сети за короткий промежуток времени. При более внимательном рассмотрении удалось определить, что это были широковещательные сообщения протоколов IPX, передаваемые маршрутизаторами и серверами. Серверы NetWare (работающие с IPX) являются также и маршрутизаторами и при работе используют как протокол маршрутной информации (Routing Information Protocol ю RIP), так и протокол извещения об услугах (Service Advertising Protocol ю SAP ), даже в случае подключения к единственному сегменту сети.
Скотт: Короче говоря, мы выяснили, что от всех маршрутизаторов и серверов приходят широковещательные сообщения IPX RIP и IPX SAP.
Билл: Каждый пакет этих протоколов содержал "плохие новости" о том, что услуга или подсеть (в распределенной сети) более не доступна.
Скотт: Да! Это действительно плохие новости.
Билл: Пакеты, вызывавшие эту "бурю", исходили от маршрутизаторов, которые извещали о потере доступа к подсетям и услугам.
Скотт: При потере хотя бы одной подсети или сетевой услуги маршрутизатор посылает информирующий об этом пакет (широковещательное сообщение) всем узлам распределенной сети. Такой пакет принимается другими маршрутизаторами и серверами, и они в свою очередь объявляют (передавая широковещательные пакеты) всем о том, что больше не могут получать доступ к этой подсети или услуге.
Билл: Представьте себе, что вы имеете два маршрутизатора и пять серверов. Как только один из них отправит пакет IPX SAP с сообщением о недоступности подсети или услуги, остальные также передадут соответствующие широковещательные сообщения. Таким образом, о потере каждой подсети или услуги будет сообщено семь раз.
Скотт: Теперь представьте, что в вашей сети "потеряно" 500 подсетей или услуг. Умножив 7 на 500, вы получите 3500 широковещательных сообщений, посылаемых маршрутизаторами и серверами.
Билл: Это как раз та ситуация, о которой можно сказать, что легкие облачка превращаются в тяжелые грозовые тучи.
Скотт: Именно так. После того как нам стал понятен механизм возникновения "штормов" широковещательных сообщений, необходимо было попытаться разобраться в их причинах. Мы предположили, что анализ периодичности возникновения "штормов" может дать верный ключ к разгадке.
Билл: После этого, настроив фильтр перехвата данных на выделение пакетов, передаваемых одним маршрутизатором, мы стали "ловить" первый пакет каждого "шторма" широковещательных сообщений. Анализ этих пакетов показал, что соответствующее им сообщение относится к одной и той же теряемой подсети или услуге.
Определив временные интервалы между моментами возникновения "штормов" в сети, мы увидели, что они практически одинаковы (табл. 1). Анализ пакетов показал, что маршрутизатор сообщал о недоступности сервера CORPORATE1.
Скотт: Как показал анализ временных интервалов между "штормами", маршрутизатор сообщал о потере одной и той же подсети приблизительно каждые 5 мин.
Билл: После этого мы проанализировали пакеты SAP, извещающие о наличии услуг этого сервера. При анализе периодичности передач этих пакетов (табл. 2) стало видно, что они посылаются три раза с интервалом в одну минуту, а потом отсутствуют 180 с (или 3 мин).
Скотт: Поразмыслив над этим, мы пришли к выводу, что в данной сети работает маршрутизатор, который посылает пакеты RIP и SAP по каналу связи распределенной сети каждые 5 мин.
Билл: Это подтвердилось. Но, к сожалению, в таком режиме (который используется для экономии полосы пропускания распределенной сети) работал маршрутизатор только на одном конце канала связи распределенной сети. В то же время принимающий эти сообщения маршрутизатор был сконфигурирован так, что ожидал пакетов SAP и RIP каждую минуту.
Скотт: Таким образом, если информация о маршрутах и услугах не поступала в течение 2 мин, то маршрутизатор "начинал думать", что услуга или подсеть "умерла", и сообщал всем узлам сети эту плохую новость перед тем, как вычистить информацию о данной услуге или подсети из своих таблиц. Это и стало причиной "штормов" широковещательных сообщений.
Билл: Верно. Когда мы запрограммировали принимающий маршрутизатор на пятиминутный интервал получения информации SAP и RIP, то "шторма" в сети прекратились. После этого широковещательные сообщения SAP нашего маршрутизатора наблюдались каждые 60 с (см. нижнюю половину табл. 2).
Скотт: Это пример того, как увеличение интервала между повторными передачами сообщений RIP и SAP маршрутизатором распределенной сети, осуществленное с целью уменьшения числа широковещательных передач по ее медленному каналу связи, может привести к весьма нежелательному побочному явлению - "шторму" широковещательных сообщений.