swelf Опубликовано 27 апреля, 2015 · Жалоба Замена софтроутера на железку проблемы не решит, просто сменятся жалобы с "падает линукс" на "падает железка". У нас 2 одинаково настроеных dell 1950 маршрутизацию, трафик начал медленно подбираться к гигабиту, решили поставить на них intel x520, на одном боевом роутере переключились на нее, на резервном остались на интегрированной сетевой. Все проработало месяц, не было никаких проблем, перешли на новую сетевую на втором роутере. Стоял debian squeeze с ядром 3.2.0. И тут неожиданно в логи начали сыпаться kernel oops сообщения, на разные процессы, oom killer начал методично убивать все подряд(хотя памяти по факту занято 10% от от того что есть), активные ssh сессии, зебру и всякие другие нужные процессы. Перенесли все функции на резервный роутер, и там сразу же началось тоже самое. Откатились на гигабитные интерфейсы, но это заняло время, вот тебе и резервирование. Причину падения вроде как нашли, это связка ядра 3.2.0 из дебиана и драйверов ixgbe для сетевой, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704988 тут правда говорится о x64, а у нас x86 версия, но проблема похожая, обновились проработали неделю, и роутер неожиданно упал. Когда все настроено, оно и правда обычно работает годами, как и было до установки новых сетевых. Вам не кажется, что ЭКСперименты начнутся при переходе с linux на железо ? Можно ж сначала потренироватться на кошках, потом перенести физ лиц, они правда дают нам процентов 10-12 от загрузки каналов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 27 апреля, 2015 · Жалоба Возможно, глупый вопрос... )Недавно прилетело на клиента 100kpps мелких udp на порт 68, типа dhcp, с абсолютно разных адресов, что привело в ступор линукс, проблема была именно с количество соединения, а не количестве пакетов. Больше 1 миллиона conntrack соединений в таблице. Ну так не трекайте ненужные соединения. Оставьте этот трафик клиенту. А как это осуществляется на практике?? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 27 апреля, 2015 · Жалоба -j NOTRACK ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 27 апреля, 2015 · Жалоба -j NOTRACK ? Так у него NAT же там ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 27 апреля, 2015 · Жалоба -j NOTRACK ? Так у него NAT же там ... а в чем противоречие? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 27 апреля, 2015 · Жалоба -j NOTRACK ? Типа так - iptables -t raw -I PREROUTING -p udp --dport 68 -j NOTRACK ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 27 апреля, 2015 · Жалоба Можно пошаманить с -m state (не уверен что для raw сработает). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
russ1st Опубликовано 27 апреля, 2015 · Жалоба kernel panic могло и не быть. Система могла потерять диск, возможно не без посторонней помощи, и продолжить работать без него. Логи в такой ситуации ессно никуда не пишутся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 27 апреля, 2015 · Жалоба Если хотите примера, у меня тимспик сервер давно стоит под атакой, бордеры этого не замечают, а на freebsd в логах вижу - слишком много динамических правил. Сервер тимспика не падает, но проблемы с коннектом клиентов к нему конечно есть, цель атаки достигнута. У меня просто есть комп, на который я заворачиваю фильтацию входа критичных вещей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 27 апреля, 2015 · Жалоба Если хотите примера, у меня тимспик сервер давно стоит под атакой, бордеры этого не замечают, а на freebsd в логах вижу - слишком много динамических правил. Это вы намутили с firewall и с системными переменными. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 28 апреля, 2015 · Жалоба Причину падения вроде как нашли, это связка ядра 3.2.0 из дебиана и драйверов ixgbe для сетевой, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704988 тут правда говорится о x64, а у нас x86 версия, но проблема похожая, обновились проработали неделю, и роутер неожиданно упал. ixgbe was changed in Linux 3.4 to allocate single-page RX buffers,rather than contiguous buffers, so I'm closing this at the first fixed version. This change might be backported in a point release along with new hardware support, but I don't have any plan to do so at the moment. что вас заставило использовать штатное ядро из debian? Типа так - iptables -t raw -I PREROUTING -p udp --dport 68 -j NOTRACK ? я бы еще список портов в ipset загнал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 28 апреля, 2015 · Жалоба 1)Недавно прилетело на клиента 100kpps мелких udp на порт 68, типа dhcp, с абсолютно разных адресов, что привело в ступор линукс, проблема была именно с количество соединения, а не количестве пакетов. лимиты на числой стейтов для каждого хоста + на скорость создания стейтов. Больше 1 миллиона conntrack соединений в таблице. Что привело машину в ступор, я делал и 4млн стейтов в conntrack, при этом в машину летело 1mpps. пока я на свиче, в который приходят аплинки не нарисовал acl блокирующий этот трафик, тут резервирование не поможет, а железный роутрер я так понял, без проблем бы с этим справился. кончится tcam и железка помахает ручкой. вы лучше скажите сколько у вас памяти на машине и покажите настройки conntrack. Удаленно ни на что не реагировал, человек, который перегрузил его по питанию, не сфотографировал экран, и не посмотрел, что там происходит, в логах ничего нету. Очевидно kernel panic по какой-то причине(ядро 3.19.5 самосбор). почему не настроен netconsole? Вобщем не спорю, что линукс за меньшие деньги может предложить, тоже, что и железные решения, но кто будет терпеть эксперименты? не надо никаких экспериментов. есть best practices и документация по sysctl/ethtool. ну вот ради интереса, покажите ethtool -g eth0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 28 апреля, 2015 · Жалоба 1)Недавно прилетело на клиента 100kpps мелких udp на порт 68, типа dhcp, с абсолютно разных адресов, что привело в ступор линукс, проблема была именно с количество соединения, а не количестве пакетов. Больше 1 миллиона conntrack соединений в таблице. Что привело машину в ступор, пока я на свиче, в который приходят аплинки не нарисовал acl блокирующий этот трафик, тут резервирование не поможет, а железный роутрер я так понял, без проблем бы с этим справился. Вам просто надо вынести терминацию абонентов на отдельное оборудование, на котором уже и будете все резать, в центр пойдет только то, что должно пойти. Например если в дома на терминацию ставить Mikrotik CRS, то при флуде его загрузка процессора увеличится, и по мониторингу всегда можно будет понять где проблема, или просто отключить указанное оборудование, убрав лишнюю нагрузку с центрального. А то тут видел одну сеть, в ней в центре стоит крутая железка, которая валится раз в неделю, зато все кабели со всего города стянуты в нее, штук 200 оптических кабелей введено в здание, круто=) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 28 апреля, 2015 · Жалоба Если хотите примера, у меня тимспик сервер давно стоит под атакой, бордеры этого не замечают, а на freebsd в логах вижу - слишком много динамических правил. Это вы намутили с firewall и с системными переменными. Тимспик - это не то, на чём я зарабатываю :) И тюнить под него мне в общем-то ни к чему, хотя как ханипот для отладки firewall вполне подходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 28 апреля, 2015 · Жалоба Например если в дома на терминацию ставить Mikrotik CRS, то... ...один качок с торрентом будет намертво ложить весь дом. А от флуда извне оно никак не защитит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 28 апреля, 2015 · Жалоба ...просто сменятся жалобы с "падает линукс" на "падает железка". +100500 Мы несколько лет назад кошек клали. Экстрим спас ситуацию, но думаю, это решение не поместится в Ваш бюджет. И бордюр отдельным сервером. Если железкой, то MX240 Вам решит все проблемы)))) Но это опять не бюджет)))) Одним словом, в Вашем случае выход только один, допилить линух. Поставьте 3.14 ядро на бордюр и 3.18 на нат с брасом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 29 апреля, 2015 (изменено) · Жалоба что вас заставило использовать штатное ядро из debian? а что не так со штатным ядром в дебиане? Поставьте 3.14 ядро на бордюр и 3.18 на нат с брасом. почему именно эти ядра для этих целей? Если не сложно.. Изменено 29 апреля, 2015 пользователем bos9 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 29 апреля, 2015 · Жалоба Поставьте 3.14 ядро на бордюр и 3.18 на нат с брасом. почему именно эти ядра для этих целей? Если не сложно.. 3.14 наиболее стабильное на текущий момент. 3.18 для ната допиленое. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evg_b Опубликовано 29 апреля, 2015 · Жалоба а собрать самовар, который должен ещё гладить и стирать, ну тут уже простите :) проблема то не в этом, самовар справляется, если я разнесу все по разным машинам, то изначальная проблема нестабильности не уйдет. Так что будем думать по поводу покупки оборудования. Представляю как огорчится когда у него "железное" решение упадет. Как это ни странно, но там на железе тоже софт крутится. Мой опыт показывает что и 1002 циски с PPPoE и NAT изредка крэшятся :)) Правда не наглухо, перезапускают какой-то модуль в софте и через 2-5 минут снова в строю Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 29 апреля, 2015 · Жалоба Мой опыт показывает что и 1002 циски с PPPoE и NAT изредка крэшятся :)) Правда не наглухо, перезапускают какой-то модуль в софте и через 2-5 минут снова в строю У больших железок, с резервированием всего (2x rsp/esp) с этим все гораздо приятней и незаметно для пользователей. Но на то они и большие железки, по цене самолета. Опять же, нату не место даже на таких железках, либо выносить его на тазики, либо на специализированные железки (которые по сути те же тазики, с дополнительной начинкой), в противном случае, нат остается основной точкой отказа. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 29 апреля, 2015 · Жалоба 3.14 наиболее стабильное на текущий момент. 3.18 для ната допиленое. Чистые 3.14 и 3.18 или с хвостиками 3.14.40 и 3.18.12? ))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 29 апреля, 2015 · Жалоба ...один качок с торрентом будет намертво ложить весь дом. А от флуда извне оно никак не защитит. У вас что не сообщение, все не в тему. От торрента микротику плохо не станет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 29 апреля, 2015 · Жалоба У вас что не сообщение, все не в тему. От торрента микротику плохо не станет. Да-да, и пережевать сотню-другую мегабит с пакетами по 200 байт мыльница уровня тплинка 841 сможет, да :) Правда только в фантазиях их продавца - но покупатель-то об этом узнает уже сильно потом, когда все уже на костылях построено :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 29 апреля, 2015 · Жалоба Поставьте 3.14 ядро на бордюр и 3.18 на нат с брасом. почему именно эти ядра для этих целей? Если не сложно.. 3.14 наиболее стабильное на текущий момент. 3.18 для ната допиленое. можете поподробнее расписать или ссылку подкинуть что там такого в 3.18 сделано для NAT если нетрудно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
^rage^ Опубликовано 29 апреля, 2015 · Жалоба что вас заставило использовать штатное ядро из debian? а что не так со штатным ядром в дебиане? оно элементарно старое. со времен 3.2 в в netdev пролетела масса важных фиксов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...