Jump to content
Калькуляторы

VPLS

У кого-нибудь получалось построить отказоустойчивую сеть с VPLS?? Ситуация следующая: есть ядро в котором бегает VPLS. остальная сеть разделена на MST домены. когда в одном из сегментов сети происходит широковещательный шторм, он распространяется по всем MST доменам, в ядре все нормально. Как сделать, чтоб шторм был локализован в одном сегменте сети?? использование L3 не предлагать, нужно чтоб пользователи разных сегментов сети видели друг друга без всякой маршрутизации у них.

Share this post


Link to post
Share on other sites
У кого-нибудь получалось построить отказоустойчивую сеть с VPLS?? Ситуация следующая: есть ядро в котором бегает VPLS. остальная сеть разделена на MST домены. когда в одном из сегментов сети происходит широковещательный шторм, он распространяется по всем MST доменам, в ядре все нормально. Как сделать, чтоб шторм был локализован в одном сегменте сети?? использование L3 не предлагать, нужно чтоб пользователи разных сегментов сети видели друг друга без всякой маршрутизации у них.

имхо тут от возможностей оборудования все зависит, изолировать бродкаст штормы полностью вряд ли удастся, но вот такие вещи как rate-limit для

- Broadcast traffic

- Multicast traffic

- Traffic with unknown destination frames

на трибутарных интерфейсах ваших РЕ могут реально помочь.

Share this post


Link to post
Share on other sites
У кого-нибудь получалось построить отказоустойчивую сеть с VPLS?? Ситуация следующая: есть ядро в котором бегает VPLS. остальная сеть разделена на MST домены. когда в одном из сегментов сети происходит широковещательный шторм, он распространяется по всем MST доменам, в ядре все нормально. Как сделать, чтоб шторм был локализован в одном сегменте сети?? использование L3 не предлагать, нужно чтоб пользователи разных сегментов сети видели друг друга без всякой маршрутизации у них.

казалось бы - настроить storm-control на коммутаторах кораном не запрещено, а все народ ищет как бы посложнее чего придумать:-)

Share this post


Link to post
Share on other sites
У кого-нибудь получалось построить отказоустойчивую сеть с VPLS?? Ситуация следующая: есть ядро в котором бегает VPLS. остальная сеть разделена на MST домены. когда в одном из сегментов сети происходит широковещательный шторм, он распространяется по всем MST доменам, в ядре все нормально. Как сделать, чтоб шторм был локализован в одном сегменте сети?? использование L3 не предлагать, нужно чтоб пользователи разных сегментов сети видели друг друга без всякой маршрутизации у них.

имхо тут от возможностей оборудования все зависит, изолировать бродкаст штормы полностью вряд ли удастся, но вот такие вещи как rate-limit для

- Broadcast traffic

- Multicast traffic

- Traffic with unknown destination frames

на трибутарных интерфейсах ваших РЕ могут реально помочь.

Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу.

Тут некоторые вендоры тихо курят и на презентациях об этом молчат.

 

 

Share this post


Link to post
Share on other sites
Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу.

Тут некоторые вендоры тихо курят и на презентациях об этом молчат.

+1

Для этого у правильных вендоров есть такие штуки как MAC-address move loop detection, когда после определенного кол-ва перемещений MAC-адреса за заданный промежуток времени трибутарный интерфейс блокируется.

Share this post


Link to post
Share on other sites
Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу.

Тут некоторые вендоры тихо курят и на презентациях об этом молчат.

+1

Для этого у правильных вендоров есть такие штуки как MAC-address move loop detection, когда после определенного кол-ва перемещений MAC-адреса за заданный промежуток времени трибутарный интерфейс блокируется.

Хрена лысого он блокируется )

Таблица портится от единственного пролета, и все встает колом.

А все эти алгоритмы придуманы на несколько переизучений, и рассчитаны на исправление ситуации у двуногих клиентов, а не на сохранение таблицы в коре.

Edited by rus-p

Share this post


Link to post
Share on other sites
Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу.

Тут некоторые вендоры тихо курят и на презентациях об этом молчат.

+1

