Jump to content
Калькуляторы

FreeBSD softrouter (netstat errs input) + непонятный трафик

Всем доброго дня.

Коллеги прошу помощи в советах. Не могу понять кто валит наш шлюз, либо физик какой-то, либо странность в сети.

Имеются два шлюза IBM для ната, перед ними есть bras в роли циски ASR1002.

Оба шлюза под управлением FreeBSD 7.3 с yandex драйверами 1.36.2.17 (сетевые Intel® PRO/1000, хорошие сетевые, с трафиком не подводили). Работают они отлично и уже очень длительное время.

После bras default-маршрут идет на первый шлюз, а на второй мы скинули 16 сетей (Для балансировки входящего в нашу сеть трафика, знаю что криво, но работает). Оба шлюза физически подключены в разные места (в разные коммутаторы), поэтому проблема точно не в физике (т.к. при переносе всего трафика на один из шлюзов, проблема повторяется).

Теперь о самой проблеме.

Вчера первый шлюз стал загибаться, процессы rx_kthread стали взлетать до 100%, тем самым съедать весь процессор.

При выводе команды netstat -hw 1 (данные пока не сохранил) увидел, что копятся errs на input, при этом количество пакетов начинает падать (например с 60K до 3-4K, а ошибки возрастают до 6-7K). Суть в том, что длится это не долго, было вчера 3 раза и каждый такой сбой был от 3 до 10 минут.

Bras (ASR1002) не загибается. Колбасит при этом первый шлюз очень даже не дурно. А вот со вторым шлюзом все нормально. Я думал, что это сам шлюз глючит, но когда я весь трафик перекинул на второй, второй стал тоже загибаться с такими же симптомами.

 

tcpdump не выявил ничего плохого.

 

Посмотрел дебаг сетевух:

 

sysctl dev.em.2.stats=1

Dec 10 08:48:41 gwibm kernel: em2: Excessive collisions = 0

Dec 10 08:48:41 gwibm kernel: em2: Sequence errors = 0

Dec 10 08:48:41 gwibm kernel: em2: Defer count = 0

Dec 10 08:48:41 gwibm kernel: em2: Missed Packets = 7216624

Dec 10 08:48:41 gwibm kernel: em2: Receive No Buffers = 1084060

Dec 10 08:48:41 gwibm kernel: em2: Receive Length Errors = 0

Dec 10 08:48:41 gwibm kernel: em2: Receive errors = 0

Dec 10 08:48:41 gwibm kernel: em2: Crc errors = 0

Dec 10 08:48:41 gwibm kernel: em2: Alignment errors = 0

Dec 10 08:48:41 gwibm kernel: em2: Collision/Carrier extension errors = 0

Dec 10 08:48:41 gwibm kernel: em2: RX overruns = 101

Dec 10 08:48:41 gwibm kernel: em2: watchdog timeouts = 0

Dec 10 08:48:41 gwibm kernel: em2: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0

Dec 10 08:48:41 gwibm kernel: em2: XON Rcvd = 0

Dec 10 08:48:41 gwibm kernel: em2: XON Xmtd = 61562

Dec 10 08:48:41 gwibm kernel: em2: XOFF Rcvd = 0

Dec 10 08:48:41 gwibm kernel: em2: XOFF Xmtd = 7275240

Dec 10 08:48:41 gwibm kernel: em2: Good Packets Rcvd = 1779196668

Dec 10 08:48:41 gwibm kernel: em2: Good Packets Xmtd = 1735225671

Dec 10 08:48:41 gwibm kernel: em2: TSO Contexts Xmtd = 0

Dec 10 08:48:41 gwibm kernel: em2: TSO Contexts Failed = 0

sysctl dev.em.2.debug=1

Dec 10 08:49:21 gwibm kernel: em2: Adapter hardware address = 0xc566a218

Dec 10 08:49:21 gwibm kernel: em2: CTRL = 0x581c0241 RCTL = 0x8002

