PPPoE флуд на секторах микротик

[yKpon]

/interface bridge filter

add action=drop chain=forward in-bridge=bridge1 in-interface=!ether1 out-bridge=bridge1 out-interface=!ether1

 

без изменений

У вас бридж в радио, рутовый? rstp включен?

да

rstp не включен

 

в общем ситуация такая, на ether1 прёт pppoe-session(8864) 5 мегабит и оно флудит на все wds по 5м, и при 20 клиентах на wlan1 генерится траффик под 100мегабит, всё висит

 

может проблема в сервере pppoe?

/usr/sbin/pppoe-server -I pppoe -I vlan51 -L 10.168.0.1 -N 700 -T 60 -k

Edited March 14, 2016 by yKpon

[Saab95]

в общем ситуация такая, на ether1 прёт pppoe-session(8864) 5 мегабит и оно флудит на все wds по 5м, и при 20 клиентах на wlan1 генерится траффик под 100мегабит, всё висит

 

Так если у вас идет поток из сетевого порта, то фильтр на бридже не поможет, это же трафик от PPPoE сервера.

 

Соответственно если он летит всем, то адрес широковещательный, посмотрите на предмет этой темы, например снифером пакеты посмотреть хотя бы, встроенным в микротик.

[Nurjr]

Для начала включите rstp.

У вас флуд летит с сервера, такое бывает на микротик при авторозации новых пользователей, потом траффик растет лавинообразно. На чем поднят pppoe сервер?

Флуд при авторизации вы врятли победите, а лавину можно убрать.

 

создайте три правила на блридже.

1. проходящие из езер в бридж пропустить.

2. проходящие из бридж в езер пропустить

3. проходящие дроп ал.

Именно в этой последовательности

 

ps. копипастить лень объясняю по колхозному))

Edited March 14, 2016 by Nurjr

[Saab95]

создайте три правила на блридже.

1. проходящие из езер в бридж пропустить.

2. проходящие из бридж в езер пропустить

3. проходящие дроп ал.

Именно в этой последовательности

 

Вообще на микротике это делается одним правилом все 3 действия=)

Только вот такое уже советовали и не помогло, а как оно может помочь, когда флуд из сетевого порта в радио идет=)

 

Тут надо пакеты поснифать и посмотреть на какие маки данные идут, может PPPoE сервер плющит и он на широковещательный адрес рассылает данные. Именно по этой причине и делают отдельный влан или EoIP туннель на базу, что если заведется такая барабашка, то она в одном канале будет, легко найти и устранить.

[zrhyt]

Всем Здрасти такая проблема на микротике поднят pppoe сервер на порту wan трафик больше чем суммарный трафик всех клиентов. откуда он берется не могу понять.

[sokrat]

Всем Здрасти такая проблема на микротике поднят pppoe сервер на порту wan трафик больше чем суммарный трафик всех клиентов. откуда он берется не могу понять.

 

Ща потерпи, кроликовод придет и все разведет.

[zrhyt]

по скрину видно что трафик приходящий на wan больше на один мегобит чем трафик идущий к абонентам откуда он берется понять не могу куда копать?

[andryas]

по скрину видно что трафик приходящий на wan больше на один мегобит чем трафик идущий к абонентам откуда он берется понять не могу куда копать?

 

NAT, шейпер мспользуются?

[zrhyt]

настраивал по этой статьи http://www.lanmart.ru/blogs/how-to-become-isp

каждому назначил в профиле при создании клиента скорость 1536K/256K

[Saab95]

У микротика есть торч, запустите его на WAN порту, возможно это либо абоненты запрашивают с интернета больше трафика, чем пускает ваш шейпер и поэтому пришедшие данные просто теряются, либо просто идет мусорный трафик.

Увеличьте буфер пакетов в ограничении скорости - в шейпере щелкните 2 раза по динамическим правилам pppoe там увидите имя записи правила, обычно это default-small, на вкладке Types найдите эту запись и увеличьте количество пакетов с 10 до 1000.

[yKpon]

снял дампы снифером на одной базе в момент лавины, смотрю wireshark-ом и вот что видим

абонент с адресом 10.168.5.45 находится вообще территориально очень далеко от тестируемой базы, и почему его pppoe-session попал на эту базу не понятно

заблокировал этого абонента, мониторю дальше, через некоторое веря мониторим дальше и снова тоже самое только уже другой абонент и так далее

 

все базы находятся в одном влане и авторизуют юзеров на одном концентраторе

 

 

получается как бы pppoe-session начинает блуждать по L2 сети и броадкастить

 

и получаем вот это

https://i.gyazo.com/2d079d2466f1d8d4b0195fc309d0eb3b.gif

потом отпускает на пару минут и опять

 

