Subnets.ru

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

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

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", чем для "Маршрутизация" - тему перенес.

Приветствую.
Про 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

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

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

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

nerik писал(а):Нат реализован на pf.

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

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

pfctl -sa

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

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

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

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

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

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

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

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

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

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

nerik писал(а):т.к. год работало все отлично

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

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

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

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

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

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

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

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

murzik_one писал(а):сетевая - 82574L (EXPI 9301 CTBLK) CT Desktop Adapter

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

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

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

покажи вывод

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

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