Dec 10 08:49:21 gwibm kernel: em2: Packet buffer = Tx=16k Rx=32k

Dec 10 08:49:21 gwibm kernel: em2: Flow control watermarks high = 30720 low = 29220

Dec 10 08:49:21 gwibm kernel: em2: tx_int_delay = 100, tx_abs_int_delay = 195

Dec 10 08:49:21 gwibm kernel: em2: rx_int_delay = 0, rx_abs_int_delay = 200

Dec 10 08:49:21 gwibm kernel: em2: fifo workaround = 0, fifo_reset_count = 0

Dec 10 08:49:21 gwibm kernel: em2: hw tdh = 1090, hw tdt = 1090

Dec 10 08:49:21 gwibm kernel: em2: hw rdh = 3104, hw rdt = 3103, next_rx_desc_to_check = 3104

Dec 10 08:49:21 gwibm kernel: em2: Num Tx descriptors avail = 4068

Dec 10 08:49:21 gwibm kernel: em2: Tx Descriptors not avail1 = 0

Dec 10 08:49:21 gwibm kernel: em2: Tx Descriptors not avail2 = 0

Dec 10 08:49:21 gwibm kernel: em2: Std mbuf failed = 0

Dec 10 08:49:21 gwibm kernel: em2: Std mbuf cluster failed = 0

Dec 10 08:49:21 gwibm kernel: em2: Driver dropped packets = 0

Dec 10 08:49:21 gwibm kernel: em2: Driver tx dma failure in encap = 0

Dec 10 08:49:21 gwibm kernel: em2: Packets pended due to reorder = 0

Dec 10 08:49:21 gwibm kernel: em2: RX interrupts has been masked = 99250334

Dec 10 08:49:21 gwibm kernel: em2: TX interrupts has been generated = 0

Единственное что я крутил у сетевух так это

 

dev.em.2.rx_int_delay=100

dev.em.2.tx_int_delay=100

dev.em.2.rx_abs_int_delay=200

dev.em.2.tx_abs_int_delay=200

dev.em.2.rx_kthreads=4

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

 

P.S. Раньше когда трафика было много и шлюз был один, то при перегрузке ошибки появлялись на интерфейсе, но количество пакетов так сильно не падало (ну может на 2-3K, но не на 40K же). Когда появляется вышеописанная проблема, взлет трафика нет, по количеству пакетов сказать пока сложно, но вроде тоже не возрастает.

Share this post


Link to post
Share on other sites
tcpdump не выявил ничего плохого.
для отлова аномального трафика я писал софтину на Си и запускал её на отдельной машине, на которую льётся инет-трафик с помошью port mirroring кошки

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

 

Посмотрел дебаг сетевух:
и не увидел... что
Dec 10 08:49:21 gwibm kernel: em2: tx_int_delay = 100, tx_abs_int_delay = 195

Dec 10 08:49:21 gwibm kernel: em2: rx_int_delay = 0, rx_abs_int_delay = 200

dev.em.2.rx_int_delay=100

dev.em.2.tx_int_delay=100

dev.em.2.rx_abs_int_delay=200

dev.em.2.tx_abs_int_delay=200

dev.em.2.rx_kthreads=4

да и вообще, мне кажется маловато 100

 

Коллеги помогите, пожалуйста. Подскажите, что за трафик такой может спровоцировать ошибки на сетевой при входе? Спасибо.
на шлюзе кроме протоколов маршрутизации (BGP, OSPF etc) ещё что есть? в т.ч. фаерволл

запустите три терминала:

один top -SP -s1

второй netstat -w1 -Iфизический_1

третий netstat -w1 -Iфизический_2

и смотрите чего будет происходить с топ-ом при появлении ошибок.

 

 

ну и пара вопросов не особо относящихся к теме:

- хватило зелени на ASR а на автономную систему нет? как-то неукладывается, зачем вам nat, с ним же проблемы одни

- вы не из Тюмени случайно? (5-6-МЖК 2004-2005г. и провайдинг)

Edited by Giga-Byte

Share this post


Link to post
Share on other sites
tcpdump не выявил ничего плохого.
для отлова аномального трафика я писал софтину на Си и запускал её на отдельной машине, на которую льётся инет-трафик с помошью port mirroring кошки

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

Если использовать статистический подход и строить распределение пакетрейта по IP, то DoS-атаки из внутренней сети вполне можно отлавливать. У атакующих IP пакетрейт всегда аномально большой.

Share this post


Link to post
Share on other sites

На шлюзе кроме ната ничего нет, BGP на другом бордере. Шлюзы нужны для экономии выделенных адресов (используется pf).

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

 

tcpdump уже поставлен на мониторинг, будем анализировать его уже позже.

 

По rx_int_delay, я видел, но параметр установлен. Счел это на баг самой сетевой. Но врятли это мешает, т.к. уже год все было отлично с этими параметрами.

 

Насчет top я же писал, что взлетает в момент проблемы процесс rx_kthread до 100%. Какие-то пакеты переполняют буфер сетевой, а вот какие пока ещё неизвестно. Скорее всего дело в их количестве и в меньшем размере. Сейчас будем мониторить их.

Edited by nerik

Share this post


Link to post
Share on other sites
Шлюзы нужны для экономии выделенных адресов (используется pf).
почему pf? он не годится для мультипроцессорности и большого трафика.

есть libalias и ng_nat... попробуйте...

 

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

 

tcpdump уже поставлен на мониторинг, будем анализировать его уже позже.
сомневаюсь, что найдете что-нибудь аномального.

 

По rx_int_delay, я видел, но параметр установлен. Счел это на баг самой сетевой. Но врятли это мешает, т.к. уже год все было отлично с этими параметрами.
как применяли параметры?

если через sysctl.conf и /etc/rc.d/sysctl restart - то это бага этого скрипта.

надо в два этапа, например

dev.em.2.rx_int_delay=100

dev.em.2.rx_int_delay=500

 

Насчет top я же писал, что взлетает в момент проблемы процесс rx_kthread до 100%. Какие-то пакеты переполняют буфер сетевой, а вот какие пока ещё неизвестно. Скорее всего дело в их количестве и в меньшем размере. Сейчас будем мониторить их.
у вас dev.em.2.rx_kthreads=4, должно быть 4 процесса (зачем опять-же)

взлетает до 100% всего один rx_kthread?

если да - советую обратить внимание на первый абзац этого сообщения.

 

физическая сетевая одна и таже?

Share this post


Link to post
Share on other sites
почему pf? он не годится для мультипроцессорности и большого трафика.

есть libalias и ng_nat... попробуйте...

А смысл менять если с ним проблем не было, тем более асинхронный нат очень даже устраивает нас. При pf первый шлюз у нас прогоняет 700 Мегабит. Просто при использовании второго шлюза, мы сейчас через первый гоняем не более 300Мегабит.

Проблема то заключается при входе трафика, так как взлетают input errs на сетевой, значит до pf не доходит.

 

такого быть не должно.

Если количество пакетов (с малым размером) будет больше, чем шлюз может прожевать, то он будет загибаться.

 

как применяли параметры?

если через sysctl.conf и /etc/rc.d/sysctl restart - то это бага этого скрипта.

надо в два этапа, например

dev.em.2.rx_int_delay=100

dev.em.2.rx_int_delay=500

через команду sysctl сначало добавляли. Да и перезагружали шлюз недавно (в sysctl.conf прописано).

 

у вас dev.em.2.rx_kthreads=4, должно быть 4 процесса (зачем опять-же)

взлетает до 100% всего один rx_kthread?

если да - советую обратить внимание на первый абзац этого сообщения.

