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

[nerik]

Всем доброго дня.
Коллеги прошу помощи в советах. Не могу понять кто валит наш шлюз, либо физик какой-то, либо странность в сети.
Имеются два шлюза 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 же). Когда появляется вышеописанная проблема, взлет трафика нет, по количеству пакетов сказать пока сложно, но вроде тоже не возрастает.

[root]

привет
у меня тоже бывало такое.

1. посмотри сколько у тя UDP трафика прет. uTP - знаешь такого зверя ?

2. посмотри в такие моменты что видно по

Код: Выделить всё

top -S

а именно как чувтсвуют себя процессы:

Код: Выделить всё

swi1: net
em2 taskq

если процесс swi1:net в 100% то это означает "ёк" сетевой подсистемы фрюнделя

3. попробуй такие значения:

Код: Выделить всё

dev.em.2.rx_int_delay=600
dev.em.2.tx_int_delay=600
dev.em.2.rx_abs_int_delay=1000
dev.em.2.tx_abs_int_delay=1000
dev.em.2.rx_processing_limit=1024

попробуй ещё поиграть с:

Код: Выделить всё

net.isr.direct=0
net.route.netisr_maxqlen=1024

+ ещё вот это:

Код: Выделить всё

net.inet.ip.fastforwarding=1
kern.ipc.maxsockets=204800
kern.ipc.shmall=128000000
kern.ipc.shmmax=128000000
kern.ipc.nmbclusters=262144
kern.maxfiles=204800
kern.maxfilesperproc=200000
net.inet.tcp.maxtcptw=40960
net.inet.tcp.msl=30000
net.inet.tcp.nolocaltimewait=1
net.inet.tcp.fast_finwait2_recycle=1
net.inet.udp.maxdgram=18432
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
net.inet.udp.recvspace=65535

4. на чем реализован NAT ? pf ? ipfw ? natd ? ipnat ?

5. как организовано прохождение трафика через NAT сервер ? одна сетевуха в сторону юзеров, а вторая "вверх" ? все на одной сетевухе ? по вланам ?

6. сколько макс. трафика в мбитах идет через сервер ?

7. можно попробовать вот эти дрова em-6.9.20.tar.gz

8. polling не пробовал включать ?

ну пока это все быстрые мыли что пришли в голову

З.Ы. Тема больше подходит для раздела "FreeBSD", чем для "Маршрутизация" - тему перенес.

[nerik]

Приветствую.
Про uTP знаю, его блокирую на BGP после шлюзов.
В момент проблемы, процессор по top весь съедался процессами rx_kthread , в netstat -hw 1 на input в графе errs ошибки были в 5-7K, количество пакетов падало с 59K до 6-8K.
Показания не могу привести, не сохранил, говорю то что видел. Как только повторится, то сохраню обязательно.

Нат реализован на pf. Есть ipfw, но там 2-3 правила, пару портов прикрываю.
На сервере две сетевушки (по два порта), но трафик входит в одну и выходит в другую. Тоесть с em2 в em0. Сетевые хорошие, работают уже год.

Дело в том что до вчерашнего дня все было отлично, шлюз молотит 300-500 Мегабит и проблем никаких не было. Проблема появлялась вчера 3 раза за день, до этого все было нормально, трафик в количестве и интенсивности в сети не менялся. Подозреваю что кто то генерирует плохой трафик, который переполняет буфер сетевой карты на входе.

Сейчас все нормально. 67K пакетов при 43M (344 Мегабита). Похоже на какую-то атаку, т.к. колбасит 5-10 минут. Вот и хочу понять, что может такое губить сетевую карту.

В debug
увидел такое
Dec 10 08:48:41 gwibm kernel: em2: Missed Packets = 7216624
Dec 10 08:48:41 gwibm kernel: em2: Receive No Buffers = 1084060

[root]

Про uTP знаю, его блокирую на BGP после шлюзов.

а почему после ? блочь его на входе на NAT сервер

посмотри в момент нагрузки на те процессы о которых я говорил выше

Нат реализован на pf.

покажи вывод:

Код: Выделить всё

pfctl -sa

интересуют "разделы": LIMITS, TIMEOUTS, INFO

Есть ipfw, но там 2-3 правила, пару портов прикрываю.

