Перейти до

Рекомендованные сообщения

Опубликовано:

Доброго времени суток.

 

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

Mikrotik CCR1036-8G-2S+ версия ROS 6.48.6 (long-term)

 

Схема следующая: Mikrotik  одной 10G смотрит в вышестоящего провайдера, в ether1 включен OLT BDCOM3616, в ether2 включен OLT BDCOM3616, в ether4 включен OLT BDCOM3608 физически петель быть не может.

Изначально все абоненты были в одном VLAN, VLAN-ы с портов Mikrotik собраны в бридж , на бридже DHCP. До мая/июня все работало без проблем и нареканий.

 

После безрезультатных игр с софтом, раскидал абонентов в разные VLAN-ы, на каждый пон порт по влану. Теперь на ether1 вланы 101-116, ether2 вланы 201-216 и т.д. Все вланы собраны в бридж и на него повешен DHCP.

На OLT абоненты изолированы, включены dhcp snooping, arp inspection, verify source.

На Mikrotik пакеты между абонентами дропаются, в Profile то networking то queuring зашкативают. В Torch ничего критичного не нашел, или не то искал...

 

Но чудеса продолжаются, появляются из ниоткуда и сами исчезают в никуда.

 

Включил отрисовку графиков, сегодня обнаружил следующее (на остальных портах графики были выключены, инфы пока нет)
962859044_.thumb.jpg.86cfb667fee550b291c28431620f7ecb.jpg

 

Подскажите пожалуйста в какую сторону копать дальше?

Опубліковано: (відредаговано)

ну судя по графикам там же очевидно полка)) соберите бондинг, + horizon на бриджах попробуйте, посмотрите на фаервол - если есть правила редиректа то офните их и понаблюдайте, + блочнуть 53й порт на сам хост микротика, а ну да попробуйте ещё увеличить очередь шейпера и арп-таймаут.

1036 вроде как спокойно может прожевать 2,5г НАТа.

Відредаговано datakrava
Опубліковано:
48 минут назад, Wassabi сказав:

На Mikrotik пакеты между абонентами дропаются, в Profile то networking то queuring зашкативают. В Torch ничего критичного не нашел, или не то искал...

По графикам вроде как внешний канал не нагружается при скачке трафика между локальными интерфейсами. По сему первое утверждение под вопросом. Networking и queuring как раз о том и говорят, что многовато трафика.

Опубліковано:
34 минуты назад, Matou сказал:

По сему первое утверждение под вопросом.

Спасибо, буду рыть в этом направлении.

Опубліковано:

На ether1 и ether2 явно трафик упирается в полку - четкая ровная линия утром с 6 до 8, там возможностей гигабитного порта явно не хватает. При этом CPU имеет запас.

 

Что же касается "CPU 100%", загрузка по факту под 75% с 8 утра до 9 утра, днем ранее.

 

Все это больше похоже на целенаправленную сетевую атаку на ваши ресурсы. В первом случае на 2 портах синхронно возрастает скачивание клиентами, причем лавинообразно и сразу в полку - с чего бы это? Может быть и ботнет у вас в сети.

 

Во втором случае может быть самый разнообразный сетевой мусор, который забивает ресурсы - firewall, mangle, dns, dhcp и так далее.

 

Обратите внимание, в этот же период на аплинке у вас трафик почти без изменений, скорее даже проседает клиентский.

Опубліковано:

С вашего описания я так понял, что все вланы так же в одном бридже ?

Неплохо било бы торчем посмотреть что творится на портах во время роста трафика. Ну и все сервисы самого микротика обезопасить.

Опубліковано:
2 часа назад, Wassabi сказал:

Подскажите пожалуйста в какую сторону копать дальше?

Встановити та налаштувати систему моніторингу. 

  • Like 1
Опубліковано:
22 минуты назад, Matou сказал:

что все вланы так же в одном бридже

так и шо, еси он horizon прописал то пофиг же должно быть

