[s.lobanov]

В чём смысл фразы "Fully manageable L3 switch, full wire speed switching" из http://i.mt.lv/route...0319094424.pdf?

 

В том, что на L2 он работает на скорости порта, а на L3 несколько медленнее.

 

Медленнее насколько? Сколько именно kpps этот новый микротик прожуёт на L3?

[alibek]

Медленнее насколько? Сколько именно kpps этот новый микротик прожуёт на L3?

Это мелочи. Зато L3. А если будет глючить, можно второй микротик поставить и настроить watchdog.

[Saab95]

Циско не микротик, чтобы такое случилось, надо очень постараться.

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

 

На цисках такое случается часто. Иногда обращаются организации с жалобой на то, что интернет плохо работает, смотришь что на порту происходит - а там куча трафика с адресами внутренней локалки абонента, весь трафик из IPSEC туннелей в открытом виде и т.п. Вот прикол говорить по каким серым адресам у них данные в центральный офис передаются.

[saaremaa]

Вот прикол говорить по каким серым адресам у них данные в центральный офис передаются.

Отнюдь это не проблема Cisco. Криворуких "одминов" Cisco и организаций жлобящихся на саппорт Cisco (те же обновления) много. :)

[NiTr0]

Сейчас компоненты на 100 и 1000 мбит стоят почти одинаково.

Разница эдак на порядок по ценам железа. 10G - еще дороже.

 

Микротик не циска, на нем при перегрузке процессора пакеты по всем портам не разлетаются.

На нем мультикаст/бродкаст флуд с одного порта по определению повалит по всем прочим портам в этом влане. Как и на любом другом свиче без LBD. И в ядро гиг флуда посыпется.

А использовать его как л3 - смешно выглядит :) Все равно, что тплинком офисным роутить...

[Стич]

http://www.dlink.ru/ru/products/1/1899_b.html

И стоит дешевле.

[Saab95]

На нем мультикаст/бродкаст флуд с одного порта по определению повалит по всем прочим портам в этом влане. Как и на любом другом свиче без LBD. И в ядро гиг флуда посыпется.

 

Ничего там не повалит. Кроме вланов есть много других интересных технологий.

[alibek]

Ничего там не повалит. Кроме вланов есть много других интересных технологий.

Я на форуме не так давно, но и то такой заход помню минимум дважды.

Окончиться он фразой «только нужно на всей сети использовать Mikrotik» через несколько постов.

[NiTr0]

Кроме вланов есть много других интересных технологий.

На 400МГц мыльнице, да :) С 10G портами :)

[s.lobanov]

На нем мультикаст/бродкаст флуд с одного порта по определению повалит по всем прочим портам в этом влане. Как и на любом другом свиче без LBD. И в ядро гиг флуда посыпется.

 

Относительно важности LBD я с вами в корне не согласен. Во-первых, шторм со стороны абонента не убивает mgmt свитча(ну кроме случаев, когда у вас насторено кучи всякого говно типа opt82, идущего через CPU и не умеющего делать лимит per-port). Во-вторых все современные L2 свитчи имеют функцию broadcast/u-unicast/mcast ограничения, в-третих лимит маков на портах и защитные ACL. И что самое важное, оно аппаратное и работает. Да, в случае шторма начнутся проблема у соседей по свитчу(в схеме vlan-per-switch, которая очень популярна), но вся остальная сеть будет работать нормально. Ну и наконец, есть vlan-per-user (хотя всё равно нужно по-максимуму использовать аппаратные возможности свитчей для защиты точки терминирования от кучи сигнального трафика)

 

Далее про само LBD. Так или иначе, оно работает с некоторым периодом, шлёт свой фрейм раз в N секунд. Т.е. если у абонента что-то сломалось после поднятия порта и несколько секунд(или хотя бы десятые доли секунды) вам всё равно прилетит шторм от абонента. И если у вас от одного шторма всё ложится(вся сеть в одном влане), то оно всё равно ляжет и только потом LBD это заметит(и то, если со стороны абонента вернётся LBD-фрейм, а я видел случай, когда у абонента была петля, а LBD его не ловило, потому что абонент не возращал мультикаст обратно).

 

Резюмируя, LBD это ненадёжный костыль, который может быть лишь вспомогательным инструментом, чтоб отлавливать битые порты(чтоб знать что их нельзя занимать или поменять свитч). Да, штукая полезная(для отлова битых портов по логам/трапам), но полагаться на неё как метод защиты от битых портов и кривых кастомеров ну никак нельзя.

