Доступность сервисов в сети является одним из показетелей качества ее работы.

 

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

 

Они могут быть самые разнообразные - вышедшие из строя свитчи (или отдельные их порты), обрывы кабеля (особенно между зданиями), патч-корды, подключенные обоими концами в один и тот же свитч (можете смеяться, но на моей памяти были случаи, когда сотрудники, переез­жая в другой отдел, отключали свой компьютер от локальной сети, а свободный конец патч-корда втыкали в свитч, образуя тем самым петлю и блокируя всю сеть). Если сеть распола­гается на территории с несколькими зданиями, путешествия из одной ее точки в другую могут отнимать немало времени.

 

Вариантов действий в данном случае несколько. Один из них - нанять дополнительного сотрудника в сетевой от­дел, если есть такая возможность Потом еще одного, и так далее. Другой вариант - попробовать построить такую сеть, которая будет гораздо более устойчива в работе и станет отвлекать вас от утреннего (дневного, вечернего) кофе го­раздо реже. Мне по душе второй вариант.

 

Рассмотрим несколько способов построения отказоу­стойчивой распределенной сети, которая сэкономит много вашего времени и, главное, нервов.

 

Оборудование локальной сети

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

 

Итак, задуманное нами невозможно осуществить на де­шевых неуправляемых свитчах, поскольку необходима под­держка в них нескольких протоколов, таких как STP (и его разновидности), OSPF (либо RIPv2), функции Loopback Detection и функций предотвращения сетевого шторма.

 

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

Storm Control

Самый простой минимум, который можем сделать, -это включить функцию Storm Control на свитче. Данная функция позволяет избежать наводнения локальной сети ненужными пакетами. Причиной этого может быть как не­исправное оборудование, так и преднамеренные действия злоумышленников. Как вариант - это может быть DDoS-атака с нескольких компьютеров в локальной сети на какой-либо сервер в той же сети. В целях предотвращения по­добных инцидентов механизм Storm Control позволяет контролировать различные типы трафика и ограничивать их. поступление на порт свитча. Как правило, трафик делится на несколько больших групп: broadcast, multicast, unicast. Некоторые свитчи позволяют также контролировать ICMP и некоторые другие типы трафика.

 

Механизм работы довольно прост. После включения дан­ной функции необходимо указать предельное количество пакетов в секунду для каждого типа трафика (в некоторых случаях указывается процентное отношение к максималь­ной пропускной способности порта). К примеру, можно указать, что broadcast, multicast, unicast будут идти без огра­ничений, а пакетов ICMP должно быть не больше 1000 в се­кунду. Свитч начнет с секундным интервалом проверять счетчики на интерфейсах, и, если какой-либо из лимитов будет превышен, лишний трафик на интерфейсе станет от­фильтровываться. Удобная и простая функция. Единствен­ное, за чем нужно следить, - это правильное выставление лимитов для каждого типа трафика, чтобы они не превы­шались при нормальном режиме работы сети. К примеру, количество unicast-пакетов, приходящих на сервер, может быть 5000 в секунду, а может и 100 000 Поэтому предварительно необходимо оценить загрузку портов в локальной сети при нормальной ее работе.

 

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

 

STP, RSTP, MSTP

 

Данное семейство протоколов предназначено прежде всего для исключения петель (дублирующихся маршрутов) между коммутаторами в локальной сети. Это делается путем от­ключения дублирующихся линий связи между коммутатора­ми. Благодаря этому свойству протокола у нас появляется возможность искусственно вводить в нашу сеть избыточ­ные аплинки между свитчами, которые в будущем могут быть при необходимости задействованы.

Представим конфигурацию (рис 1.), где сеть, состоящая из четырех управляемых свитчей, каждый из которых соединен с дву­мя соседними по Ethernet. Таким образом, получается петля, которая приводит к зацикливанию пакетов внутри сети и как следствие к внутрисетевому шторму. STP позволяет отключить один из линков и сохранить корректную структуру сети. В случае об­рыва любого из основных линков включается резервный, и работоспособность сети сохраняется. После устранения неисправности и ввода в строй отсутствующего линка ре­зервный вновь отключается. Это очень удобно, поскольку сеть мгновенно реагирует на изменение топологии и под­страивается под нее без вашего вмешательства. Для того, чтобы без труда представлять себе, каким образом нам не­обходимо будет построить сеть и что с ней произойдет при отключении того или иного линка, нужно знать сам принцип работы STP-протокола, поэтому рассмотрим в общих чертах схему его работы.

 

Рисунок 1. Топология сети при использовании STP-протокола

Рисунок 2. Ситуация, при которой целесообразно включение функции Loopback Detection, как дополнение к протоколу STP

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Протокол STP не привязан к какому-либо конкретному устройству (например, свитчу), он может свободно под­держиваться любым активным устройством в сети. Однако поскольку в данном примере мы рассматриваем именно свитчи, то и говорить будем о протоколе STP, привязываясь именно к свитчам.

 