Опубліковано:
1 час назад, DVSGROUP сказал:

Что же касается "CPU 100%", загрузка по факту под 75% с 8 утра до 9 утра, днем ранее.

Вчера в Winbox загрузку проца показывало 100%, сегодняшнее проспал.

 

42 минуты назад, Matou сказал:

С вашего описания я так понял, что все вланы так же в одном бридже ?

Да, на микротике два бриджа, один собраны абонентские вланы во второй вланы управления.

 

44 минуты назад, Matou сказал:

Неплохо било бы торчем посмотреть что творится на портах во время роста трафика.

Буду ждать следующего события и гляну

 

45 минут назад, Matou сказал:

Ну и все сервисы самого микротика обезопасить.

Это сделано давно.

 

2 часа назад, datakrava сказал:

соберите бондинг, + horizon на бриджах попробуйте,

Спасибо, сейчас изучаю инфу касательно horizon, в bonding нет смысла в нормальных условиях

 

1 час назад, DVSGROUP сказал:

Все это больше похоже на целенаправленную сетевую атаку на ваши ресурсы. В первом случае на 2 портах синхронно возрастает скачивание клиентами, причем лавинообразно и сразу в полку - с чего бы это? Может быть и ботнет у вас в сети.

 

Во втором случае может быть самый разнообразный сетевой мусор, который забивает ресурсы - firewall, mangle, dns, dhcp и так далее.

Обратил внимание, что в первом случае на бридже нет входящего трафика, а во втором более 300 Mb/s

 

2 часа назад, Matou сказал:

По графикам вроде как внешний канал не нагружается при скачке трафика между локальными интерфейсами. По сему первое утверждение под вопросом. Networking и queuring как раз о том и говорят, что многовато трафика.

На данный момент торчем из/в абонентскую подсеть только внутренние обращения на DNS микротика, и обмен трафиком между камерами и регистратором. Про камеры забыл, их в феврале после первых прилетов повесили. Сейчас выведу их в отдельный vlan, но сомневаюсь, что поможет.

Всем спасибо за дельные мысли, будут еще пишите. Будет какой-то результат, отпишусь.

Опубліковано:
48 минут назад, Wassabi сказав:

обмен трафиком между камерами и регистратором. Про камеры забыл, их в феврале после первых прилетов повесили

Имхо, быть может здесь собака и зарыта, ибо по графикам трафик локальный. Конечно, надо бы и другие интерфейсы глянуть графики

  • Thanks 1
Опубліковано:
1 час назад, Wassabi сказал:

обращения на DNS микротика

Держать DNS на том же микротике плохая затея....

 

Попробуйте клиентам по DHCP выдать 1.1.1.1 и 8.8.8.8, отключив затем локальный DNS.

 

Если проблема решится - поднимайте отдельно BIND под DNS на тазике.

Опубліковано:
6 часов назад, Wassabi сказал:

, в bonding нет смысла в нормальных условиях

у тебя на порту полка) воткни ещё одни в ОЛТху чи шо у тебя там собери из этого бондинг онже лацп и вешай туда вланы) 

Опубліковано:
13 минут назад, datakrava сказал:

у тебя на порту полка) воткни ещё одни в ОЛТху чи шо у тебя там собери из этого бондинг онже лацп и вешай туда вланы)

 

Только вот не задача... трафик за пределы WAN не бегает, если внимательно графики посмотреть

Опубліковано:
17 минут назад, datakrava сказал:

у тебя на порту полка) воткни ещё одни в ОЛТху чи шо у тебя там собери из этого бондинг онже лацп и вешай туда вланы) 

 

Могу и 10G порт воткнуть эти два ОЛТа, но это ничего не даст. При нормальных условиях один ОЛТ около 800 Mb/s кушает.
Проблема таки в локальном трафике, сейчас выкинул камеры и регистратор в отдельный влан, избавился от локального DNS, и установил одинаковый horizon на абонентских вланах в бридже. Жду...

Опубліковано:
1 час назад, Wassabi сказал:

одинаковый horizon

тогда нету смысла в horizon

 

1 час назад, Wassabi сказал:

но это ничего не даст

у тебя утилизация на интерфейсе 100% это типо щас щитается норм?)

 

1 час назад, Wassabi сказал:

около 800 Mb/s кушает

tx?

rx?

tx+rx?

ну ДНС на микротике уже ошибка)

Опубліковано: (відредаговано)

Доброго времени суток.

 

Ситуация повторилась.
В торче обнаружил следующее

image.png.113697d1c72dc5550147ce201997b7df.png

 

ip x.x.93.248 белый абонентский, 10.90.0.90 в сети вообще нет. Трафик летит во все абонентские вланы, но как? И как с подобным бороться?
Если верить графикам не через бридж, в котором все абонентские интерфейс вланы.

image.png.bf5b1d4e1800e1d9ffce676a3b728376.png

image.png.5699e4774fecc3aba9592a387a342094.png

 

 

Відредаговано Wassabi
Опубліковано:

а почему у вас микрот маршрутизирует 10.90.0.90 во все вланы?

правила смотрите.... такое чувство что у вас дыра где-то... а клиент руками маршрут себе пишет через заданный gateway

 

Можно на микроте конечно запретить маршрутизировать этот адрес, но это костыль

 

ip route rules

src 0.0.0.0/0

dst 10.90.0.90/32

unreachable

 

Смотрите правила, ищите первопричину как трафик туда уходит

Опубліковано:

Оч плохая идея кидать вланы в бриджи. Разделите, на каждый влан свой интерфейс Л3, дхцп. Если нужно разобраться - пишите в лс.

  • Like 1
Опубліковано:
3 минуты назад, Kiano сказав:

Оч плохая идея кидать вланы в бриджи. Разделите, на каждый влан свой интерфейс Л3, дхцп. Если нужно разобраться - пишите в лс.

А чем плоха схема влан-бридж?

Опубліковано:

Ущербна она сама по себе. Экономия IP того не стоит. А даже если DHCP на отдельном серваке, что мешает навесить на него все вланы?

Опубліковано: (відредаговано)
Цитата

а почему у вас микрот маршрутизирует 10.90.0.90 во все вланы?

Кто сказал, что маршрутизирует? Анкнов юникаст летит себе по всем интерфейсам бриджа и все..

Відредаговано khatgit
Опубліковано:
7 часов назад, wantmore сказал:

Спробуйте заборонити icmp між клієнтськими vlan. Також перевірте налаштування igmp snooping.

Дропаю icmp между абонентскими подсетями, как это сделать между вланами не понял... Multicast в сети не вещается.

 

Ситуация повторилась, но с другого ip. Я так понимаю это DoS атака по icmp, но почему и как трафик лезет внутрь сети если Dst. адрес внешний?

image.png.a2295a5592782c97dacaafa7517b1577.png

Кроме этого физически ip x.x.93.252 находится на интерфейсе ether6

 

Сейчас заблокировал пинги в сторону белых ip абонентов, но как по мне, это не совсем корректно.

 

Какие будут еще рекомендации или совенты?

Опубліковано:
37 минут назад, Wassabi сказал:

Дропаю icmp между абонентскими подсетями, как это сделать между вланами не понял... Multicast в сети не вещается.

 

Ситуация повторилась, но с другого ip. Я так понимаю это DoS атака по icmp, но почему и как трафик лезет внутрь сети если Dst. адрес внешний?

image.png.a2295a5592782c97dacaafa7517b1577.png

Кроме этого физически ip x.x.93.252 находится на интерфейсе ether6

 

Сейчас заблокировал пинги в сторону белых ip абонентов, но как по мне, это не совсем корректно.

 

Какие будут еще рекомендации или совенты?

Убрать вланы из бриджа. Обычными icmp пакетами задудосить можно было 20 лет назад. Не сейчас.

  • Like 2

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
×
×
  • Створити нове...