Сотни и сотни больших и малых предприятий торгового города на Западе страны оставались без связи в течение сорока минут!
Около трёх часов дня дежурный инженер по имени Н. вбежал в серверную весь в поту с одышкой курильщика, чтобы перезагрузить центральный коммутатор. Это было единственным способом остановить широковещательный шторм (broadcast storm), возникший на spanning-tree сети.
Когда дежурный инженер Н. приступал к работе -адцатого дня, он не мог и подумать, что через несколько часов будет бежать куда-то со всех ног с полным послеобеденным желудком через улицы, дома и кварталы, и что вся эта физкультура будет вызвана одной-единственной командой “quit”.
Вот как всё произошло…
Около двенадцати дня на его рабочий стол поступило сообщение об исходе времени жизни (dead time) OSPF соседства в 40 секунд. И следом за ним сообщение о падении соседства в 666 VLAN’e. Инженер посуетился в кресле, открыл схемы и через некоторое время изобразил VLAN 666 на таком примерно рисунке:
На схеме он отметил, что все используемые VLANs как для данных (data plane), так и для управления, и маршрутизации (control plane и management plane) принадлежат одному instance. А это значит, что для них всех действует одна топология spanning-tree. И топология эта построена так, что все VLANs отдаются в порт стороннего оператора, который разделяет их по своей сети. VLANs 100-500 оператор отдаёт в одно направление, а VLAN 666 в другое. Такая странность объяснялась тем, что 666 в основном направлении у оператора был занят, и он решил отдать его в другое кольцо. Иными словами, сделал крюк. Для оператора это было дешевле, чем модернизировать сеть до QinQ. Изюминка этого альтернативного направления для 666-го была в том, что проходил он по участку с сомнительной отказоустойчивостью. Поэтому, когда Аннушка разлила масло (отрывок из “Мастер и Маргарита” Булгакова М., помните?), на участок между портом стороннего оператора и коммутатором Горькая, то канал в 666 VLAN’е отвалился. При этом для мышления spanning-tree топология осталась прежней, ведь чтобы произошло перестроение отвалиться должен был канал от Будёновки до порта стороннего оператора.
Каким-то образом дежурный инженер знал об этом костыле с 666 VLAN’ом (и огромное уважение ему за это!). И поскольку 666 отвечал за работоспособность целого сетевого объекта, который после падения ospf, естественно, был скорее мёртв, чем жив, то он решил действовать незамедлительно. А именно, выделить VLAN 666 в отдельный instance и применить для него различные с instance 1 атрибуты, так чтобы порт на Заре блокировался для всех VLAN'ов, но только не для 666. Идеальное решение! - подумал дежурный инженер и принялся воплощать задуманное!
Однако на последней команде он остановился. До него дошло, что он пытается применить незнакомую для него команду на центральном коммутаторе сети! И авария на другом объекте - это не повод так рисковать, да ещё в разгар рабочего дня! А если вся топология spanning-tree начнёт перестраиваться?! Это 30 секунд прерывания всех сервисов - не меньше! Он вытер каплю пота со лба, запустил eNSP и применил эти команды на симуляторе:
Уф, всё хорошо! Ещё понажимал Enter, чтобы убедиться, что управление не потеряно.
Казалось бы, всё нормально: создание нового instance не влияет на текущий процесс. Ага, как бы не так! Тут и крылась роковая ошибка дежурного инженера Н. Он не вышел из режима конфигурирования mst региона. Все изменения применяются только после команды quit!
Тем не менее обрадованный дежурный инженер побежал применять эти команды на центральном коммутаторе Будёновка и через пару минут потерял управление над всей сетью. Вся топология сети начала перестраиваться, запустился процесс полной калькуляции ролей и всего, всего, всего…
Покрывшись потом и покраснев со стыда, он ждал тридцать секунд, потом минуту, другую, но доступ ни до центрального, ни других коммутаторов не восстанавливался. Ещё через минуту пришло сообщение о шторме в VLAN’e управления 107. Он понял, что spanning tree не функионирует больше. Схватив куртку, он выбежал на улицу в сторону Будёновки, сожалея при этом о многом, но ещё и о том, что не сделал отложенного рестарта:
<Budenovka>schedule reboot delay 15
Где “15” это значение в минутах
Почему произошла петля в 107 VLAN’e и почему не восстановилась spanning-tree топология попробую рассказать в отдельной статье “Хоровод фреймов. Последствия отказа Spanning-Tree”. Проходите по этой ссылке, чтобы узнать об STP немного больше. Я расскажу как возникают петли и почему они могут скручивать мозги вашего коммутатора вечно!
Вопрос. А вы используете отложенный рестарт в своей работе в качестве страховочной меры?