Для этого у правильных вендоров есть такие штуки как MAC-address move loop detection, когда после определенного кол-ва перемещений MAC-адреса за заданный промежуток времени трибутарный интерфейс блокируется.

Хрена лысого он блокируется )

Таблица портится от единственного пролета, и все встает колом.

А все эти алгоритмы придуманы на несколько переизучений, и рассчитаны на исправление ситуации у двуногих клиентов, а не на сохранение таблицы в коре.

Сорри, я не совсем уловил. MAC move detection задумывался для защиты от backdoor линков между двумя СЕ подключенных каждый к своему РЕ. В коре обычно split-horizon включен, там петли не может образоваться. Вы судя по всему какой-то конкретный дизайн подразумеваете и какого-то конкретного вендора.

Share this post


Link to post
Share on other sites
Сорри, я не совсем уловил. MAC move detection задумывался для защиты от backdoor линков между двумя СЕ подключенных каждый к своему РЕ. В коре обычно split-horizon включен, там петли не может образоваться. Вы судя по всему какой-то конкретный дизайн подразумеваете и какого-то конкретного вендора.

Петля у клиента конечно, а не в коре, иначе это уже вообще клиника.

А split-horizon не спасает в этой ситуации, т.к. трафик обернувшийся в кольце клиента вновь становиться легитимным для рассылки внутрь коры.

 

 

 

Share this post


Link to post
Share on other sites
Сорри, я не совсем уловил. MAC move detection задумывался для защиты от backdoor линков между двумя СЕ подключенных каждый к своему РЕ. В коре обычно split-horizon включен, там петли не может образоваться. Вы судя по всему какой-то конкретный дизайн подразумеваете и какого-то конкретного вендора.

Петля у клиента конечно, а не в коре, иначе это уже вообще клиника.

А split-horizon не спасает в этой ситуации, т.к. трафик обернувшийся в кольце клиента вновь становиться легитимным для рассылки внутрь коры.

хм... а можно архитектуру показать?

3-и года VPLS, а на описанных кошмарах как-то не подрывались ни разу (и лупы у абонентов бывают и т.п. описанные здесь)...

Share this post


Link to post
Share on other sites
хм... а можно архитектуру показать?

3-и года VPLS, а на описанных кошмарах как-то не подрывались ни разу (и лупы у абонентов бывают и т.п. описанные здесь)...

Архитектура стандартная - h-vpls, но тоже самое будет и в plane (полносвязанном) vpls.

Рисовать не тянет, на словах проще объяснить.

Вот купил клиент несколько точек. В одной из точек у него стоит гейтвей, назовем ее главной, tcp cессии идут со всех точек на этот гейвей, назовем их второстепенными.

И вруг у него в одной из второстепенных точек кольцо, мак адрес гейтвея оборачивается в кольце. Если это бкаст, то раскручивается, и вылетает обратно в сеть в виде шторма, только уже с неправильного направления. В результате fdb таблица мгновенно портиться, все легальные tcp сессии встают. Попытки гейтвея послать что-то по таймауту и ретранзмиту забиваются тут же постоянным потоком пакетов с мак адресом гейтвея со стороны второстепенной точки. И так пока клиент не уберет кольцо.

Спасает от этого только блокировка первого же пакета (и всех последующих) посланного со второстепенной точки, где случилось кольцо.

Лечится это только фильтрами на мак адреса, но вводить их статикой это понятно дело проще повеситься, а динамика, как выяснилось работает не у всех или не так как надо. Циску не проверял, но сомневаюсь, что реализовано.

Корни проблемы в масштабе услуги, когда у вас коммутатор в здании, скорее всего есть план скс и за нею следят. А когда у вас десять-двадцать-сто офисов, и кто-то где-то воткнул что-то не туда, кладется все, только в отличии от здания, пинают провайдера.

Вариант с маршрутизатором тоже не спасает, т.к. часто встроенных портов не хватает и шнурок от провайдера втыкают в коммутатор, а уже потом маршрутизатор в коммутатор.