Надёжно это сегментация(по вланам, внутри влана, чем меньше L2-сегмент, тем лучше), hw ACL-и, шторм-контроли, hw traffic-policy

[EShirokiy]

s.lobanov, LBD применяется скорее как элемент диагностики. При хорошей сегментации при петлях сеть не сильно страдает

[s.lobanov]

s.lobanov, LBD применяется скорее как элемент диагностики. При хорошей сегментации при петлях сеть не сильно страдает

 

Да, я именно так и написал. LBD нужен чтоб найти битый порт(ну или сказать абоненту что у него петля и поэтому ничего не работает)

[NiTr0]

Во-первых, шторм со стороны абонента не убивает mgmt свитча(ну кроме случаев, когда у вас насторено кучи всякого говно типа opt82, идущего через CPU и не умеющего делать лимит per-port).

Я что-то говорил о менеджменте свича? Впрочем, шторма обычно хватает для окукливания мозга свича до его прекращения (если там скажем ip ource guard и подобные фичи реализованы), ну и да, без опции 82 - это либо влан на пользователя, либо использование умного свича как тупаря...

 

Во-вторых все современные L2 свитчи имеют функцию broadcast/u-unicast/mcast ограничения,

Не все. И скорее всего данный тик тоже нифига подобного не умеет.

 

в-третих лимит маков на портах и защитные ACL.

Каким образом лимит маков спасет от бродкаст шторма?

 

Да, в случае шторма начнутся проблема у соседей по свитчу(в схеме vlan-per-switch, которая очень популярна), но вся остальная сеть будет работать нормально.

А при гиговом потоке флуда в ядро - еще и на соседних домах проблемы будут, а то и во всей сети... Или кто-то тянет десятку на район?

 

Далее про само LBD. Так или иначе, оно работает с некоторым периодом, шлёт свой фрейм раз в N секунд. Т.е. если у абонента что-то сломалось после поднятия порта и несколько секунд(или хотя бы десятые доли секунды) вам всё равно прилетит шторм от абонента. И если у вас от одного шторма всё ложится(вся сеть в одном влане), то оно всё равно ляжет и только потом LBD это заметит(и то, если со стороны абонента вернётся LBD-фрейм, а я видел случай, когда у абонента была петля, а LBD его не ловило, потому что абонент не возращал мультикаст обратно).

Флуд отсекается - сеть начинает работать нормально. Без LBD - флуд продолжается, сеть таращит.

[stason]

Долго у меня валялся Mikrotik Cloud Router Switch CRS125-24G-1S-IN не знал куда его впихнуть.

