Комментарии 23
Странно.
Хде JDima?! )))
Хде JDima?! )))
Он по Цискам больше :)
Ээээ. Он не пропускает ни одного подобного поста ХП. А уж где L2 в ЦОД-е упоминается да еще миграция виртуалок… А уж между им и автором топика вообще давняя лубовь. Но это уже оффтоп :)
Дык тут миграция в пределах ЦОДа. Это дело нужное. Претензий к статье не имею (ну помимо бессодержательности и банальности, да и черт с ним).
Правда, вот «Отсутствие необходимости в STP/RSTP/MSTP» — необходимость в STP никуда не делась, так как BPDUшки нужны, чтобы обнаружить хотя бы банальное соединение патч-кордом двух соседних портов. И по всем внутренним интерфейсам фабрики BPDU будут бегать (чтобы от этого отказаться, надо или предварительно вырезать у архитектора мозг, чтобы он разучился думать, или внедрить нечто вроде QFabric, TRILL/FP и т.д.). И свое дерево STP построит. Но в нем не будет блокируемых в штатной ситуации портов, что есмь добро.
Да и в упомянутом 3-уровневом сценарии, когда требуется до черта и больше портов, не следует растягивать L2 по всей площадке, лучше бы ограничить сегменты отдельными стойками либо группами стоек, или по какому-нибудь иному принципу. Ибо L2 домен — это всегда жирная точка отказа, всегда могут возникнуть лупы или другие проблемы (не надо говорить, что IRF безглючен и идиотоустойчив, не поверю), и лучше заранее снизить масштаб бедствия.
Правда, вот «Отсутствие необходимости в STP/RSTP/MSTP» — необходимость в STP никуда не делась, так как BPDUшки нужны, чтобы обнаружить хотя бы банальное соединение патч-кордом двух соседних портов. И по всем внутренним интерфейсам фабрики BPDU будут бегать (чтобы от этого отказаться, надо или предварительно вырезать у архитектора мозг, чтобы он разучился думать, или внедрить нечто вроде QFabric, TRILL/FP и т.д.). И свое дерево STP построит. Но в нем не будет блокируемых в штатной ситуации портов, что есмь добро.
Да и в упомянутом 3-уровневом сценарии, когда требуется до черта и больше портов, не следует растягивать L2 по всей площадке, лучше бы ограничить сегменты отдельными стойками либо группами стоек, или по какому-нибудь иному принципу. Ибо L2 домен — это всегда жирная точка отказа, всегда могут возникнуть лупы или другие проблемы (не надо говорить, что IRF безглючен и идиотоустойчив, не поверю), и лучше заранее снизить масштаб бедствия.
ну помимо бессодержательности и банальности, да и черт с нимзаконы мерфи в ИТ, безусловно, очень интересное и содержательное чтиво :)))
И по всем внутренним интерфейсам фабрики BPDU будут бегатьчто вы, JDima, какие BPDU по внутренним интерфейсам фабрики, на картинке irf-стэк, там все чуть иначе, чем вам представляется :) и для петель на доступе совсем не обязательно поднимать stp
законы мерфи в ИТ, безусловно, очень интересное и содержательное чтиво
Кровавая мстя :)
какие BPDU по внутренним интерфейсам фабрики
То есть по LACPам в направлениях вверх-вниз не бегают BPDU? Точно-точно? Все устройства на картинках от ядер до TOR объединены в один IRF стек?
(под фабрикой я понимаю как раз всё изображенное на картинке, всю коммутационную инфраструктуру)
и для петель на доступе совсем не обязательно поднимать stp
Ну так расскажите поподробнее, каким образом без отправки BPDU обнаруживаются лупы. Варианты — или тот самый патч-корд, или на сервере кто-то поднял бридж вместо бондинга.
по LACPам в направлениях вверх-вниз не бегают BPDU, посмотрите на картинку внимательнее, схема линейная — стэк агрегатом соединяется со стэком, или это вы LACP DU с BPDU попутали?
по LACPам в направлениях вверх-вниз не бегают BPDU
Ну то есть это как раз тот случай, когда «надо предварительно вырезать у архитектора мозг» :)
Допустим, на ядре и на агрегации по каким-то причинам есть два одинаково настроенных порта (транки, идентичный или схожий список VLANов). Их соединили вместе. И теперь у нас между ядром и агрегацией есть как основной LACP транк, так и левый патч-корд (для красоты спецэффектов допустим, что 10G). Вопрос: что произойдет дальше?
(о реактивных мерах по защите от колец на минуту забудем — они могут снизить урон, но не до нуля)
Может лупы каким-нибудь упрощенным механизмом детектятся, типа кипаливов (ectp или подобное). У длинка например оно может работать не только как port-based, но и как vlan-based. Но конечно при патчкорте из порта в порт на доступе, допустим, такой механизм сработает только выше, на аплинке и отрубит все.
Может лупы каким-нибудь упрощенным механизмом детектятся
Я бы послушал.
Но BPDU тоже очень даже кипалайвы. Все привыкли к тому, что они должны обнаруживать лупы. Смысл что-то менять? В случае, когда в штатной ситуации блокируемые порты отсутствуют, STP ведет себя как ягненок. Просто предохранительный механизм, который однажды может спасти сеть от коллапса. Хуже от него не будет.
И лозунг «отказ от STP» вовсе не значит «отключаем нафиг». Реальный смысл — «обеспечим полное физическое резервирование без блокируемых STP линков».
Но конечно при патчкорте из порта в порт на доступе, допустим, такой механизм сработает только выше, на аплинке и отрубит все.
Офигеть механизм. Но да, это лучше шторма на весь сегмент.
>>Я бы послушал.
Может это военная тайна…
Может это военная тайна…
Тогда вендор обречен, если даже такие вещи не документированы.
Одна из причин, по которым Cisco стала чуть ли не монополистом — первоклассная документация и первоклассная программа подготовки специалистов.
Правда, бывают времена, когда на мой вопрос о реализации чего-либо TAC говорит «сие ведомо лишь девелоперам». Но как правило, этот момент действительно не принципиален.
Одна из причин, по которым Cisco стала чуть ли не монополистом — первоклассная документация и первоклассная программа подготовки специалистов.
Правда, бывают времена, когда на мой вопрос о реализации чего-либо TAC говорит «сие ведомо лишь девелоперам». Но как правило, этот момент действительно не принципиален.
А вообще с механизмом loop detect (без stp, на keepalive-ах) в cisco я в свое время «с наскоку» не разобрался.
Вот на порту dlink-a с этой включенной функцией я виже что-то вроде (см. ниже) и все ясно
12:36:32.956958 00:0b:5f:52:00:01 > 00:0b:5f:52:00:01, ethertype Loopback (0x9000), length 60:
12:36:42.957394 00:0b:5f:52:00:01 > 00:0b:5f:52:00:01, ethertype Loopback (0x9000), length 60:
12:36:52.957804 00:0b:5f:52:00:01 > 00:0b:5f:52:00:01, ethertype Loopback (0x9000), length 60:
На циске ничего не вижу. Хотя вроде включено, точнее не выключено. Разные настройки на порту крутил, но снифером так ничего и не поймал. Однако это работает вроде, потому что иногда случается
%PM-4-ERR_DISABLE: loopback error detected on Gi0/48, putting Gi0/48 in err-disable state
Делал эксперимент. Отключал stp, подключал на порт циски (2960) неуправляемый свич и там делал петлю. Шторм наблюдал, консоль еле ворочалась, еррдизэйбла не случалось. Включал на порту 2960 сторм-контрол с не очень жетскими лимитами, луп ловился, но как-то через раз
16:07:45: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet1/0/2.
16:07:45: %PM-4-ERR_DISABLE: loopback error detected on Gi1/0/2, putting Gi1/0/2 in err-disable state
Еще оказалось, без stp петлю на порту ловит udld (обычный режим, не aggressive, без обязательной связи со смежным коммутатором), причем без сторм-контрола, успевает отрабатотать сразу и всегда
01:25:05: %UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Gi1/0/2, transmit/receive loop detected
01:25:05: %PM-4-ERR_DISABLE: udld error detected on Gi1/0/2, putting Gi1/0/2 in err-disable state
С keepalive-ами в циске так и не разобрался. То ли снифером смотрел криво, то ли еще что, но вопрос для меня остался мутным, как оно работает.
Вот на порту dlink-a с этой включенной функцией я виже что-то вроде (см. ниже) и все ясно
12:36:32.956958 00:0b:5f:52:00:01 > 00:0b:5f:52:00:01, ethertype Loopback (0x9000), length 60:
12:36:42.957394 00:0b:5f:52:00:01 > 00:0b:5f:52:00:01, ethertype Loopback (0x9000), length 60:
12:36:52.957804 00:0b:5f:52:00:01 > 00:0b:5f:52:00:01, ethertype Loopback (0x9000), length 60:
На циске ничего не вижу. Хотя вроде включено, точнее не выключено. Разные настройки на порту крутил, но снифером так ничего и не поймал. Однако это работает вроде, потому что иногда случается
%PM-4-ERR_DISABLE: loopback error detected on Gi0/48, putting Gi0/48 in err-disable state
Делал эксперимент. Отключал stp, подключал на порт циски (2960) неуправляемый свич и там делал петлю. Шторм наблюдал, консоль еле ворочалась, еррдизэйбла не случалось. Включал на порту 2960 сторм-контрол с не очень жетскими лимитами, луп ловился, но как-то через раз
16:07:45: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet1/0/2.
16:07:45: %PM-4-ERR_DISABLE: loopback error detected on Gi1/0/2, putting Gi1/0/2 in err-disable state
Еще оказалось, без stp петлю на порту ловит udld (обычный режим, не aggressive, без обязательной связи со смежным коммутатором), причем без сторм-контрола, успевает отрабатотать сразу и всегда
01:25:05: %UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Gi1/0/2, transmit/receive loop detected
01:25:05: %PM-4-ERR_DISABLE: udld error detected on Gi1/0/2, putting Gi1/0/2 in err-disable state
С keepalive-ами в циске так и не разобрался. То ли снифером смотрел криво, то ли еще что, но вопрос для меня остался мутным, как оно работает.
UDLD и ethernet кипалайвы рассчитаны на обнаружение проблем с одним портом. Если соединить два порта, то они ни на что не повлияют. Общая цель кипалайвов — банальное обнаружение доступности хоста с другой стороны. И сколько смотрел сниффы, везде их видел (если не отключать вручную).
В случае «подключал на порт циски (2960) неуправляемый свич и там делал петлю» кольца внутри топологии управляемых свитчей нет. Это аналогично ситуации «сервер начал гадить броадкастами во весь линк. Защита — storm control, CoPP и так далее.
Storm control работает достаточно хитро. В результате его работы мощность шторма будет то снижаться, то повышаться, но в пределах определенного уровня. Если не сказать ему „сразу глуши порт“.
В случае «подключал на порт циски (2960) неуправляемый свич и там делал петлю» кольца внутри топологии управляемых свитчей нет. Это аналогично ситуации «сервер начал гадить броадкастами во весь линк. Защита — storm control, CoPP и так далее.
Storm control работает достаточно хитро. В результате его работы мощность шторма будет то снижаться, то повышаться, но в пределах определенного уровня. Если не сказать ему „сразу глуши порт“.
Это понятно, что с одним портом. Два порта я соединял на неуправляемом свиче, для порта 2960 это должен быть луп на порту, ведь если неуправляемый свич ничего не режет, эти служебные пакеты «обернутся» и придут циске на тот же порт.
A loopback error occurs when the keepalive packet is looped back to the port that sent the keepalive. The switch sends keepalives out all the interfaces by default. A device can loop the packets back to the source interface, which usually occurs because there is a logical loop in the network that the spanning tree has not blocked. The source interface receives the keepalive packet that it sent out, and the switch disables the interface (errdisable).
Что я и наблюдал (не в смысле снифера, а в смысле отключения порта), но почему-то не всегда. Сильно помогал срабатывать этой функции именно сторм-контрол, из чего можно сделать предположение, что когда шторм приходит быстро и масштабно, keepalive-ы или не отсылаются из-за загруженности цпу или что-то с приоритетом их отсылки на цыске.
A loopback error occurs when the keepalive packet is looped back to the port that sent the keepalive. The switch sends keepalives out all the interfaces by default. A device can loop the packets back to the source interface, which usually occurs because there is a logical loop in the network that the spanning tree has not blocked. The source interface receives the keepalive packet that it sent out, and the switch disables the interface (errdisable).
Что я и наблюдал (не в смысле снифера, а в смысле отключения порта), но почему-то не всегда. Сильно помогал срабатывать этой функции именно сторм-контрол, из чего можно сделать предположение, что когда шторм приходит быстро и масштабно, keepalive-ы или не отсылаются из-за загруженности цпу или что-то с приоритетом их отсылки на цыске.
Теперь понял идею.
Неуправляемый свитч, вообще говоря, запросто может резать и кипалайвы, и UDLD. Это довольно специфические фреймы. А неуправляемый свитч всяко умнее хаба.
L2 кипалайвы по идее должны обрабатываться хардварно. Но да, ситуация «начавшийся шторм за долю секунды выносит control plane» вполне типична. В первую очередь страдает STP…
Неуправляемый свитч, вообще говоря, запросто может резать и кипалайвы, и UDLD. Это довольно специфические фреймы. А неуправляемый свитч всяко умнее хаба.
L2 кипалайвы по идее должны обрабатываться хардварно. Но да, ситуация «начавшийся шторм за долю секунды выносит control plane» вполне типична. В первую очередь страдает STP…
Юзал для этого эксперимента древний компекс (не SOHO). UDLD он не резал точно, кипаливы если и резал, то не на постоянной основе, если так можно выразиться. Ведь я все же наблюдал иногда
16:07:45: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet1/0/2.
16:07:45: %PM-4-ERR_DISABLE: loopback error detected on Gi1/0/2, putting Gi1/0/2 in err-disable state
16:07:45: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet1/0/2.
16:07:45: %PM-4-ERR_DISABLE: loopback error detected on Gi1/0/2, putting Gi1/0/2 in err-disable state
как-то негусто… самые интересные вопросы не покрыты. как-то — связанность с другими цод (резервным, например), конвергентность SAN/LAN на одном устройстве (pros и cons), степень переподписки каналов в разных схемах, вопросы сетевой безопасности (где у вас в схеме фаерволлы??)
Вы не привели цифирки по количеству устройств в каждой схеме.
Которые в итоге повлияют на стоимость решения.
А теперь по поводу маркетингового булшита:
1) в «двухуровневой архитектуре» вы просто поставили коммутаторы L2 на доступ
2) в «трехуровневой архитектуре» вы просто поставили коммутаторы L2 на доступ и L3 на агрегацию.
Которые в итоге повлияют на стоимость решения.
А теперь по поводу маркетингового булшита:
1) в «двухуровневой архитектуре» вы просто поставили коммутаторы L2 на доступ
2) в «трехуровневой архитектуре» вы просто поставили коммутаторы L2 на доступ и L3 на агрегацию.
не уверен, что уловил ваш посыл, переформулируете?
- Приведите минимальное кол-во устройств в каждой схеме и рассчитайте вероятности выхода из строя по каждой точки отказа. А потом укажите время замены устройства. Про указание стоимости каждой точки отказа я уже молчу.
- Судя по стилю написания, вы все-таки «продажник», а не «технарь».
- Добавьте больше схем, в стиле Cisco, чтоб JDima было легче указывать слабые места.
- Прочитайте по классическую схему: клиент — коммутатор доступа — коммутатор агрегации — коммутатор ядра.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор архитектур сети ЦОД