Добрый день.
Обрисовалась не стандартная проблема. Хотя возможно правильнее сказать что моя проблема объединяет в себе несколько стандартных, но правильного решения выработать так и не удалось.
Есть программный шейпер (он же биллинг LANBilling 2.0) на базе CentOS. Железо HP Proliant 380G7 с 4 Gb/s х4 картами.
Шейпер реализован на ТС+IPtables+iproute2.
Активных абонентов порядка 1500, по факту в базе 2000 абонентов. Бывают моменты в пиковые часы когда ksoftirqd уходит на одном из ядер (сетевые карты уже разнесены по ядрам) в 100%, в эти тяжелые мгновения пинг до биллинга уходит в 2000 мс, а затем вообще пропадает, на 1-2 минуты, такое ощущение что сервер упал, достучаться никакими способами не получается. Поднимается он сам, через вышеупомянутое время, и все как и раньше работает. Но с одной оговоркой пинг до него, даже с соседнего порта, как бы плавает, т.е джиттер постоянно изменятся для существующей загрузки в (10-30%) на гигабитных портах это неприемлемо, если все правильно настроено/работает. И это его нормальное состояние в любое время:
время=7мс TTL=62
время=8мс TTL=62
время=4мс TTL=62
время=5мс TTL=62
время=104мс TTL=62
время=76мс TTL=62
время=57мс TTL=62
время=7мс TTL=62
время=8мс TTL=62
время=4мс TTL=62
  При том что траффик идущий мимо сервера, в другие сети, с этого же коммутатора (cat3750G), проходит до адресата за приемлемое время (в пределах города пинг до 2мс).
Сделать вывод несложно что проблема именно в сервере, но что не так понять не могу. Правила, к слову, для iptables все оптимизированы и разнесены по разным таблицам.
Во момент последнего падение dmsg выдал следующее (самое интересное вырезал из вывода):
NETDEV WATCHDOG: eth0: transmit timed out
bnx2 0000:03:00.0: eth0: DEBUG: intr_sem[0] PCI_CMD[00100446]
bnx2 0000:03:00.0: eth0: DEBUG: PCI_PM[19002008] PCI_MISC_CFG[92000088]
bnx2 0000:03:00.0: eth0: DEBUG: EMAC_TX_STATUS[00000008] EMAC_RX_STATUS[00000000]
bnx2 0000:03:00.0: eth0: DEBUG: RPM_MGMT_PKT_CTRL[40000088]
bnx2 0000:03:00.0: eth0: DEBUG: HC_STATS_INTERRUPT_STATUS[015000af]
bnx2 0000:03:00.0: eth0: DEBUG: PBA[00000000]
bnx2 0000:03:00.0: eth0: <--- start MCP states dump --->

.......

INFO: task events/7:33 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
events/7      D ffffffff801582dc     0    33      1            34    32 (L-TLB)
ffff81031fda3db0 0000000000000046 ffffffff804e33f0 0000000000000000
0000000000000000 000000000000000a ffff81031fead080 ffff81031b10f040
002ec9787c577af3 00000000000004f7 ffff81031fead268 0000000700000001
Call Trace:

.....

INFO: task scsi_eh_1:757 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
scsi_eh_1     D ffffffff801582dc     0   757    135           758   747 (L-TLB)
ffff81031e049d80 0000000000000046 ffff81030dfa5b50 0000000000000046
ffff81031b0cb300 000000000000000a ffff81031b0fd7b0 ffff81010af98080
002ec9ab640fb27a 000000000000087e ffff81031b0fd998 000000032bf62288
Call Trace:

......

INFO: task hald-addon-stor:4178 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
hald-addon-st D ffffffff801582dc     0  4178   4155                4169 (NOTLB)
ffff81030dfa5978 0000000000000082 ffff81031a1707f0 ffff81031fedb830
002ec9ab63d32516 0000000000000009 ffff81031a1707f0 ffff81031fe3a040
002ec9ab63d368b9 000000000000022c ffff81031a1709d8 00000007880756c0
Call Trace:

....
INFO: task sshd:31695 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
sshd          D ffffffff801582dc     0 31695   4258 31697     520  8455 (NOTLB)
ffff8101e86e1b68 0000000000000086 ffff81015615e918 ffffffff80010ef0
0000000000000000 000000000000000a ffff81030ed7a7b0 ffff810318b64040
002ec9ab0a1af20e 000000000003e8ef ffff81030ed7a998 00000004880312ea
Call Trace:

...
INFO: task bash:31698 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash          D ffffffff801582dc     0 31698      1  2997    2999  8491 (L-TLB)
ffff81029bc9db68 0000000000000046 ffff81015615e7e0 ffff8100a267a780
0000000300000000 000000000000000a ffff810300db47b0 ffff81031b10f040
002ec9ab0a1f68c2 0000000000059c64 ffff810300db4998 0000000300000246
Call Trace:

NETDEV WATCHDOG: eth0: transmit timed out
bnx2 0000:03:00.0: eth0: DEBUG: intr_sem[0] PCI_CMD[00100446]
bnx2 0000:03:00.0: eth0: DEBUG: PCI_PM[19002008] PCI_MISC_CFG[92000088]
bnx2 0000:03:00.0: eth0: DEBUG: EMAC_TX_STATUS[00000008] EMAC_RX_STATUS[00000000]
bnx2 0000:03:00.0: eth0: DEBUG: RPM_MGMT_PKT_CTRL[40000088]
bnx2 0000:03:00.0: eth0: DEBUG: HC_STATS_INTERRUPT_STATUS[014000bf]
bnx2 0000:03:00.0: eth0: DEBUG: PBA[00000000]
bnx2 0000:03:00.0: eth0: <--- start MCP states dump --->
bnx2 0000:03:00.0: eth0: DEBUG: MCP_STATE_P0[0003610e] MCP_STATE_P1[0003610e]
bnx2 0000:03:00.0: eth0: DEBUG: MCP mode[0000b880] state[80008000] evt_mask[00000500]
bnx2 0000:03:00.0: eth0: DEBUG: pc[0800b31c] pc[0800d1b4] instr[10400044]
bnx2 0000:03:00.0: eth0: DEBUG: shmem states:
bnx2 0000:03:00.0: eth0: DEBUG: drv_mb[0103000b] fw_mb[0000000b] link_status[0000006f] drv_pulse_mb[00005355]
bnx2 0000:03:00.0: eth0: DEBUG: dev_info_signature[44564903] reset_type[01005254] condition[0003610e]
bnx2 0000:03:00.0: eth0: DEBUG: 000003cc: 44444444 44444444 44444444 00000a3c
bnx2 0000:03:00.0: eth0: DEBUG: 000003dc: 0ffeffff 0000ffff ffffffff ffffffff
bnx2 0000:03:00.0: eth0: DEBUG: 000003ec: 00000000 00000000 00000000 00000002
bnx2 0000:03:00.0: eth0: DEBUG: 0x3fc[0000ffff]
bnx2 0000:03:00.0: eth0: <--- end MCP states dump --->
bnx2i [03:00.00]: ISCSI_INIT passed
bnx2 0000:03:00.0: eth0: NIC Copper Link is Down
bnx2i [03:00.00]: ISCSI_INIT passed
bnx2i [03:00.00]: ISCSI_INIT passed
sr 1:0:0:0: timing out command, waited 120s
bnx2 0000:03:00.0: eth0: NIC Copper Link is Up, 1000 Mbps full duplex

т.е. дошло до того что физический линк упал, о чем так же свидетельствует запись в логе calalyst. Ошибок на портах нет, если линки от сетевых карт этого же сервера на другие циски, но там ситуация такая же. Пинг с самого биллинга так же "плавает" до любых сервисов.
  Куда копать примерно представил - это драйвер сетевой, порты, патчкорд, даже могу предположить что проблема в ядре (было сказано в одной из статей) например поддержка NAPI не включена, но хочется услышать мнение экспертов, либо людей уже лечивших подобное. Так как проблема (с пингом) существует даже не в пиковые часы, а круглосуточно. И есть огромная вероятность что это взаимосвязано.

Для более глубокого понимания сути происходящего так же:
Дистрибутив: CentOS
Ядро: 2.6.18-371.6.1.el5
Сеть: Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20)

ethtool -i eth0
driver: bnx2
version: 2.1.11
firmware-version: bc 5.2.3 NCSI 2.0.6
bus-info: 0000:03:00.0

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