Итак, один из свитчей выбирается ведущим устройством (Designated Root Bridge). Топология сети будет строиться, отталкиваясь от этого свитча как центрального. Необходи­мо, чтобы ведущее устройство присутствовало всегда, даже если в сети работает всего один свитч. Из всех «кандидатов» на роль ведущего выбирается одно из устройств на основа­нии значения параметра Bridge Identifier, которое, по сути, определяет приоритет устройства. Оно может быть установ­лено вручную либо по умолчанию. В последнем случае мы не сможем контролировать то, какой свитч окажется веду­щим. Все остальные свитчи определяют порт, ближайший к корневому свитчу. Этот порт называется Root Port. Затем для каждого сегмента сети просчитывается самый корот­кий путь к корневому порту. Все мосты, через которые идет этот путь, называются назначенными мостами (Designated Bridge), а непосредственно подключенные к сети порты ком­мутатора - назначенными портами (Designated Port). Затем на всех коммутаторах блокируются все порты, не являющи­еся корневыми и назначенными. В итоге получается некая древовидная структура без петель, вершиной которой явля­ется ведущий коммутатор. Этот алгоритм будет выполняться каждый раз при изменении топологии сети.

 

Важно понимать, что в любом случае всегда итоговая то­пология сети не будет иметь петель, даже если мы искус­ственно их создали. Это означает, что мы можем добавить в сеть несколько резервных линков. Для рис. 1 это линк между свитчами 1 и 4. Чтобы указать свитчам, какой из лин­ков является основным, а какой резервным, используется параметр Path Cost, что означает стоимость маршрута. При­оритет всегда имеют порты с наименьшим Path Cost либо наименьшим bridge ID".

 

Таким образом, мы имеем инструмент, позволяющий эффективно организовывать резервирование линий связи в нашей сети при обслуживании компьютеров. Существует усовершенствованный протокол RSTP, работающий быстрее, и поэтому получивший сейчас большее распространение, нежели STP. Кроме того, суще­ствует MSTP-протокол, который удобно использовать в сети с несколькими VLAN. Классический STP-протокол после принятия решения блокирует порты целиком, а это не всег­да удобно. MSTP умеет блокировать выборочно необходи­мые VLAN, не блокируя при этом порт целиком.

 

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

 

При использовании данного протокола это, к сожалению, невозможно.

 

Есть еще одна проблема, вызванная использованием STP. Этот протокол не поддерживает средства аутентифи­кации и, как следствие, имеет ряд уязвимостей. Они позво­ляют злоумышленникам кратковременно нарушать работу сети. Ряд брендов поддерживают дополнительные функции, позволяющие снизить риск подобных атак.

 

Loopback Detection

Представим ситуацию, когда вы настроили RSTP-протокол на своих узловых свитчах. Они прекрасно работают, одна­ко к некоторым из портов этих свитчей подключены другие свитчи, неуправляемые. В таком случае возможна ситуация, когда по случайности, незнанию или по злому умыслу поль­зователь подключит один патч-корд в два порта неуправляе­мого свитча (см. рис.2). Следуя своей логике работы, свитч будет ретранслировать все широковещательные запросы на все свои порты, в том числе и на те, что создали петлю. Таким образом, создастся ситуация, когда лавинообразно возрастет огромное количество копий одного и того же широковещательного запроса, и сегмент сети перестанет работать вследствие создавшейся в нем перегрузки. По­добную ситуацию призван разрешить механизм Loopback Detection Задача данного механизма - определять наличие петель в неуправляемых сегментах сети.

 

Основной принцип работы протокола Loopback Detection состоит в том, что свитч посылает с порта Ethernet-фреймы определенного типа (а именно 9000 Loopback). Если на уда­ленной стороне существует петля, эти фреймы вернут­ся на свитч, и он констатирует факт наличия этой петли на порту. После того как будет обнаружена петля, данный порт должен быть погашен (либо только тот VLAN, в кото­ром обнаружилась петля, все зависит от того, насколько интеллектуален ваш свитч и какие возможности в него за­ложены).

 

В заголовке Ethernet-фрейма есть поле, указывающее размер фрейма либо его тип (в зависимости от значения, ко­торое туда помещено). Если значение поля равно или боль­ше 1536 в десятичном виде (либо 0600 в шестнадцатирич­ном), то оно интерпретируется как обозначение протокола более высокого уровня, и данные, содержащиеся во фрей­ме, будут декодироваться согласно этому протоколу. Если указан тип фрейма 0800, то на более высоком уровне ис­пользуется IP-протокол версии 4.

P.S.

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