Пока 3-ю неделю трудится как P-роутер в MPLS облаке одного поселка. Сводим на него все MPLS-TE+VPLS тунели от Omnitik`ов и отправляем в Ядро.

Трафик 80-90 Мбит/с. Так как там чистый MPLS и немного бриджа нагрузка на нем 10-15%.

MPLS в поселке? да ещё и с TE?

Круто) если не секрет какая топология, зачем так настроено?

[s.lobanov]

MPLS в поселке? да ещё и с TE?

Круто) если не секрет какая топология, зачем так настроено?

 

А что собственно такого? Просто многие воспринимают mpls как что-то "навороченное" и нужное только крупняку. А в действительно, с точки зрения форвардинга, это обычные метки(на основании которых нужно принимать решение о пересылке данных), как, например, dot1Q. Никто же не удивляется вланам.

[s.lobanov]

Флуд отсекается - сеть начинает работать нормально. Без LBD - флуд продолжается, сеть таращит.

 

Отлично, т.е. Вы считаете нормальным, что (в среднем)2 секунды раз в час сеть "таращит" (пример для случая, когда период LBD=4 секунды и рекавери тайм=1 час). И опять же, LBD может не отработать, я видел такую ситуацию.

 

Каким образом лимит маков спасет от бродкаст шторма?

Он спасает не бродкаст-штормов, а от большого кол-ва маков с абонентского порта(такой глюк абонентского железа я тоже видел, хотя его природа не очень понятно). Это всё проблемы одного вида - "плохой" трафик от абонента

 

ну и да, без опции 82 - это либо влан на пользователя, либо использование умного свича как тупаря

если мы говорим про IPoE(а я лично не считаю, что оно чем-то лучше(или хуже) pppoe), то кроме opt82 и vlan-per-user есть ещё mac-portal(т.е. авторизация по маку, но с простой привязкой на веб-портале(при смене мака) абонент должен ввести логин/пароль от ЛК). И если vlan-per-user по каким-то(чаще всего, транспортным) причинам сделать сложно, то mac-portal это хорошая альтернатива opt82(требующего обработку сигнализации через CPU свитча)

И вообще, использование "умных" фич свитча это вечный траблшутинг этих фич. Не знаю масштабов вашей сети, но в больших это всегда где-то что-то да не работает из-за этих приблуд. И если уж на то пошло, то основная функция управляемого свитча это не "умная" работа с трафиком, а просмотр наличия линка, счётчиков на кастомеровских портах и т.п.(т.е. первичный траблшутинг проблемы).

 

А при гиговом потоке флуда в ядро - еще и на соседних домах проблемы будут, а то и во всей сети... Или кто-то тянет десятку на район?

Откуда гиг? Чаще всего используются FE-порты в сторону клиентов, т.е. это будет 100мбит на гиговых линков, что не так страшно. И опять же если есть suppression-ы, то и этого не должно быть.

[saaremaa]

MPLS в поселке? да ещё и с TE?

Круто) если не секрет какая топология, зачем так настроено?

Топология банальное кольцо (vlan на базу + управление внутри VPLS), но Я не захотел использовать *stp по некоторой причине и для удешевления сети (да-да :) ). Плюс там надо было чтобы трафик перекладывался при нагрузке одного из линков на агрегацию на обратное направление кольца для равномерной нагрузки и отказоустойчивость опять же.

Настройки к сожалению на пальцах не расскажешь.

Изменено 10 апреля, 2014 пользователем saaremaa

[NiTr0]

Отлично, т.е. Вы считаете нормальным, что (в среднем)2 секунды раз в час сеть "таращит" (пример для случая, когда период LBD=4 секунды и рекавери тайм=1 час).

Я считаю нормальным когда гиг флуда отсекается на порту, а не кошмарит весь сегмент как минимум (как максимум - всю сеть). Пускай и не сразу.

Ну и да, у нормальных свичей зачастую LBD срабатывает менее чем за секунду, и при этом порт не гасится а просто запрещается форвардинг трафика с него. И рекавери тайм роли не играет - наличие петли продолжает проверяться LBD пакетами

 

Он спасает не бродкаст-штормов, а от большого кол-ва маков с абонентского порта(такой глюк абонентского железа я тоже видел, хотя его природа не очень понятно).

Природа сего явления - хитро протаращило сохо роутер, и он решил переслать сетью скажем содержимое RAM.

 

Это всё проблемы одного вида - "плохой" трафик от абонента

Нет, проблемы совершенно разных видов.

 

если мы говорим про IPoE(а я лично не считаю, что оно чем-то лучше(или хуже) pppoe), то кроме opt82 и vlan-per-user есть ещё mac-portal(т.е. авторизация по маку, но с простой привязкой на веб-портале(при смене мака) абонент должен ввести логин/пароль от ЛК). И если vlan-per-user по каким-то(чаще всего, транспортным) причинам сделать сложно, то mac-portal это хорошая альтернатива opt82(требующего обработку сигнализации через CPU свитча)

Не сказал бы, что хорошая альтернатива. Контроль над пользователями теряется.

 

И вообще, использование "умных" фич свитча это вечный траблшутинг этих фич. Не знаю масштабов вашей сети, но в больших это всегда где-то что-то да не работает из-за этих приблуд. И если уж на то пошло, то основная функция управляемого свитча это не "умная" работа с трафиком, а просмотр наличия линка, счётчиков на кастомеровских портах и т.п.(т.е. первичный траблшутинг проблемы).

Смотря какие свичи. Может, и от STP отказаться, и от агрегации каналов, и от SNMP мониторинга? Купить дорогой умный свич, и юзать его как тупой тплинковский веб-смарт...

 

Откуда гиг? Чаще всего используются FE-порты в сторону клиентов, т.е. это будет 100мбит на гиговых линков, что не так страшно. И опять же если есть suppression-ы, то и этого не должно быть.

Ну а нахрена покупать гигабитный свич и юзать его со 100мбит портами?

[s.lobanov]

Не сказал бы, что хорошая альтернатива. Контроль над пользователями теряется.

 

Почему контроль-то теряется? при использовании mac-portal, авторизация, в общем случае, происходит по mac и S-Vlan. Если используется схема vlan-per-switch, то максимум что может сделать абонент, так это выйти с другого порта домового свитча. Если vlan на сегмент некоторого размера, то он может перемещаться в пределах этого сегмента.

 

При авторизации только по opt82, кабели в подъезде могут перепутаться, в принципе, когда у всех анлимы это не сильно страшно, но неприятно

 

И рекавери тайм роли не играет - наличие петли продолжает проверяться LBD пакетами

Петли нет, LBD открывает порт(включает или разблокирует логически, не важно), потом петля появилась и ждём следующего LBD цикла.

 

Я к тому, что нужен такой дизайн, для которого штормы(и вообще, любой мусор со стороны кастомера) не представляют опасности, даже если LBD их не поймал, а не расчитывать на костыль, который блокирует(или не блокирует, если не повезёт) это шторм, используя пробный фрейм

[EShirokiy]

s.lobanov, кстати, да.

при использовании mac-portal, авторизация, в общем случае, происходит по mac и S-Vlan. Если используется схема vlan-per-switch, то максимум что может сделать абонент, так это выйти с другого порта домового свитча. Если vlan на сегмент некоторого размера, то он может перемещаться в пределах этого сегмента

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

[DVM-Avgoor]

Привязка к порту - хорошо, знать мак абонента - нафиг не надо.

Вы вообще видели на крупных сетях с привязкой к макам кол-во заявок в CRM с "сменить мак, абонент поменял сетевуху/роутер/компьютер" ?

Не, однозначно только влан-пер-усер, только хардкор.

[NiTr0]

Почему контроль-то теряется? при использовании mac-portal, авторизация, в общем случае, происходит по mac и S-Vlan. Если используется схема vlan-per-switch, то максимум что может сделать абонент, так это выйти с другого порта домового свитча. Если vlan на сегмент некоторого размера, то он может перемещаться в пределах этого сегмента.

Этого мало? :)

 

При авторизации только по opt82, кабели в подъезде могут перепутаться, в принципе, когда у всех анлимы это не сильно страшно, но неприятно

Дополнительный контроль маков на портах, с алертами саппорту если мак Пети появился на порту Васи.

 

Петли нет, LBD открывает порт(включает или разблокирует логически, не важно), потом петля появилась и ждём следующего LBD цикла.

А куда же она подевалась?

Шлется пакет, не вернулся - разблокируется порт. Появляется петля - порт отключается...

 

Я к тому, что нужен такой дизайн, для которого штормы(и вообще, любой мусор со стороны кастомера) не представляют опасности, даже если LBD их не поймал, а не расчитывать на костыль, который блокирует(или не блокирует, если не повезёт) это шторм, используя пробный фрейм

Угу, и 10G на каждый дом для этого...

[EShirokiy]

Привязка к порту - хорошо, знать мак абонента - нафиг не надо.

Вы вообще видели на крупных сетях с привязкой к макам кол-во заявок в CRM с "сменить мак, абонент поменял сетевуху/роутер/компьютер" ?

Не, однозначно только влан-пер-усер, только хардкор.

с привязкой к порту (или vlan), что делать, если:

-свитч сгорел/сперли

-кабель порезали

к тому же надо будет вести дополнительную учетность, бэкапить конфиги и т.д.

А привязку по маку используют как минимум три крупных провайдера в СПб)

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

[sherwood]

Попробуйте сами сделать петлю и посмотреть, что случиться с оборудованием. Быстрее роутер или компьютер абонента сконфузится, чем обсуждаемый коммутатор.

 

умирает мгновенно, любой из микротыков

[s.lobanov]

s.lobanov (10 апреля 2014 - 23:21) писал:

Почему контроль-то теряется? при использовании mac-portal, авторизация, в общем случае, происходит по mac и S-Vlan. Если используется схема vlan-per-switch, то максимум что может сделать абонент, так это выйти с другого порта домового свитча. Если vlan на сегмент некоторого размера, то он может перемещаться в пределах этого сегмента.

 

Этого мало? :)

лично я сторонник концепции any port-any service. в вырожденном случае(только инет) это просто any port. но многие со своим консервативным образом мышления не готовы менять свои взгляды на процессы тех.учета и обслуживания.

делайте все максимально надолгожно, просто и понятно, а не заставляйте л2 оборудование работать с 4ым уровнем и ещё фильтровать на 3ем заоодно

 

А куда же она подевалась?

Шлется пакет, не вернулся - разблокируется порт. Появляется петля - порт отключается...

ну ок, допустим. а что же делать в случае, если абонент не возращает мультикаст? всё, вся сеть лежит? нет, нужны другие методы защиты/изоляции проблемы, никак не зависящие от поведения абонента