вердикт такой: абонентские pppoe-session временами начинают флудиться по всей сети на короткое время, вопрос почему?

 

уточню что везде мыльницы, умные свитчи только на узле

Edited March 16, 2016 by yKpon

[Saab95]

уточню что везде мыльницы, умные свитчи только на узле

 

Вот и ответ, нужно делать отдельный влан или EoIP туннель до каждой БС. Как раз в сетях на мыльницах это самое то, но с ними лучше EoIP туннели все же использовать.

 

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

[Nurjr]

снял дампы снифером на одной базе в момент лавины, смотрю wireshark-ом и вот что видим

Уменьшено на 77% (1492 x 530) - Нажмите для увеличения

 

абонент с адресом 10.168.5.45 находится вообще территориально очень далеко от тестируемой базы, и почему его pppoe-session попал на эту базу не понятно

заблокировал этого абонента, мониторю дальше, через некоторое веря мониторим дальше и снова тоже самое только уже другой абонент и так далее

 

все базы находятся в одном влане и авторизуют юзеров на одном концентраторе

 

 

 

получается как бы pppoe-session начинает блуждать по L2 сети и броадкастить

 

и получаем вот это

 

https://i.gyazo.com/...fc309d0eb3b.gif

потом отпускает на пару минут и опять

 

вердикт такой: абонентские pppoe-session временами начинают флудиться по всей сети на короткое время, вопрос почему?

 

уточню что везде мыльницы, умные свитчи только на узле

 

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

 

В чем причина я так и не понял.

Вариантов два, либо это особенность протокола

 

либо косяк в арпах.

 

У нас концентратор был на микротике и было тоже самое.

Решали сигментированием, то есть один концентратор на базу.

[yKpon]

У нас концентратор был на микротике и было тоже самое.

Решали сигментированием, то есть один концентратор на базу.

подал на базу отдельный vlan с узла, на нём свой демон pppoe-server

 

 

траффик с wds33 сыпется по все wds-ы, заснифил wireshark-ом

Edited March 17, 2016 by yKpon

[Nurjr]

Покажите скрин правил фильтрации на бридже

[yKpon]

добавил фильтр, где в bridge2 все wds

/interface bridge filter
add action=drop chain=forward in-bridge=bridge2 in-interface=!ether1 out-bridge=bridge2 out-interface=!ether1

и всё успокоилось

причина такого поведения PPPoE мне до сих пор не понятна =)

Edited March 17, 2016 by yKpon

[Saab95]

добавил фильтр, где в bridge2 все wds

/interface bridge filter
add action=drop chain=forward in-bridge=bridge2 in-interface=!ether1 out-bridge=bridge2 out-interface=!ether1

и всё успокоилось

причина такого поведения PPPoE мне до сих пор не понятна =)

 

Если вы говорите что подали влан на БС, то почему интерфейс указан ether1 а не какой-то там vlan?

[tambu]

тема про PPPoE, но я тоже вставлю свои 5копеек. Наблюдаю точно такую же картину в виде "флуда на секторах".

Схема у меня "влан на пользователя", клиентские антенны настроены в режиме моста, абонентский влан соответственно растегируется на абонентском микротике. В процессе изучения данной проблемы я выяснил, что аномальный трафик (аномальный ли он?) лезет из порта пользователя. Понятно, что блокировка порта локализует и устраняет проблему в сети, но нам же надо, чтобы пользователь был счастлив и у него всё работало. Сниффер показал, что клиент обращается к абсолютно разным узлам как по http так и по https при этом мы видим TX RATE, который идеально совпадает с TX RATE во время флуда на каждую из клиентских микротиков на базовой станции. Я еще раз уточняю, что у меня каждый абонент сидит в своем влане, но это никак не решает трабл с генерацией трафика на секторах.

Решилась у меня проблема методом перевода абонентской точки в режим роутера, хотя меня это не совсем устраивает, но в конкретном случае проблема решилась.

Вопрос - как решать эту глюкавость грёбаного микротика?

[andryas]

Мнргоинтерфейсный бридж Микротика иногда криво работает с тегированным трафиком, а именно, превращается в хаб, посылая траффик на все интерфейсы.

Если у моста всего 2 интрфейса - тогда всё отлично :)

[tambu]

Мнргоинтерфейсный бридж Микротика иногда криво работает с тегированным трафиком, а именно, превращается в хаб, посылая траффик на все интерфейсы.

Если у моста всего 2 интрфейса - тогда всё отлично :)

как по мне, то не только с тегированным. Аналогичный флуд я видел в других местах, где абоненты болтаются в 1м влане.

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

Edited June 23, 2016 by tambu

[Saab95]

как по мне, то не только с тегированным. Аналогичный флуд я видел в других местах, где абоненты болтаются в 1м влане.

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

 

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

 

