yKpon Опубликовано 14 марта, 2016 (изменено) · Жалоба /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 Изменено 14 марта, 2016 пользователем yKpon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 14 марта, 2016 · Жалоба в общем ситуация такая, на ether1 прёт pppoe-session(8864) 5 мегабит и оно флудит на все wds по 5м, и при 20 клиентах на wlan1 генерится траффик под 100мегабит, всё висит Так если у вас идет поток из сетевого порта, то фильтр на бридже не поможет, это же трафик от PPPoE сервера. Соответственно если он летит всем, то адрес широковещательный, посмотрите на предмет этой темы, например снифером пакеты посмотреть хотя бы, встроенным в микротик. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nurjr Опубликовано 14 марта, 2016 (изменено) · Жалоба Для начала включите rstp. У вас флуд летит с сервера, такое бывает на микротик при авторозации новых пользователей, потом траффик растет лавинообразно. На чем поднят pppoe сервер? Флуд при авторизации вы врятли победите, а лавину можно убрать. создайте три правила на блридже. 1. проходящие из езер в бридж пропустить. 2. проходящие из бридж в езер пропустить 3. проходящие дроп ал. Именно в этой последовательности ps. копипастить лень объясняю по колхозному)) Изменено 14 марта, 2016 пользователем Nurjr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 14 марта, 2016 · Жалоба создайте три правила на блридже. 1. проходящие из езер в бридж пропустить. 2. проходящие из бридж в езер пропустить 3. проходящие дроп ал. Именно в этой последовательности Вообще на микротике это делается одним правилом все 3 действия=) Только вот такое уже советовали и не помогло, а как оно может помочь, когда флуд из сетевого порта в радио идет=) Тут надо пакеты поснифать и посмотреть на какие маки данные идут, может PPPoE сервер плющит и он на широковещательный адрес рассылает данные. Именно по этой причине и делают отдельный влан или EoIP туннель на базу, что если заведется такая барабашка, то она в одном канале будет, легко найти и устранить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zrhyt Опубликовано 15 марта, 2016 · Жалоба Всем Здрасти такая проблема на микротике поднят pppoe сервер на порту wan трафик больше чем суммарный трафик всех клиентов. откуда он берется не могу понять. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sokrat Опубликовано 15 марта, 2016 · Жалоба Всем Здрасти такая проблема на микротике поднят pppoe сервер на порту wan трафик больше чем суммарный трафик всех клиентов. откуда он берется не могу понять. Ща потерпи, кроликовод придет и все разведет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zrhyt Опубликовано 15 марта, 2016 · Жалоба по скрину видно что трафик приходящий на wan больше на один мегобит чем трафик идущий к абонентам откуда он берется понять не могу куда копать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andryas Опубликовано 15 марта, 2016 · Жалоба по скрину видно что трафик приходящий на wan больше на один мегобит чем трафик идущий к абонентам откуда он берется понять не могу куда копать? NAT, шейпер мспользуются? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zrhyt Опубликовано 15 марта, 2016 · Жалоба настраивал по этой статьи http://www.lanmart.ru/blogs/how-to-become-isp каждому назначил в профиле при создании клиента скорость 1536K/256K Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 15 марта, 2016 · Жалоба У микротика есть торч, запустите его на WAN порту, возможно это либо абоненты запрашивают с интернета больше трафика, чем пускает ваш шейпер и поэтому пришедшие данные просто теряются, либо просто идет мусорный трафик. Увеличьте буфер пакетов в ограничении скорости - в шейпере щелкните 2 раза по динамическим правилам pppoe там увидите имя записи правила, обычно это default-small, на вкладке Types найдите эту запись и увеличьте количество пакетов с 10 до 1000. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yKpon Опубликовано 16 марта, 2016 (изменено) · Жалоба снял дампы снифером на одной базе в момент лавины, смотрю wireshark-ом и вот что видим абонент с адресом 10.168.5.45 находится вообще территориально очень далеко от тестируемой базы, и почему его pppoe-session попал на эту базу не понятно заблокировал этого абонента, мониторю дальше, через некоторое веря мониторим дальше и снова тоже самое только уже другой абонент и так далее все базы находятся в одном влане и авторизуют юзеров на одном концентраторе получается как бы pppoe-session начинает блуждать по L2 сети и броадкастить и получаем вот это https://i.gyazo.com/2d079d2466f1d8d4b0195fc309d0eb3b.gif потом отпускает на пару минут и опять вердикт такой: абонентские pppoe-session временами начинают флудиться по всей сети на короткое время, вопрос почему? уточню что везде мыльницы, умные свитчи только на узле Изменено 16 марта, 2016 пользователем yKpon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 16 марта, 2016 · Жалоба уточню что везде мыльницы, умные свитчи только на узле Вот и ответ, нужно делать отдельный влан или EoIP туннель до каждой БС. Как раз в сетях на мыльницах это самое то, но с ними лучше EoIP туннели все же использовать. Поэтому искать проблему, пытаться с ней бороться - плохое дело, нужно сеть грамотно сегментировать и все проблемы сами собой пропадут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nurjr Опубликовано 17 марта, 2016 · Жалоба снял дампы снифером на одной базе в момент лавины, смотрю wireshark-ом и вот что видим Уменьшено на 77% (1492 x 530) - Нажмите для увеличения абонент с адресом 10.168.5.45 находится вообще территориально очень далеко от тестируемой базы, и почему его pppoe-session попал на эту базу не понятно заблокировал этого абонента, мониторю дальше, через некоторое веря мониторим дальше и снова тоже самое только уже другой абонент и так далее все базы находятся в одном влане и авторизуют юзеров на одном концентраторе получается как бы pppoe-session начинает блуждать по L2 сети и броадкастить и получаем вот это https://i.gyazo.com/...fc309d0eb3b.gif потом отпускает на пару минут и опять вердикт такой: абонентские pppoe-session временами начинают флудиться по всей сети на короткое время, вопрос почему? уточню что везде мыльницы, умные свитчи только на узле Такой флуд происходит когда авторизуеться новый пользователь на концентраторе. В чем причина я так и не понял. Вариантов два, либо это особенность протокола либо косяк в арпах. У нас концентратор был на микротике и было тоже самое. Решали сигментированием, то есть один концентратор на базу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yKpon Опубликовано 17 марта, 2016 (изменено) · Жалоба У нас концентратор был на микротике и было тоже самое. Решали сигментированием, то есть один концентратор на базу. подал на базу отдельный vlan с узла, на нём свой демон pppoe-server траффик с wds33 сыпется по все wds-ы, заснифил wireshark-ом Изменено 17 марта, 2016 пользователем yKpon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nurjr Опубликовано 17 марта, 2016 · Жалоба Покажите скрин правил фильтрации на бридже Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yKpon Опубликовано 17 марта, 2016 (изменено) · Жалоба добавил фильтр, где в bridge2 все wds /interface bridge filter add action=drop chain=forward in-bridge=bridge2 in-interface=!ether1 out-bridge=bridge2 out-interface=!ether1 и всё успокоилось причина такого поведения PPPoE мне до сих пор не понятна =) Изменено 17 марта, 2016 пользователем yKpon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 17 марта, 2016 · Жалоба добавил фильтр, где в 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? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tambu Опубликовано 23 июня, 2016 · Жалоба тема про PPPoE, но я тоже вставлю свои 5копеек. Наблюдаю точно такую же картину в виде "флуда на секторах". Схема у меня "влан на пользователя", клиентские антенны настроены в режиме моста, абонентский влан соответственно растегируется на абонентском микротике. В процессе изучения данной проблемы я выяснил, что аномальный трафик (аномальный ли он?) лезет из порта пользователя. Понятно, что блокировка порта локализует и устраняет проблему в сети, но нам же надо, чтобы пользователь был счастлив и у него всё работало. Сниффер показал, что клиент обращается к абсолютно разным узлам как по http так и по https при этом мы видим TX RATE, который идеально совпадает с TX RATE во время флуда на каждую из клиентских микротиков на базовой станции. Я еще раз уточняю, что у меня каждый абонент сидит в своем влане, но это никак не решает трабл с генерацией трафика на секторах. Решилась у меня проблема методом перевода абонентской точки в режим роутера, хотя меня это не совсем устраивает, но в конкретном случае проблема решилась. Вопрос - как решать эту глюкавость грёбаного микротика? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andryas Опубликовано 23 июня, 2016 · Жалоба Мнргоинтерфейсный бридж Микротика иногда криво работает с тегированным трафиком, а именно, превращается в хаб, посылая траффик на все интерфейсы. Если у моста всего 2 интрфейса - тогда всё отлично :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tambu Опубликовано 23 июня, 2016 (изменено) · Жалоба Мнргоинтерфейсный бридж Микротика иногда криво работает с тегированным трафиком, а именно, превращается в хаб, посылая траффик на все интерфейсы. Если у моста всего 2 интрфейса - тогда всё отлично :) как по мне, то не только с тегированным. Аналогичный флуд я видел в других местах, где абоненты болтаются в 1м влане. я бы попробовал написать в саппорт микротика, но боюсь меня нафиг пошлют, они это умеют делать лучше всего. Изменено 23 июня, 2016 пользователем tambu Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 23 июня, 2016 · Жалоба как по мне, то не только с тегированным. Аналогичный флуд я видел в других местах, где абоненты болтаются в 1м влане. я бы попробовал написать в саппорт микротика, но боюсь меня нафиг пошлют, они это умеют делать лучше всего. И правильно сделают. Потому что если вы на базе настроили бридж, к которому подключаются клиенты, и у каждого свой уникальный влан, но среда передачи общая, то один абонент может передавать пакеты всем другим абонентам, не важно в каком они влане, т.к. эти пакеты полетят по радио ко всем, а CPE абонентов просто не будут их забирать, потому что номер влана чужой. Поэтому нужно на БС блокировать любую передачу данных от абонентов в беспроводную сеть, делается это фильтрами бриджа, которые разрешают передачу данных только в сторону проводного (или логического) интерфейса, который идет в центр сети. Правило имеет вид - если входящий интерфейс бридж и выходящий интерфейс бридж, если исходящий сетевой интерфейс не ether1, и входящий сетевой интерфейс не ether1, то делать дроп. Если хотите делать схему действительно правильную влан на абонента, то нужно на базе вручную бриджевать WDS интерфейсы с нужным вланом, тогда передача в радио будет идти только конкретному абоненту с конкретным вланом, а не все в общую кучу. Но такой способ не удобный, потому что встает вопрос с управлением антеннами, если пускать туда еще и влан управления, общий на всех, то он опять будет иметь общий сегмент, что лишает такую затею смысла. Как вариант это PPPoE для управления, но в этом случае нужно в центре создать кучу серверов на каждый влан. Отсюда следует что самая верная схема сети это транспорт по L3, тогда до абонента можно сделать EoIP туннель из центра, который поднять поверх PPPoE, что исключит объединение физических транспортных интерфейсов и не будет требовать какой-то отдельной адресации для антенн. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nkusnetsov Опубликовано 24 июня, 2016 (изменено) · Жалоба Отсюда следует что самая верная схема сети это транспорт по L3, тогда до абонента можно сделать EoIP туннель из центра, который поднять поверх PPPoE, что исключит объединение физических транспортных интерфейсов и не будет требовать какой-то отдельной адресации для антенн. Может тогда имеет смысл, поднять MPLS/VPLS при наличии нормального оборудования? Благо он на микротике легко поднимается. Изменено 24 июня, 2016 пользователем nkusnetsov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tambu Опубликовано 24 июня, 2016 (изменено) · Жалоба 1. Флуд лезет только от определенных абонов. (это и есть проблема) 2. Микротик говно, это мы тоже знаем 3. Я решил вопрос жестким сегментированием, на управляемом свиче, где соединены даунлинки в сторону базовых, распределил юзерские диапазоны вланов строго на определенные порты. Хочу заметить, что стоит huawei s2300 и на нём я включал опцию port isolate (работает, ни маков с соседних баз я не увидел, l3 трафика тоже нет), но вот эти пакеты, которые ломают нам wifi всё-равно пролазят. Я в этом почти уверен. Изменено 24 июня, 2016 пользователем tambu Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 25 июня, 2016 · Жалоба Может тогда имеет смысл, поднять 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 к абоненту, с серыми адресами проблем нет, если белых адресов не достаточно много - тогда такая схема не всем подходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
777BLOODER777 Опубликовано 24 февраля, 2017 (изменено) · Жалоба Может кому то и пригодится .... /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 к серверу тишина и спокойствие .... Изменено 25 февраля, 2017 пользователем 777BLOODER777 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...