Обычно две вещи мы хотим получить от нашей сети. Первая - это, чтобы всё работало корректно и нам не приходилось бы часто залазить под капот словно старого Жигули. И второе - мы хотим, чтобы всё работало сейчас, а не потом. Мы не хотим ждать час или два пока необходимые нам в конкретный момент времени сервисы наконец дадут отклик. Мы хотим полной работоспособности всего, что нам нужно прямо сейчас! И чтобы сделать эту надёжность реальной, нам на помощь придёт отказоустойчивость (fault tolerance), будь это отказоустойчивость роутеров, или отказоустойчивость коммутаторов или отказоустойчивость firewalls, или отказоустойчивость линков в L2 сети.
Есть неприятные последствия, когда протокол маршрутизации выходит из строя на одном роутере. Но в целом, когда это случается мы только теряем соединения с сетями, которые непосредственно подключены (directly connected) к этому роутеру и это не затрагивает остальной части нашей сети. Не так страшно, правда? Здесь мы всегда знаем, где искать занозу, использовав, например, traceroute! Но что же касается L2 сегмента?
Есть два вида отказа в STP. Один из них приводит к похожей проблеме, что я только упомянул, когда конкретные порты блокируются (blocking state), в то время как они должны передавать данные (forwarding state). Такая ситуация делает участок сети недоступным, но остальная его часть остаётся функционировать (как в случае с 666 vlan'ом в готовящейся к выходу статье “Сорок минут кошмара после quit”). Но что случается, когда заблокированные порты (которые должны быть заблокированными), переходят в активное состояние (forwarding)? Давайте поработает над этим сценарием, используя топологию ниже. Начнём с первого рисунка и выясним, что произойдёт, когда STP откажет. Предупреждаю брезгливых читателей - это не будет красиво!
Представим, если заблокированный порт на LSW4 перейдёт в состояние forwarding… Одно можно сказать уже точно - последствия будут разрушительными!
Фреймы, которые имеют адрес назначения в таблице мак-адресов, будут форвардиться в прежние порты; однако, любой широковещательный (broadcast), multicast и unicasts, которых нет в CAM (Content-addressable memory) теперь закружатся в бесконечной петле. Следующий рисунок покажет нам эту бойню. На каждом порту коммутатора лампочки будут попеременно зажигаться янтарным и зелёным цветами, а это верный признак начала больших проблем!
Фреймы станут накапливаться в сети, а пропускная способность снижаться. Нагрузка на процессор возрастёт до такой степени, что он перестанет работать. И всё это произойдёт за несколько секунд!
Вот перечень проблем в вышедшей из строя STP сети, о которых вам лучше знать, чтобы вы могли обнаружить их в своей корпоративной сети и, конечно, должны знать для сдачи экзамена:
- Загрузка на линки начинает возрастать, и всё больше и больше фреймов попадают в петлю. Запомните, что петля распространяется на все линки сети, потому что фреймы всегда распространяются на все порты. Эта ситуация будет выглядеть менее ужасной, если петля затронет только один VLAN. В этом случае она будет изолирована только теми портами, которые принадлежат этому VLAN, и всеми транковым линкам, которые содержат информацию об этом VLAN’e.
- Если образуется более чем одна петля, то трафик будет возрастать на всех коммутаторах, потому что кружащиеся в хороводе фреймы дублируются. Коммутаторы получают фрейм, делают его копию и отправляют во все порты. И они делают это снова и снова, и снова с одним и тем же фреймом, так же как и со всеми другими! И каждая копия этого фрейма будет кружиться вечно, потому что у фрейма нет ограничения по времени жизни, как у пакета (ip packet)!
- Таблица мак-адресов теперь окончательно нестабильна и не читабельна. Она больше не знает какой кому мак-адрес принадлежит, потому что один и тот же адрес хоста приходит сразу из нескольких портов коммутатора.
- Чрезвычайно высокая нагрузка на линки и на процессор, которая теперь доходит до 100% или около того, делает устройство неспособным к ответу, недостижимым, непригодным для поиска проблемы (troubleshooting), иными словами, случился кошмар высшей степени!
Единственной возможностью остановить его будет последовательно отключать каждый избыточный линк между коммутаторами пока вы не сможете найти источник. И не стоит этого бояться, потому что в итоге ваша деградированная сеть успокоится и вернётся к жизни после новой и успешной STP сходимости! Ваши разгорячённые коммутаторы оклемаются, хотя им будет нужна серьёзная терапия после этого!
Когда вы приступите искать причину, спровоцировавшую сбой, то хорошей стратегией будет возвращать избыточные линки обратно один за одним до тех пор, пока петля снова не возникнет. Первопричиной может быть вышедший из строя порт или даже коммутатор. Как только вы вернёте все линки на место, вам нужно тщательно проследить за сетью и иметь спланированный план как быстро изолировать проблему, если она снова произойдёт. Вы ведь не хотите пройти через этот кошмар снова?!
*Статья написана с использованием материалов от сетевых экспертов Todd Lammle и Keith Barker.
Вопрос. О чем будет говорить сценарий, при котором все порты на коммутаторе будут гореть янтарным цветом постоянно и при этом ни один из не будет передавать фреймы?)