Правило имеет вид - если входящий интерфейс бридж и выходящий интерфейс бридж, если исходящий сетевой интерфейс не ether1, и входящий сетевой интерфейс не ether1, то делать дроп.

 

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

 

Отсюда следует что самая верная схема сети это транспорт по L3, тогда до абонента можно сделать EoIP туннель из центра, который поднять поверх PPPoE, что исключит объединение физических транспортных интерфейсов и не будет требовать какой-то отдельной адресации для антенн.

[nkusnetsov]

Отсюда следует что самая верная схема сети это транспорт по L3, тогда до абонента можно сделать EoIP туннель из центра, который поднять поверх PPPoE, что исключит объединение физических транспортных интерфейсов и не будет требовать какой-то отдельной адресации для антенн.

Может тогда имеет смысл, поднять MPLS/VPLS при наличии нормального оборудования? Благо он на микротике легко поднимается.

Edited June 24, 2016 by nkusnetsov

[tambu]

1. Флуд лезет только от определенных абонов. (это и есть проблема)

2. Микротик говно, это мы тоже знаем

3. Я решил вопрос жестким сегментированием, на управляемом свиче, где соединены даунлинки в сторону базовых, распределил юзерские диапазоны вланов строго на определенные порты. Хочу заметить, что стоит huawei s2300 и на нём я включал опцию port isolate (работает, ни маков с соседних баз я не увидел, l3 трафика тоже нет), но вот эти пакеты, которые ломают нам wifi всё-равно пролазят. Я в этом почти уверен.

Edited June 24, 2016 by tambu

[Saab95]

Может тогда имеет смысл, поднять MPLS/VPLS при наличии нормального оборудования? Благо он на микротике легко поднимается.

 

Да, так делают в сетях кабельных операторов, которые хотят предоставлять услугу в радио по той же схеме, что и по кабелю, то есть схема VLAN на абонента. Прямо так пускать вланы в радио нельзя - это сложно в реализации и создаст проблемы. Поэтому выделяют все радио в отдельную служебную сеть и далее делают 2 варианта - либо PPPoE, а поверх адресов VLPS интерфейс (адрес антенны абонента всегда постоянен), либо выдают IP по DHCP с привязкой по маку антенны - по этим адресам и работает VPLS туннель. Далее туннель бриджуется с сетевым портом и данные идут до абонента. В большинстве случаев используется PPPoE, т.к. это проще в реализации.

 

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

 

1. Флуд лезет только от определенных абонов. (это и есть проблема)

 

В правильной сети флуда не бывает.

 

2. Микротик говно, это мы тоже знаем

 

Я не знаю.

 

3. Я решил вопрос жестким сегментированием, на управляемом свиче, где соединены даунлинки в сторону базовых, распределил юзерские диапазоны вланов строго на определенные порты. Хочу заметить, что стоит huawei s2300 и на нём я включал опцию port isolate (работает, ни маков с соседних баз я не увидел, l3 трафика тоже нет), но вот эти пакеты, которые ломают нам wifi всё-равно пролазят. Я в этом почти уверен.

 

А правильно все решить отказом от L2 и переходом на L3, при этом от L2 трафика абонента можно вообще отказаться, терминируя IP абонента прямо на антенне, а все антенны работают в OSPF и подключаются к БС тоже с OSPF. Авторизация на центральной железке уже будет по IP адресу, а не порту или маку устройства абонента. Единственный минус такого решения это постоянная привязка IP к абоненту, с серыми адресами проблем нет, если белых адресов не достаточно много - тогда такая схема не всем подходит.

[777BLOODER777]

Может кому то и пригодится ....

 

/interface bridge filter

 

Разрешающие для IPTV (возможно либо изменить broadcast на multicast, unicast либо добавить аналогичное разрешающие)

add action=accept chain=forward comment="Allow for IPTV" in-interface=ether mac-protocol=ip out-interface=vlan_isp_rt1

add action=accept chain=forward in-interface=ether out-interface=vlan_isp_rt1 packet-type=broadcast

 

Разрешающие для PPPoE (Первое правило разрешает обнаружение серверов PPPoE, второе саму сессию PPPoE)

add action=accept chain=forward comment="Allow for PPPoE" in-interface=ether mac-protocol=pppoe-discovery out-interface=vlan_isp_rt1

add action=accept chain=forward in-interface=ether mac-protocol=pppoe out-interface=vlan_isp_rt1

 

Всё остальное блочим ("давай до свидание" =) )

add action=drop chain=forward comment="Everything else block" in-interface=ether out-interface=vlan_isp_rt1

 

 

 

in-interface=ether - от провайдера

 

out-interface=vlan_isp_rt1 - vlan к серверу

 

тишина и спокойствие ....

Edited February 25, 2017 by 777BLOODER777