Понятно, что происходит это не со всеми и редко, но одного случая с крупным клиентом бывает достаточно, чтоб он изменил свое мнение об услуге с положительного на отрицательное, т.к. его недоумение вполне понятно, какого хрена из-за одной точки ложиться весь виртуальный коммутатор.

Уследить за этим административно не реально, слишком много вовлечено территориально разнесенных людей.

Вот таки дела.

 

Edited by rus-p

Share this post


Link to post
Share on other sites

таки вопрос, почему у вас от петель не спасает оборудование доступа, в которое включены те самые стопецод офисов клиента?

Share this post


Link to post
Share on other sites
таки вопрос, почему у вас от петель не спасает оборудование доступа, в которое включены те самые стопецод офисов клиента?

Подскажите как ?

 

Рэйт лимитить шторм на акцессе это здорово, но таблице виртульного коммутатора все равно на какой скорости в нее влетают пакеты с неправильного направления, что на 64k, что все 10м.

Edited by rus-p

Share this post


Link to post
Share on other sites

ну допустим loopback detect с выключением порта, или акшн на сторм - выключение порта.

выключится одна точка, а не весь виртуальный коммутатор колом встанет :)

Share this post


Link to post
Share on other sites
таки вопрос, почему у вас от петель не спасает оборудование доступа, в которое включены те самые стопецод офисов клиента?

Подскажите как ?

 

Рэйт лимитить шторм на акцессе это здорово, но таблице виртульного коммутатора все равно на какой скорости в нее влетают пакеты с неправильного направления, что на 64k, что все 10м.

Забываете главное правило - "никому не верить". нужно и loop и storm и ограничение кол-ва маков на порту и т.п. Главное чтобы оно было разумным и было озвучено в условиях подключения.

Share this post


Link to post
Share on other sites

ну допустим loopback detect с выключением порта, или акшн на сторм - выключение порта.

не поможет :(

Share this post


Link to post
Share on other sites
ну допустим loopback detect с выключением порта, или акшн на сторм - выключение порта.
не поможет :(

через aging time всё очухается, если вы про случай когда происходит флап мака некого очень важного шлюза.

Share this post


Link to post
Share on other sites

Ну большинство клиентов строят в купленном vpls хаб энд споук, поэтому важный мак есть всегда и проблема с ним приводит к всеобщей аварии.

ingress, спасибо за наводку, мне тут подсказывают, что, например, на эджкоре минимальное время между отсылкой тестовых пакетов 1 сек. Это в принципе уже кое-что. А как реально быстро может быть уложен порт ?

 

visir, а можете подробнее ?

 

 

 

Share this post


Link to post
Share on other sites
ну допустим loopback detect с выключением порта, или акшн на сторм - выключение порта.
не поможет :(

через aging time всё очухается, если вы про случай когда происходит флап мака некого очень важного шлюза.

на мой взгляд Konstantin Klimchev очень даже прав...

 

важных шлюзов не так уж и много... их можно (нужно) жестко прописать статикой (fdb) на всех точках присутствия...

да это немного стесняет действия, но это оправданно....

Edited by Maruto

Share this post


Link to post
Share on other sites
Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу.

Тут некоторые вендоры тихо курят и на презентациях об этом молчат.

А можно узнать об оборудование которому от такой схемы сносит башню? Вы сказали что это не cisco, если судить по разговору. К сожалению HVPLS нет, но как я понимаю hub&spoke тоже пристутствует, лупы были, но крышу не сносило.

 

 

Share this post


Link to post
Share on other sites
Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу.

Тут некоторые вендоры тихо курят и на презентациях об этом молчат.

А можно узнать об оборудование которому от такой схемы сносит башню? Вы сказали что это не cisco, если судить по разговору. К сожалению HVPLS нет, но как я понимаю hub&spoke тоже пристутствует, лупы были, но крышу не сносило.

Да походу сносит у всех.

Может просто клиенты у вас сильно аккуратные. Проверил EdgeCore действительно работает и это радует.

Вот коллеги предложили посмотреть на loop detection. Мож действительно одна две секунды на укладывание порта предотвратят шторм, т.к. он начинается не в момент создания кольца, а после появления бкаст пакета.

 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this