[Tau]

Разбираем проблемы после небольшого даунтайма сети.

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

 

По дефолту на коммутаторе для разных типов трафика (multicast, multicast6, igm, stp и т.д.) задается лимит пакетов, который обрабатывается процессором.

Все что идет с превышением лимита - отбрасывается. Среди лимитируемого трафика есть и ARP, что логично - ARP обрабатывается CPU и в случае L2-петли широковещательные ARP убьют любую железку.

 

Но реализация у механизма лимитирования какая-то странная. Учитываются не только ARP-пакеты в VLAN, где у коммутатора есть L3-интерфейсы, но и все транзитные VLAN. Об этой потенциальной проблеме было известно давно, и вот она проявила себя - в одном из транзитных VLAN возник ARP-шторм из-за L2-петли, которая не был отсечена механизмом loopback-detection и broadcast storm control. Как следствие коммутатор начал дропать ВЕСЬ ARP-трафик, включая клиентов в смежных VLAN и менеджмент VLAN.

 

Вопросы:

1) Какой смысл лимитировать ARP в VLAN, где нет собственных L3-интерфейсов?

2) Как обстоят дела у разных вендоров с лимитированием ARP? Есть ли сегментирование по интерфейсам/слотам?

 

Есть подозрение, что причиной реализации является ограничение дешевого "чипсета", который отбирает все ARP-пакеты без выяснения принадлежности к VLAN и кидает их в сторону CPU. Мы не Ростелеком, чтобы требовать "доработки", давить "разрывом контракта" и т.п. Поэтому третий вопрос:

 

3) Есть ли основание признать эту "особенность" за серьезную проблему и требовать устранения?

 

Вендора и модель осознанно не называю.

[Negator]

Насколько я знаю ARP, да и весь трафик в транзитных вланах не должен попадать на процессор.

Вы вообще на 100% уверены что все было именно так как вы описали?

[Tau]

Вы вообще на 100% уверены что все было именно так как вы описали?

Да, именно так.

Там проблемы собственно две:

1) Какого хрена лимиты задаются на девайс, а не на порт.

2) Какого хрена проверяются лимиты там, где на них насрать (мой случай).

 

Эти потенциальные проблемы были видны давно, ТП вендора об этом сообщалось. ТП говорила что по другому никак. Но это ТП. В идеале хотелось бы эскалировать проблему выше.

[ShyLion]

По идее, если нет SVI в данном вилане, то нефиг и ловить ARP пакеты из него.

 

1) Какого хрена лимиты задаются на девайс, а не на порт.

А что тут странного? CPU-то один, на все порты. От того и лимит один.

[Tau]

А что тут странного? CPU-то один, на все порты. От того и лимит один.

Ну да. Есть всякие очереди, например, приоритеты.

Опять же, в целях траблшутинга удобно необходимо видеть статистику в раскладке по портам.

Edited September 12, 2016 by Tau

[ShyLion]

А что тут странного? CPU-то один, на все порты. От того и лимит один.

Ну да. Есть всякие очереди, например, приоритеты.

Опять же, в целях траблшутинга удобно необходимо видеть статистику в раскладке по портам.

По портам, да еще по виланам, плюс по протоколам да еще и на CPU - не умеют даже приличные бренды.

Edited September 12, 2016 by ShyLion

[Tau]

По портам, да еще по виланам, плюс по протоколам да еще и на CPU - не умеют даже приличные бренды.

По Vlan никто и не пишет. По протоколам оно и так разбито. А что умеют приличные бренды можно посмотреть в Huawei, в Hidden menu.

[s.lobanov]

Когда я тестил свитчи, требовал чтобы в транзитных вланах arp, igmp и прочая сигналка не попадала на CPU. Некоторые вендоры даже умудрялись это сделать по-нормальному, но нужно быть крупным, что вендоры к вам прислушивались. Если у вас крупная закупка это пара сотен свитчей, то после покупки вас пошлют с вероятностью 95%.

[vurd]

Что за свитч то? Элтекс что-ли?

[Ivan_83]

Всё просто же.

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

Если это л2 железка то выключить лимиты арпа и оставить один манагемент влан с ип интерфейсом.

[Tau]

Когда я тестил свитчи, требовал чтобы в транзитных вланах arp, igmp и прочая сигналка не попадала на CPU. Некоторые вендоры даже умудрялись это сделать по-нормальному, но нужно быть крупным, что вендоры к вам прислушивались.

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

 

Если у вас крупная закупка это пара сотен свитчей, то после покупки вас пошлют с вероятностью 95%.

Будем писать гневные статьи на Хабр о неудачной попытке импортозамещения. Без купюр. Но это крайняя мера.

Edited September 13, 2016 by Tau

[alibek]

чтобы в транзитных вланах arp, igmp и прочая сигналка не попадала на CPU

А по IGMP что имеется ввиду под транзитным VLAN?

L3-интерфейсов ведь у него нет.

Да и «прочая сигналка» как правило L3 не имеет.

[Володя]

Название свича в студию :)

[ichthyandr]

А что тут странного? CPU-то один, на все порты. От того и лимит один.

Ну да. Есть всякие очереди, например, приоритеты.

Опять же, в целях траблшутинга удобно необходимо видеть статистику в раскладке по портам.

По портам, да еще по виланам, плюс по протоколам да еще и на CPU - не умеют даже приличные бренды.

каталисты умеют:

no mac address-table learning vlan XXX

 

и трафик летит сквозняком. Только влан должен быть максимум на 2-х портах, иначе штормить может

[vurd]

Элтекс что-ли?

Будем писать гневные статьи на Хабр о неудачной попытке импортозамещения. Без купюр.

