Перейти к содержимому
Калькуляторы

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

- Broadcast traffic

- Multicast traffic

- Traffic with unknown destination frames

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

- Broadcast traffic

- Multicast traffic

- Traffic with unknown destination frames

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

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

+1

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

+1

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

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

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

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

Изменено пользователем rus-p

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

+1

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Изменено пользователем rus-p

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Изменено пользователем rus-p

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

не поможет :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

Изменено пользователем Maruto

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.