попробуй полностью перейти на ipfw nat и посмотреть как поведет себя сервер с ним, я по итогу перебрал все виды NAT`а и остановился именно на ipfw nat как на более стабильном варианте.

а сервере две сетевушки (по два порта), но трафик входит в одну и выходит в другую

ясно, стандартная схема вообщем.

Подозреваю что кто то генерирует плохой трафик, который переполняет буфер сетевой карты на входе.

когда не понимают что происходит все именно это подозревают
тока как ты найдешь этот "плохой" трафик в потоке под 500 мбит/с ? вот в этом и заключается главный вопрос, на который и у меня нет ответа, как и на вопрос "а что есть плохой трафик?"

[nerik]

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

Ошибся насчет uTP, на входе тоже блочу.

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

[root]

т.к. год работало все отлично

все когда нить заканчивается
я не предлагаю тебе сменить NAT демон совсем, я предлагаю тебе посмотреть как будет обстоять ситуация с другим процессом для NAT`а

Есть подозрение что кто-то генерит мелкие пакеты

ну понятное дело что и мелкие пакеты будут, лично я сколько смотрел на трафик, в момент input errs так ничего криминального и не увидел
если увидишь ты - свистни

Ошибся насчет uTP, на входе тоже блочу

чем и как ты его блочишь ?

[murzik_one]

У меня аналогичная проблема возникает. Только при таком трафике:

Код: Выделить всё

bgp# netstat -h -I em1 -w 1
            input          (em1)           output
   packets  errs      bytes    packets  errs      bytes colls
      9.1K     0       5.5M       9.9K     0       6.8M     0
      9.1K     0       5.4M       9.9K     0       7.0M     0
      9.7K     0       5.9M        10K     0       7.4M     0
       10K     0       6.3M        11K     0       7.5M     0
      9.5K     0       6.0M        10K     0       6.2M     0
      9.5K     0       6.1M        10K     0       6.6M     0

Сейчас все спокойно, но перирдически лезут ошиюки, по входу на интерфейсе.
Сетевые 82574L.

Код: Выделить всё

FreeBSD bgp.xxx.xx 7.3-RELEASE

В message лезет следующее.

Код: Выделить всё

Mar 23 03:25:41 bgp kernel: interrupt storm detected on "irq256:"; throttling interrupt source

Код: Выделить всё

cat /boot/loader.conf
if_em_load="YES"
kern.hz=4000
hw.em.rxd=4096
hw.em.txd=4096

Код: Выделить всё

cat /etc/sysctl.conf
kern.polling.each_burst=1000
kern.polling.burst_max=1000
net.inet.ip.fastforwarding=1
net.inet.tcp.blackhole=2 
net.inet.udp.blackhole=1

Код: Выделить всё

dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 7.1.7
dev.em.1.%driver: em
dev.em.1.%location: slot=0 function=0
dev.em.1.%pnpinfo: vendor=0x8086 device=0x10d3 subvendor=0x8086 subdevice=0xa01f class=0x020000

дрова последние (февраль 2011) с интеловского сайта.
сетевая - 82574L (EXPI 9301 CTBLK) CT Desktop Adapter

5399 em1 irq259
3845 em1 irq260
em1 irq261

[root]

сетевая - 82574L (EXPI 9301 CTBLK) CT Desktop Adapter

слова Desktop Adapter тебе ни о чем не говорят ?
юзать такую сетевуху на сервере с BGP не есть гуд, десктопы сильно уступают серверным сетевухам по производительности

но перирдически лезут ошиюки, по входу на интерфейсе.

девайс, в который воткнута эта сетевуха, в твоем ведении ? что это ? что там по статистике на порту ?
патчкорд менять не прововал ?

покажи вывод

Код: Выделить всё

top -SP

в момент когда лезут ошибки, а так же посмотри на процесс swi1:net load - сколько он отъедает

попробуй выставить в sysctl такие значения:

Код: Выделить всё

dev.em.1.rx_int_delay=600
dev.em.1.tx_int_delay=600
dev.em.1.rx_abs_int_delay=1000
dev.em.1.tx_abs_int_delay=1000
dev.em.1.rx_processing_limit=1024

попробуй дрова от Yandex