Broadcast storm или как победить "мелких поганцев" в сети. Часть 1 Часть 2

In English

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

     Итак, как работает коммутатор когда все хорошо: коммутатор строит таблицы mac-адресов где каждому адресу соответствует порт, и необходимый клиенту трафик идёт уже ни как в старых хабах во все порты, а в конкретный порт в соответствии с mac-таблицей. До того, как коммутатор узнал порт, на котором живёт клиент, первая посылка идёт обычно во все порты, после чего от клиента приходит ответ и он попадает в mac-таблицу и только тогда с ним начинают работать по конкретному порту.

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

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

     Для начала, конечно, стоит избавиться от привычки отключать SpanningTree на оборудовании, если у вас такая привычка есть, и возможно поднастроить этот протокол в соответствии с топологией своей сети. По большому счету если вы не знаете , что там настраивать и сеть у вас небольшая, то он и по-умолчанию будет работать, и более того, почти никакие петли вашу сеть не парализуют. Почему "почти" ? Да потому, что парализуют петли, которые будут на оборудовании с включенным SpanningTree... Но у вас ведь может оказаться и не только такое оборудование :)

     Казалось бы, что может перегрузить или вообще положить такую вот сеть:

     10 гигабит между коммутаторами, гигабит каждому конечному пользователю + настроенный SpanningTree протокол, вернее даже MSTP. Так вот, ни дубль-линк между коммутаторами эту сеть не убьёт, ни кольцо на коммутаторе ядра, потому что MSTP все лишнее заблокирует. Более того, все коммутаторы тут соединены не единственными линками для повышения отказоустойчивости, и вся эта связка успешно работает благодаря MSTP. Варианты атак и неисправностей рассматривать не будем, а рассмотрим вариант, если в вашей сети есть "тупой" свитч... типа неуправляемого длинка... и петлю сделали на нём... Тут и STP, и MSTP окажутся бессильны :) Ваша сеть ляжет от этого "мелкого поганца" в считанные минуты, или вернее даже десятки секунд !:)

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

     Итак, STP от неуправляемого оборудования не спасает, даже наоборот, BPDU пакеты тоже размножаются со всех сторон и STP начинает хаотично блокировать и разблокировать порты с частотой раз в 2-3 секунды. Количество mac-адресов на портах особо не ограничить, ведь там свитчи, и маков может быть много и в нормальном состоянии, но зато можно ограничить броадкаст, а уж до кучи и мультикаст трафик!

     Есть на современных коммутаторах такие средства, как storm-control, broadcast limit и еще наверное какие-то варианты этой же самой методики на оборудовании разных производителей.

     Настройка broadcast-limit 10% на HP и storm-control broadcast level 10% на cisco почти полностью, вернее процентов на 80% оставляют мою сеть живой при возникновении петель на "тупом" оборудовании. Единственное, что пока меня беспокоит, что STP продолжает дурить. Все равно порты блокируются не те, что надо, и шторм с заблокированного порта продолжает штормить все равно, хоть и не сильно. Возможно, это происходит потому, что передача BPDU не блокируется при блокировке порта STP, и после блокировки инициатора шторма широковещательный шторм переходит в BPDU шторм.

     Вот пример:

     Петля на порту A5, он сразу заблокировался, и вслед за ним межкоммутаторный порт L2 тоже заблокировался. Это не парализует сеть, ведь есть дополнительные линки, но тем не менее не очень приятно, особенно если учесть, что заблокироваться вот так случайно может порт на котором важный сервер или еще что-то важное. Некоторые проблемы еще остались, но благодаря broadcast limit шторм режется почти полностью. Дело за тюнингом MSTP, но об этом в следующий раз :)

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