vovan-pmr Опубликовано 19 января, 2011 · Жалоба У кого-нибудь получалось построить отказоустойчивую сеть с VPLS?? Ситуация следующая: есть ядро в котором бегает VPLS. остальная сеть разделена на MST домены. когда в одном из сегментов сети происходит широковещательный шторм, он распространяется по всем MST доменам, в ядре все нормально. Как сделать, чтоб шторм был локализован в одном сегменте сети?? использование L3 не предлагать, нужно чтоб пользователи разных сегментов сети видели друг друга без всякой маршрутизации у них. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
macharius Опубликовано 19 января, 2011 · Жалоба У кого-нибудь получалось построить отказоустойчивую сеть с VPLS?? Ситуация следующая: есть ядро в котором бегает VPLS. остальная сеть разделена на MST домены. когда в одном из сегментов сети происходит широковещательный шторм, он распространяется по всем MST доменам, в ядре все нормально. Как сделать, чтоб шторм был локализован в одном сегменте сети?? использование L3 не предлагать, нужно чтоб пользователи разных сегментов сети видели друг друга без всякой маршрутизации у них. имхо тут от возможностей оборудования все зависит, изолировать бродкаст штормы полностью вряд ли удастся, но вот такие вещи как rate-limit для - Broadcast traffic - Multicast traffic - Traffic with unknown destination frames на трибутарных интерфейсах ваших РЕ могут реально помочь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
White_Alex Опубликовано 20 января, 2011 · Жалоба У кого-нибудь получалось построить отказоустойчивую сеть с VPLS?? Ситуация следующая: есть ядро в котором бегает VPLS. остальная сеть разделена на MST домены. когда в одном из сегментов сети происходит широковещательный шторм, он распространяется по всем MST доменам, в ядре все нормально. Как сделать, чтоб шторм был локализован в одном сегменте сети?? использование L3 не предлагать, нужно чтоб пользователи разных сегментов сети видели друг друга без всякой маршрутизации у них. казалось бы - настроить storm-control на коммутаторах кораном не запрещено, а все народ ищет как бы посложнее чего придумать:-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 20 января, 2011 · Жалоба У кого-нибудь получалось построить отказоустойчивую сеть с VPLS?? Ситуация следующая: есть ядро в котором бегает VPLS. остальная сеть разделена на MST домены. когда в одном из сегментов сети происходит широковещательный шторм, он распространяется по всем MST доменам, в ядре все нормально. Как сделать, чтоб шторм был локализован в одном сегменте сети?? использование L3 не предлагать, нужно чтоб пользователи разных сегментов сети видели друг друга без всякой маршрутизации у них. имхо тут от возможностей оборудования все зависит, изолировать бродкаст штормы полностью вряд ли удастся, но вот такие вещи как rate-limit для - Broadcast traffic - Multicast traffic - Traffic with unknown destination frames на трибутарных интерфейсах ваших РЕ могут реально помочь. Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу. Тут некоторые вендоры тихо курят и на презентациях об этом молчат. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
macharius Опубликовано 20 января, 2011 · Жалоба Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу.Тут некоторые вендоры тихо курят и на презентациях об этом молчат. +1 Для этого у правильных вендоров есть такие штуки как MAC-address move loop detection, когда после определенного кол-ва перемещений MAC-адреса за заданный промежуток времени трибутарный интерфейс блокируется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 20 января, 2011 (изменено) · Жалоба Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу.Тут некоторые вендоры тихо курят и на презентациях об этом молчат. +1 Для этого у правильных вендоров есть такие штуки как MAC-address move loop detection, когда после определенного кол-ва перемещений MAC-адреса за заданный промежуток времени трибутарный интерфейс блокируется. Хрена лысого он блокируется ) Таблица портится от единственного пролета, и все встает колом. А все эти алгоритмы придуманы на несколько переизучений, и рассчитаны на исправление ситуации у двуногих клиентов, а не на сохранение таблицы в коре. Изменено 20 января, 2011 пользователем rus-p Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
macharius Опубликовано 20 января, 2011 · Жалоба Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу.Тут некоторые вендоры тихо курят и на презентациях об этом молчат. +1 Для этого у правильных вендоров есть такие штуки как MAC-address move loop detection, когда после определенного кол-ва перемещений MAC-адреса за заданный промежуток времени трибутарный интерфейс блокируется. Хрена лысого он блокируется ) Таблица портится от единственного пролета, и все встает колом. А все эти алгоритмы придуманы на несколько переизучений, и рассчитаны на исправление ситуации у двуногих клиентов, а не на сохранение таблицы в коре. Сорри, я не совсем уловил. MAC move detection задумывался для защиты от backdoor линков между двумя СЕ подключенных каждый к своему РЕ. В коре обычно split-horizon включен, там петли не может образоваться. Вы судя по всему какой-то конкретный дизайн подразумеваете и какого-то конкретного вендора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 20 января, 2011 · Жалоба Сорри, я не совсем уловил. MAC move detection задумывался для защиты от backdoor линков между двумя СЕ подключенных каждый к своему РЕ. В коре обычно split-horizon включен, там петли не может образоваться. Вы судя по всему какой-то конкретный дизайн подразумеваете и какого-то конкретного вендора. Петля у клиента конечно, а не в коре, иначе это уже вообще клиника. А split-horizon не спасает в этой ситуации, т.к. трафик обернувшийся в кольце клиента вновь становиться легитимным для рассылки внутрь коры. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 20 января, 2011 · Жалоба Сорри, я не совсем уловил. MAC move detection задумывался для защиты от backdoor линков между двумя СЕ подключенных каждый к своему РЕ. В коре обычно split-horizon включен, там петли не может образоваться. Вы судя по всему какой-то конкретный дизайн подразумеваете и какого-то конкретного вендора. Петля у клиента конечно, а не в коре, иначе это уже вообще клиника. А split-horizon не спасает в этой ситуации, т.к. трафик обернувшийся в кольце клиента вновь становиться легитимным для рассылки внутрь коры. хм... а можно архитектуру показать? 3-и года VPLS, а на описанных кошмарах как-то не подрывались ни разу (и лупы у абонентов бывают и т.п. описанные здесь)... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 21 января, 2011 (изменено) · Жалоба хм... а можно архитектуру показать?3-и года VPLS, а на описанных кошмарах как-то не подрывались ни разу (и лупы у абонентов бывают и т.п. описанные здесь)... Архитектура стандартная - h-vpls, но тоже самое будет и в plane (полносвязанном) vpls. Рисовать не тянет, на словах проще объяснить. Вот купил клиент несколько точек. В одной из точек у него стоит гейтвей, назовем ее главной, tcp cессии идут со всех точек на этот гейвей, назовем их второстепенными. И вруг у него в одной из второстепенных точек кольцо, мак адрес гейтвея оборачивается в кольце. Если это бкаст, то раскручивается, и вылетает обратно в сеть в виде шторма, только уже с неправильного направления. В результате fdb таблица мгновенно портиться, все легальные tcp сессии встают. Попытки гейтвея послать что-то по таймауту и ретранзмиту забиваются тут же постоянным потоком пакетов с мак адресом гейтвея со стороны второстепенной точки. И так пока клиент не уберет кольцо. Спасает от этого только блокировка первого же пакета (и всех последующих) посланного со второстепенной точки, где случилось кольцо. Лечится это только фильтрами на мак адреса, но вводить их статикой это понятно дело проще повеситься, а динамика, как выяснилось работает не у всех или не так как надо. Циску не проверял, но сомневаюсь, что реализовано. Корни проблемы в масштабе услуги, когда у вас коммутатор в здании, скорее всего есть план скс и за нею следят. А когда у вас десять-двадцать-сто офисов, и кто-то где-то воткнул что-то не туда, кладется все, только в отличии от здания, пинают провайдера. Вариант с маршрутизатором тоже не спасает, т.к. часто встроенных портов не хватает и шнурок от провайдера втыкают в коммутатор, а уже потом маршрутизатор в коммутатор. Понятно, что происходит это не со всеми и редко, но одного случая с крупным клиентом бывает достаточно, чтоб он изменил свое мнение об услуге с положительного на отрицательное, т.к. его недоумение вполне понятно, какого хрена из-за одной точки ложиться весь виртуальный коммутатор. Уследить за этим административно не реально, слишком много вовлечено территориально разнесенных людей. Вот таки дела. Изменено 21 января, 2011 пользователем rus-p Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 21 января, 2011 · Жалоба таки вопрос, почему у вас от петель не спасает оборудование доступа, в которое включены те самые стопецод офисов клиента? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 21 января, 2011 (изменено) · Жалоба таки вопрос, почему у вас от петель не спасает оборудование доступа, в которое включены те самые стопецод офисов клиента? Подскажите как ? Рэйт лимитить шторм на акцессе это здорово, но таблице виртульного коммутатора все равно на какой скорости в нее влетают пакеты с неправильного направления, что на 64k, что все 10м. Изменено 21 января, 2011 пользователем rus-p Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 21 января, 2011 · Жалоба ну допустим loopback detect с выключением порта, или акшн на сторм - выключение порта. выключится одна точка, а не весь виртуальный коммутатор колом встанет :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 21 января, 2011 · Жалоба таки вопрос, почему у вас от петель не спасает оборудование доступа, в которое включены те самые стопецод офисов клиента? Подскажите как ? Рэйт лимитить шторм на акцессе это здорово, но таблице виртульного коммутатора все равно на какой скорости в нее влетают пакеты с неправильного направления, что на 64k, что все 10м. Забываете главное правило - "никому не верить". нужно и loop и storm и ограничение кол-ва маков на порту и т.п. Главное чтобы оно было разумным и было озвучено в условиях подключения. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 21 января, 2011 · Жалоба ну допустим loopback detect с выключением порта, или акшн на сторм - выключение порта. не поможет :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 21 января, 2011 · Жалоба ну допустим loopback detect с выключением порта, или акшн на сторм - выключение порта.не поможет :( через aging time всё очухается, если вы про случай когда происходит флап мака некого очень важного шлюза. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 21 января, 2011 · Жалоба Ну большинство клиентов строят в купленном vpls хаб энд споук, поэтому важный мак есть всегда и проблема с ним приводит к всеобщей аварии. ingress, спасибо за наводку, мне тут подсказывают, что, например, на эджкоре минимальное время между отсылкой тестовых пакетов 1 сек. Это в принципе уже кое-что. А как реально быстро может быть уложен порт ? visir, а можете подробнее ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Maruto Опубликовано 21 января, 2011 (изменено) · Жалоба ну допустим loopback detect с выключением порта, или акшн на сторм - выключение порта.не поможет :( через aging time всё очухается, если вы про случай когда происходит флап мака некого очень важного шлюза. на мой взгляд Konstantin Klimchev очень даже прав... важных шлюзов не так уж и много... их можно (нужно) жестко прописать статикой (fdb) на всех точках присутствия... да это немного стесняет действия, но это оправданно.... Изменено 21 января, 2011 пользователем Maruto Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_user_ Опубликовано 21 января, 2011 · Жалоба Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу.Тут некоторые вендоры тихо курят и на презентациях об этом молчат. А можно узнать об оборудование которому от такой схемы сносит башню? Вы сказали что это не cisco, если судить по разговору. К сожалению HVPLS нет, но как я понимаю hub&spoke тоже пристутствует, лупы были, но крышу не сносило. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rus-p Опубликовано 21 января, 2011 · Жалоба Есть еще неприятный момент, мак адреса из рабочих сегментов, прогулявшись по кольцу, влетают обратно в vpls и убивают ему таблицу.Тут некоторые вендоры тихо курят и на презентациях об этом молчат. А можно узнать об оборудование которому от такой схемы сносит башню? Вы сказали что это не cisco, если судить по разговору. К сожалению HVPLS нет, но как я понимаю hub&spoke тоже пристутствует, лупы были, но крышу не сносило. Да походу сносит у всех. Может просто клиенты у вас сильно аккуратные. Проверил EdgeCore действительно работает и это радует. Вот коллеги предложили посмотреть на loop detection. Мож действительно одна две секунды на укладывание порта предотвратят шторм, т.к. он начинается не в момент создания кольца, а после появления бкаст пакета. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...