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

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

/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

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

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


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

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

 

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

 

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

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


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

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

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

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

 

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

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

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

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

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

 

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

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

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


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

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

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

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

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

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

 

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

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

 

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

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


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

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

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


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

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

 

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

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


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

8e2a43668944.png

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

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


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

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

 

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

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


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

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

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

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


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

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

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

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


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

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

a5a8cdeeb09ef3d82e7136cb0238dcc0.png

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

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

 

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

 

850eda85611e153a862ebbf623063a74.png

 

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

 

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

4c016ca13a0c8bd5bf6430c7eba8d049.png

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

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

 

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

 

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

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

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


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

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

 

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

 

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

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


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

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

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

 

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

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

 

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

 

 

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

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

 

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

 

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

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

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


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

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

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

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

 

db28653c094f0cf4a202bfc582b51a8c.gif

 

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

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

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


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

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

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


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

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

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

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

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

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

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


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

добавил фильтр, где в 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?

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


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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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


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

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

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

 

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

 

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

 

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

 

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

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


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

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

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

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

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


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

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

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

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

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

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


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

Может тогда имеет смысл, поднять 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 к абоненту, с серыми адресами проблем нет, если белых адресов не достаточно много - тогда такая схема не всем подходит.

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


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

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

 

/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 к серверу

 

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

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

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


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

Join the conversation

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

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

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

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

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

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

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