Comments 18
Каждый следующий виток “закольцованного” broadcast flood сопровождается экспоненциальным ростом количества unknown unicast пакетов в сегменте сети.
Так broadcast или unknown unicast? Они немного по-разному себя ведут и по-разному сеть убивают. Во всяком случае, broadcast-шторм не порождает unknown unicast пакеты.
в сети одного из наших клиентов случился бродкастовый шторм, который мгновенно перекинулся к нам
Вы меня пугаете! У вас L2 не отделён от клиентского?
Конечно же, мы отделяем клиентский L2-сегмент от своей сетевой инфраструктуры VLAN’ми, но при шторме в клиентской сети шторм воздействовал и на CPU наших коммутаторов доступа. Это привело к «развалу» наших внутренних STP процессов и в конечном итоге вызвало шторм во всех остальных VLAN. Рекомендации, приведенные в конце статьи, помогут предотвратить подобные ситуации)
Так broadcast или unknown unicast?
Да, здесь допущена неточность в формулировке. Широковещательный шторм как правило сопровождается ростом количества пакетов в сети (multicast, broadcast, unknown unicast). Поправили. Спасибо)
«Идеальный шторм» и как это лечитсяШторм лечится? У меня когнитивный диссонанс. От шторма можно бежать, со штормом можно бороться, но никак не лечить его.
TRILL – общепринятый стандарт, у которого быстро появились вендорские варианты: FabricPath от Cisco (который используем мы) и QFabric от Juniper.
Почему вы считаете QFabric вариантом TRILL? Начните с того, что QFabric это не протокол.
FabricPath — это предстандарт TRILL — проприетарное решение Cisco, несовместимое с TRILL и в следующем поколениее линейке Nexus (9К) его просто нет.
Еще TRILL позволяет… объединять распределенные дата-центры в единую L2-сеть
Первый же флуд (или ваш шторм) полетит в соседний ЦОД. Не делайте так. Инженеры Cisco не рекомендуют делать DCI на FabricPath.
А как же SPB? Простой, открытый протокол. Не требует специальных ASIC, в отлшичии от TRILL.
1. Да, вы правы, Qfabric не является протоколом, это проприетарная технология от Juniper.
В статье хотели показать, что Qfabric является вариантом TRILL в отношении формирования единой фабрики без угрозы возникновения петель коммутации внутри этой фабрики. Спасибо за уточнение, поправили этот момент в тексте и еще добавили VCS от Brocade.
2. Для того, чтобы избежать флуда на соседний ЦОД, необходимо разграничение на L3 (по маршрутизации), например, организовать связь между ЦОД через L3VPN. Для нас этот вариант не подходит, т.к. между ЦОД требуется растянутый L2 сегмент для работы vMotion.
Мы выбрали FabricPath, протокол достаточно надежен и прост в эксплуатации (легко настраивается, достаточно быстро можно добавлять новые VLAN). За 2 года эксплуатации ни разу не подвел.
При необходимости подключения в схему третьего ЦОД, можно будет рассмотреть возможность перехода на OTV + FabricPath.
В статье хотели показать, что Qfabric является вариантом TRILL в отношении формирования единой фабрики без угрозы возникновения петель коммутации внутри этой фабрики. Спасибо за уточнение, поправили этот момент в тексте и еще добавили VCS от Brocade.
2. Для того, чтобы избежать флуда на соседний ЦОД, необходимо разграничение на L3 (по маршрутизации), например, организовать связь между ЦОД через L3VPN. Для нас этот вариант не подходит, т.к. между ЦОД требуется растянутый L2 сегмент для работы vMotion.
Мы выбрали FabricPath, протокол достаточно надежен и прост в эксплуатации (легко настраивается, достаточно быстро можно добавлять новые VLAN). За 2 года эксплуатации ни разу не подвел.
При необходимости подключения в схему третьего ЦОД, можно будет рассмотреть возможность перехода на OTV + FabricPath.
1. Тогда и MetaFabric от Juniper, если о VCS от Brocade. Мухи с мухами, котлеты с котлетами. А к TRILL подходит SPB, который вы отчего-то игнорируете.
2. «Разграничение на L3» взаимоисключает «TRILL позволяет… объединять распределенные дата-центры в единую L2-сеть».
OTV + FabricPath — прошлый век, сейчас в моде (в том числе и у Cisco) EVPN, а OTV переведут на VXLAN, чтобы был, как EVPN.
Возможно, ваш пост не о том, как бывает, а о том, как вы сделали. Но тогда я не понимаю, к чему отсылки к QFabric и TRILL, объединяющий датацентры, соединенные по L3.
2. «Разграничение на L3» взаимоисключает «TRILL позволяет… объединять распределенные дата-центры в единую L2-сеть».
OTV + FabricPath — прошлый век, сейчас в моде (в том числе и у Cisco) EVPN, а OTV переведут на VXLAN, чтобы был, как EVPN.
Возможно, ваш пост не о том, как бывает, а о том, как вы сделали. Но тогда я не понимаю, к чему отсылки к QFabric и TRILL, объединяющий датацентры, соединенные по L3.
Методы построения DCI, пожалуй, тема для отдельного поста.
В этой публикации мы рассмотрели методы борьбы с петлями, испытанные нами на практике.
Построение Ethernet фабрик (мы используем FabricPath) — один из способов борьбы с петлями и один из приемлемых вариантов соединения ЦОД по L2 без угроз возникновения закольцованностей (проверено в боевых условиях).
VCS и Qfabric упомянуты как альтернативы FP, и мы не ставили цели перечислять все существующие технологии.
В этой публикации мы рассмотрели методы борьбы с петлями, испытанные нами на практике.
Построение Ethernet фабрик (мы используем FabricPath) — один из способов борьбы с петлями и один из приемлемых вариантов соединения ЦОД по L2 без угроз возникновения закольцованностей (проверено в боевых условиях).
VCS и Qfabric упомянуты как альтернативы FP, и мы не ставили цели перечислять все существующие технологии.
В коммутаторах уровня выше SoHo защита от Broadcast Storm обычно встроена и не требует дополнительных действий.
Я не видел ни одной технологии, которая бы реально могла спасти от кольца, сделанного в неожиданном месте. Более того, я не могу себе представить, как такая технология могла бы появиться.
Hint: пара серверов с кривонастроенным soft bridge и двумя портами в один vlan (или просто приходящими на порт несколькими тегами) может доставить веселья всей сети «всего лишь» перекладывая пакетики в оба направления.
Hint: пара серверов с кривонастроенным soft bridge и двумя портами в один vlan (или просто приходящими на порт несколькими тегами) может доставить веселья всей сети «всего лишь» перекладывая пакетики в оба направления.
пара серверов с кривонастроенным soft bridge и двумя портами в один vlan
На серверных портах надо держать включенным bpdu-guard. «Правила техники безопасности написаны кровью».
Это если вам его будут обратно транслировать. Добый человече может и не перекладывать «незнакомые» типы протоколов в интернетах. Говорю как человек, который однажды номер порта попутал в ovs'е и отправил весь ip трафик в другой вилан. Хотел конкретный, отправил весь. Если бы это были два сервера, то получилась бы знатная злая петля.
Действительно, от этой проблемы нет волшебной пилюли. Проблема комплексная и подход к её решению должен быть комплексным. Сложно полностью исключить возможность возникновения петель, но свести к минимуму этот риск и последствия широковещательных штормов очень даже реально.
В вашем примере с серверами при правильной настройке портов коммутатора можно смягчить последствия шторма, применив storm-control и ограничив количество обрабатываемых пакетов процессором с помощью инструмента CoPP.
Также можно настроить на порту Layer 2 ACL, разрешив трафик только с MAC-адреса этого сервера.
В вашем примере с серверами при правильной настройке портов коммутатора можно смягчить последствия шторма, применив storm-control и ограничив количество обрабатываемых пакетов процессором с помощью инструмента CoPP.
Также можно настроить на порту Layer 2 ACL, разрешив трафик только с MAC-адреса этого сервера.
Очень скоро эта лавина «забивает» полосу пропускания портов, на заднем плане красиво «вскипают» перегруженные процессоры коммутаторов – и ваша сеть превращается в памятник самой себе.
Забить всю полосу пропускания broadcast-траффиком очень даже не просто. Практически любой свитч намного раньше убьется MAC-learning-ом. Процессоры вскипают очень даже на переднем плане :)
Под каждый VLAN выделяется один RSTP-процесс
Извините, Вы путаете RSTP и PVSTP. RSTP вообще не знает про VLAN'ы.
Sign up to leave a comment.
«Идеальный шторм» и как это лечится