medmm

EoIP в бриджах в принципе не всегда нормально работает, а уж тем более для multicast. Лучше поднимите VPLS over pptp, как советует @weedman.

@McSea У туннеля MTU 1500, L2MTU 65535, все как обычно.

@Saab95 Не первый раз убеждаюсь, что 95% проблем с микротиком решаются сбросом конфига. Начал с ваших настроек, потом ввернул fasttrack и все завертелось. Постепенно возвращая свои настройки по одному, очень сильно удивился, когда обнаружил, что после добавления EoIP туннеля в основной бридж скорость упала и утилизация подскочила до 85%. Никогда бы не подумал, что EoIP так влияет на производительность. Без EoIP в бридже имею 800/900 при утилизации 40/45. Надо было сразу все сбросить, просто был уверен в своем конфиге и не хотел делать его заново) Спасибо! ЗЫ Переткнул свой комп в ether3, другой комп в ether5, чтоб при передаче по локалке не нагружать проц.

@Saab95 А почему этого на вход хватает? Этот, как известно, почти самый мощный из soho сегмента, а ставить домой RB3011 слишком жирно. На PPPoE Туполиньк раньше стоял, пока не сдох, отдавал по 900 мбит в обе стороны (мерял в 4 утра).

Имею подключение от провайдера по PPPoE на интерфейсе ether1. При замере скорости speedtest показывает 850 мбит на вход и 600 на выход, причем во время первой половины теста (вход) загрузка процессора в среднем 45%, во время второй половины теста (выход) в среднем 87%, причем три ядра из четырех используются на 100%. Из firewall убрал все, кроме fasttrack и src-nat. Если вместо микротика подключить машину с убунтой, то скорость 850 на вход и 890 на выход. Подскажите, пожалуйста, как побороть эту проблему с исходящим трафиком.

Так или иначе, могу с уверенностью утверждать, что мою "атаку" никто не заметил;)

@s.lobanov Вот я влип! Пошел собирать чемоданы, походу за мной уже выехали, последний понедельник живу.

Там человек конфиги нескольких тысяч абонентов сломал, а я ничего не ломал, не менял, в сети никаких следов не оставил, тем более, что во время модернизации у провайдера вообще не было доступа к статистике и мониторингу. Да и атакой это сложно назвать, wireshark и 2 команды на микроте.

Согласен, наверное так и было... Спасибо за разъяснение)

Вы правы, похоже, что на доступе изоляция действительно есть, клиентские padi отправляются только на uplink коммутатора, но во время ребута ("модернизации") вышестоящего коммутатора он превратился в тупаря и начал пропускать л2 во все стороны, а не только к аплинку и я увидел broadcast storm на интерфейсе микротика. Тогда буду ждать очередной "модернизации", хоть посчитаю количество абонов в одном сегменте)

На моем свиче точно не включена trafic segmentation, так как во время дауна pppoe сервера я видел весь л2 трафик (padi). Я хочу понять, на каком узле режется этот трафик. Может быть, что помимо pppoe провайдер ребутал один из узловых свичей, функцией которого и было блокировать этот авторизационный флуд. Этот вариант довольно логичен, но сходится не со всеми фактами. В таком случае мне опять же не понятно, как узловой свич может блокировать л2 флуд, который через него не проходит (мой коммутатор и соседний включены цепочкой через транки)

Тогда мне не понятно, почему я сейчас не вижу padi, которые рассылает мой микротик из соседнего подъезда (pppoe scan)? Завтра проверю прохождение широковещательных кадров padi в пределах одного коммутатора.

Я подключен в huawei s5320-28tp-li-ac, в соседнем подъезде QTECH, оба управляемые, но во время "модернизации" л2-изоляцию я не увидел) Тогда получается, что перезагрузили все свичи в моем сегменте, раз сотни абонов начали друг дружке рассылать padi и я их увидел? Или я не в том направлении мыслю?

Здравствуйте! Являюсь абонентом одного крупного провайдера. Несколько дней назад у них проводилась модернизация оборудования, из-за которой наш микрорайон потерял доступ к интернету. Решил посмотреть, в чем же дело. В логах микротика увидел, что pppoe сервер не отвечает на PADI-пакеты. Но! Помимо "своих" PADI пакетов я увидел сотни чужих, беспрерывно сыпавшихся на интерфейс. Решил поднять pppoe сервер (ради интереса) и сотни клиентов начали сообщать мне свои учетные данные. То есть провайдер вообще не позаботился о блокировке авторизационного флуда на доступе. Как только провайдер поднял свой vrrp-pppoe сервер, padi сыпаться перестали. Решил проверить, как в целом изменилась ситуация с pppoed в сегменте. Оказалось, что теперь "мои" padi пакеты не доходят ни до кого в сегменте, кроме pppoe сервера (соответственно, он на них отвечает). Убедился в этом, встав wireshark`ом на интерфейс в соседнем подъезде. Кроме того, до моего интерфейса не доходят padi от других клиентов (проверил опять же с соседнего подъезда). Такое ощущение, что пров настроил на коммутаторах ACL на запрет входящих padi на клиентских портах за пару часов, но ведь это невозможно. Конечно, так и должно быть, но меня мучает вопрос: как широковещательная рассылка ethernet кадров зависит от состояния pppoe сервера?