Название свича в студию :)

 

Я походу угадал.

 

Ловил примерно такую же проблему на olt. Там у меня штормящий с одного пон-дерева абонент уложил всю голову, так как _по какой-то никому не понятной причине_ коммутатор заглядывает в arp-пакеты и захлебывается в них. Это при том, что трафик транзитный, а функционал arp snooping выключен.

[Tosha]

Все что идет с превышением лимита - отбрасывается. Среди лимитируемого трафика есть и ARP, что логично - ARP обрабатывается CPU и в случае L2-петли широковещательные ARP убьют любую железку.

Нормально делать шторм контроль на портах доступа и тогда в случае шторма отсыхает только один порт (лучше одного абонента)

Нормально любые rate лимиты делать на вход к процессору и тогда ARP пролетающий без захода на L3 не фильтруется

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

Нормально делать сегментацию (и вплоть до приватных VLAN и VLAN-на-абонента) и ACL на клиентских портах

Нормально ставить на L3 железо умеющее аппаратно обрабатывать L3 или просто достаточно мощное и с развитыми средствами rate лимитов чтобы не скопом весь трафик

 

А если делать ненормально - то тогда возможны разные неприятности

 

Ставьте на агрегацию и ядро хорошие свичи и при условии удовлетворительной сегментации (хотя бы VLAN на 1,2 дома) глобальных проблем не будет. А если отключить прямой трафик между абонентами и гонять его через роутер (приватные VLAN + proxy-ARP) то тогда маловероятно что кто-то сумеет повалить сеть всего дома.

[No_name]

Нормально делать...

А если делать ненормально - то тогда возможны разные неприятности

Ставьте на агрегацию и ядро хорошие свичи и при условии удовлетворительной сегментации (хотя бы VLAN на 1,2 дома) глобальных проблем не будет...

Пока единственно правильный совет

[Tau]

Нормально делать шторм контроль на портах доступа и тогда в случае шторма отсыхает только один порт (лучше одного абонента)

Есть!

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

Есть!

Нормально делать сегментацию (и вплоть до приватных VLAN и VLAN-на-абонента) и ACL на клиентских портах

Есть! (vlan на абонента, management vlan на сегмент)

Нормально ставить на L3 железо умеющее аппаратно обрабатывать L3 или просто достаточно мощное и с развитыми средствами rate лимитов чтобы не скопом весь трафик

Есть!

А если делать ненормально - то тогда возможны разные неприятности

Ставьте на агрегацию и ядро хорошие свичи и при условии удовлетворительной сегментации (хотя бы VLAN на 1,2 дома) глобальных проблем не будет. А если отключить прямой трафик между абонентами и гонять его через роутер (приватные VLAN + proxy-ARP) то тогда маловероятно что кто-то сумеет повалить сеть всего дома.

Вы походу не поняли сути. Проблема с пропуском ARP на L2 коммутаторе, которому чужие ARP должны быть до п...ы, и обрабатывать их в соответствии с политикой storm-control для broadcast-трафика.

 

Пока единственно правильный совет

Ответ "делайте хорошо и будет вам счастье" всегда правильный.

[NikAlexAn]

Вы походу не поняли сути. Проблема с пропуском ARP на L2 коммутаторе, которому чужие ARP должны быть до п...ы, и обрабатывать их в соответствии с политикой storm-control для broadcast-трафика.

Дак озвучьте модель сего чудного дивайса то.

[dignity]

Вообще, странно, что Вы не говорите что это за модель - это же не клевета, не части КП, не NDA, а людям будет проще избегать косячного железа...

[Tau]

Вы походу не поняли сути. Проблема с пропуском ARP на L2 коммутаторе, которому чужие ARP должны быть до п...ы, и обрабатывать их в соответствии с политикой storm-control для broadcast-трафика.

Дак озвучьте модель сего чудного дивайса то.

 

Вообще, странно, что Вы не говорите что это за модель - это же не клевета, не части КП, не NDA, а людям будет проще избегать косячного железа...

 

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

[ShyLion]

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

Ну т.е. предлагаете нам тоже наступить на грабли вместе с Вами? Когда не только у тебя проблема, то как-то легче, да?

[Butch3r]

Тоже мне секрет нашли...Коммунити должен знать о чём речь.

[s.lobanov]

Когда я тестил свитчи, требовал чтобы в транзитных вланах arp, igmp и прочая сигналка не попадала на CPU. Некоторые вендоры даже умудрялись это сделать по-нормальному, но нужно быть крупным, что вендоры к вам прислушивались.

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

 

Если у вас крупная закупка это пара сотен свитчей, то после покупки вас пошлют с вероятностью 95%.

Будем писать гневные статьи на Хабр о неудачной попытке импортозамещения. Без купюр. Но это крайняя мера.

 

Дело было давно, поэтому маппинг фич на вендоров уже забыл. Из того что помню, QTech 2800 или 2850 (DCN) обрабатывал на CPU dhcp-запросы в тех вланах, где он включен не был. Пофиксили. Не знаю вошёл ли этот фикс в актуальные прошивки, но по крайней мере в той версии что они мне показали транзитные dhcp не грузили CPU. Но QTech в то время в разрезе свитчей был голым китаем, отличием был файл только vendor.cfg (как и SNR и многие другие вендоры), сейчас не знаю их ситуацию и что они делают

 

P.S. А кто ещё в РФ пишет софт для свитчей кроме Eltex'а?

[EShirokiy]

Озвучу, но после того, как получу официальный ответ от вендора.

Если Элтекс, то у них весьма адекватная ТП, подобный вопрос должны порешать без проблем.