[swelf]

Замена софтроутера на железку проблемы не решит, просто сменятся жалобы с "падает линукс" на "падает железка".

У нас 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 от загрузки каналов.

[AlKov]

Возможно, глупый вопрос...

)Недавно прилетело на клиента 100kpps мелких udp на порт 68, типа dhcp, с абсолютно разных адресов, что привело в ступор линукс, проблема была именно с количество соединения, а не количестве пакетов. Больше 1 миллиона conntrack соединений в таблице.

Ну так не трекайте ненужные соединения. Оставьте этот трафик клиенту.

А как это осуществляется на практике??

[pppoetest]

-j NOTRACK ?

[g3fox]

-j NOTRACK ?

Так у него NAT же там ...

[bos9]

-j NOTRACK ?

Так у него NAT же там ...

 

а в чем противоречие?

[AlKov]

-j NOTRACK ?

Типа так -

iptables -t raw -I PREROUTING -p udp --dport 68 -j NOTRACK

?

[NiTr0]

Можно пошаманить с -m state (не уверен что для raw сработает).

[russ1st]

kernel panic могло и не быть.

Система могла потерять диск, возможно не без посторонней помощи, и продолжить работать без него.

Логи в такой ситуации ессно никуда не пишутся.

[YuryD]

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

[vlad11]

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

 

Это вы намутили с firewall и с системными переменными.

[^rage^]

Причину падения вроде как нашли, это связка ядра 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 загнал.

[^rage^]

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

[Saab95]

1)Недавно прилетело на клиента 100kpps мелких udp на порт 68, типа dhcp, с абсолютно разных адресов, что привело в ступор линукс, проблема была именно с количество соединения, а не количестве пакетов. Больше 1 миллиона conntrack соединений в таблице. Что привело машину в ступор, пока я на свиче, в который приходят аплинки не нарисовал acl блокирующий этот трафик, тут резервирование не поможет, а железный роутрер я так понял, без проблем бы с этим справился.

 

Вам просто надо вынести терминацию абонентов на отдельное оборудование, на котором уже и будете все резать, в центр пойдет только то, что должно пойти. Например если в дома на терминацию ставить Mikrotik CRS, то при флуде его загрузка процессора увеличится, и по мониторингу всегда можно будет понять где проблема, или просто отключить указанное оборудование, убрав лишнюю нагрузку с центрального.

 

А то тут видел одну сеть, в ней в центре стоит крутая железка, которая валится раз в неделю, зато все кабели со всего города стянуты в нее, штук 200 оптических кабелей введено в здание, круто=)

[YuryD]

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

 

Это вы намутили с firewall и с системными переменными.

Тимспик - это не то, на чём я зарабатываю :) И тюнить под него мне в общем-то ни к чему, хотя как ханипот для отладки firewall вполне подходит.

[NiTr0]

Например если в дома на терминацию ставить Mikrotik CRS, то...

...один качок с торрентом будет намертво ложить весь дом. А от флуда извне оно никак не защитит.

[telecom]

...просто сменятся жалобы с "падает линукс" на "падает железка".

 

+100500

 

Мы несколько лет назад кошек клали. Экстрим спас ситуацию, но думаю, это решение не поместится в Ваш бюджет.

И бордюр отдельным сервером. Если железкой, то MX240 Вам решит все проблемы)))) Но это опять не бюджет))))

Одним словом, в Вашем случае выход только один, допилить линух.

Поставьте 3.14 ядро на бордюр и 3.18 на нат с брасом.

[bos9]

что вас заставило использовать штатное ядро из debian?

а что не так со штатным ядром в дебиане?

 

Поставьте 3.14 ядро на бордюр и 3.18 на нат с брасом.

почему именно эти ядра для этих целей? Если не сложно..

Изменено 29 апреля, 2015 пользователем bos9

[telecom]

Поставьте 3.14 ядро на бордюр и 3.18 на нат с брасом.

почему именно эти ядра для этих целей? Если не сложно..

 

3.14 наиболее стабильное на текущий момент.

3.18 для ната допиленое.

[evg_b]

а собрать самовар, который должен ещё гладить и стирать, ну тут уже простите :)

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

 

Представляю как огорчится когда у него "железное" решение упадет. Как это ни странно, но там на железе тоже софт крутится. Мой опыт показывает что и 1002 циски с PPPoE и NAT изредка крэшятся :)) Правда не наглухо, перезапускают какой-то модуль в софте и через 2-5 минут снова в строю

[darkagent]

Мой опыт показывает что и 1002 циски с PPPoE и NAT изредка крэшятся :)) Правда не наглухо, перезапускают какой-то модуль в софте и через 2-5 минут снова в строю

У больших железок, с резервированием всего (2x rsp/esp) с этим все гораздо приятней и незаметно для пользователей. Но на то они и большие железки, по цене самолета. Опять же, нату не место даже на таких железках, либо выносить его на тазики, либо на специализированные железки (которые по сути те же тазики, с дополнительной начинкой), в противном случае, нат остается основной точкой отказа.

[Antares]

3.14 наиболее стабильное на текущий момент.

3.18 для ната допиленое.

Чистые 3.14 и 3.18 или с хвостиками 3.14.40 и 3.18.12? )))

[Saab95]

...один качок с торрентом будет намертво ложить весь дом. А от флуда извне оно никак не защитит.

 

У вас что не сообщение, все не в тему. От торрента микротику плохо не станет.

[NiTr0]

У вас что не сообщение, все не в тему. От торрента микротику плохо не станет.

Да-да, и пережевать сотню-другую мегабит с пакетами по 200 байт мыльница уровня тплинка 841 сможет, да :) Правда только в фантазиях их продавца - но покупатель-то об этом узнает уже сильно потом, когда все уже на костылях построено :)

[alks]

Поставьте 3.14 ядро на бордюр и 3.18 на нат с брасом.

почему именно эти ядра для этих целей? Если не сложно..

 

3.14 наиболее стабильное на текущий момент.

3.18 для ната допиленое.

 

можете поподробнее расписать или ссылку подкинуть что там такого в 3.18 сделано для NAT

если нетрудно

[^rage^]

что вас заставило использовать штатное ядро из debian?

а что не так со штатным ядром в дебиане?

оно элементарно старое. со времен 3.2 в в netdev пролетела масса важных фиксов