нет, взлетают все rx_kthread, от 90 до 100%. Стоит 4 так как у нас 8 ядер на шлюзе. По 4 отдаем на каждую сетевую.

 

физическая сетевая одна и таже?

нет, сетевые две, внешние, двухпортовые, но используется только по одному порту, на вход и выход.

 

 

Сейчас мы ожидаем когда проблема появится снова, чтобы точно сказать, что из-за количество пакетов становиться шлюзу плохо (поставили на мониторинг все магистрали на pps). Тогда будет все ясно.

Share this post


Link to post
Share on other sites
как применяли параметры?

если через sysctl.conf и /etc/rc.d/sysctl restart - то это бага этого скрипта.

надо в два этапа, например

dev.em.2.rx_int_delay=100

dev.em.2.rx_int_delay=500

через команду sysctl сначало добавляли. Да и перезагружали шлюз недавно (в sysctl.conf прописано).

 

в дровах есть проблема, насколько я вижу ее никто не правил. Единожды установленные парамеры (вот эти самые delay) сбрасываются по разным поводам, типа появления линка. т.е. на стандартной загрузке значения из sysctl.conf не работают никогда. при этом в sysctl они показываются, а в драйвере их нет. Там дефолтные. Соответственно после загрузки следует применить их еще раз (внимание, /etc/rc.d/sysctl не переустанавливает значения на уже стоящий там значения. т.е или в sysctl.conf их, как показано выше писать по 2 раза или звать что то типа

egrep '^dev\.em\.' /etc/sysctl.conf | while read line; do sysctl $line; done

и это запускать уже после загрузки)

Share this post


Link to post
Share on other sites
Оба шлюза под управлением FreeBSD 7.3 с yandex драйверами 1.36.2.17 (сетевые Intel® PRO/1000, хорошие сетевые, с трафиком не подводили)

[off]

Просто интересно, а яндексные драйвера ещё актуальны по сравнению со стандартными?

[/off]

Share this post


Link to post
Share on other sites
Просто интересно, а яндексные драйвера ещё актуальны по сравнению со стандартными?

С ними шлюзы очень хорошо трафик жуют. Тем более стандартные не разбрасывают по ядрам нагрузку.

Share this post


Link to post
Share on other sites
Просто интересно, а яндексные драйвера ещё актуальны по сравнению со стандартными?

С ними шлюзы очень хорошо трафик жуют. Тем более стандартные не разбрасывают по ядрам нагрузку.

Шлюзы жуют трафик, нагрузка разбрасывается по ядрам, это хорошо. Но, при переходе на netisr сильнее грузится проц но пробегает больше трафика, пик подростает где-то так мегабит с 700 до 800. Конечно мои эксперименты могут дивным образом совпадать с фазой луны и направлением ветра, но разница между 700 и 800 мбит на разных драйверах заметна была. Списали на глюки с packet reordering из-за рандомной раскидки пакетов по ядрам под нагрузкой и забили, перешли на стандартные. Хотя это может быть у меня только так, вообще на подземный стук похоже.
Edited by make.kernel

Share this post


Link to post
Share on other sites
Шлюзы жуют трафик, нагрузка разбрасывается по ядрам, это хорошо. Но, при переходе на netisr сильнее грузится проц но пробегает больше трафика, пик подростает где-то так мегабит с 700 до 800. Конечно мои эксперименты могут дивным образом совпадать с фазой луны и направлением ветра, но разница между 700 и 800 мбит на разных драйверах заметна была. Списали на глюки с packet reordering из-за рандомной раскидки пакетов по ядрам под нагрузкой и забили, перешли на стандартные. Хотя это может быть у меня только так, вообще на подземный стук похоже.

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

Как только будет больше трафика и не будет резервов (новых шлюзов), вот тогда потестим стандартные драйвера. За информацию спасибо.

 

А по факту сегодня 3 день как аномалий не было.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this