DemYaN

Добрый день! Имеется WS-C3550-48 (c3550-ipservicesk9-mz.122-46.SE.bin), который соединен патчкордом с Edge-Core ES3528M. Со стороны 3528M - SFP, со стороны 3550 - GBIC. 3550 в качестве L3 роутит 15 vlan'ов. Наблюдается рост отклика проходящего через 3550 трафика с 0.5-1мс до 5-10мс. При этом на "аплинке" Gi 0/1 наблюдается такая картина: #sh interfaces gigabitEthernet 0/1 GigabitEthernet0/1 is up, line protocol is up (connected) Hardware is Gigabit Ethernet, address is 000d.bd68.5c31 (bia 000d.bd68.5c31) Description: EDGECORE-1G MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 42/255, rxload 42/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex, 1000Mb/s, link type is force-up, media type is 1000BaseSX input flow-control is off, output flow-control is on ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:01, output 00:00:00, output hang never Last clearing of "show interface" counters 14w5d Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 166037000 bits/sec, 27439 packets/sec 5 minute output rate 165360000 bits/sec, 28320 packets/sec 586688152 packets input, 958007710 bytes, 0 no buffer Received 37742128 broadcasts (0 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 38456659 ignored 0 watchdog, 1361293 multicast, 0 pause input 0 input packets with dribble condition detected 2292900146 packets output, 1855456334 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 11817634 PAUSE output 0 output buffer failures, 0 output buffers swapped out Растут: 38456659 ignored 11817634 PAUSE output при 5 minute input rate 166037000 bits/sec, 27439 packets/sec 5 minute output rate 165360000 bits/sec, 28320 packets/sec #sh controller ethernet-controller gigabitEthernet 0/1 Transmit GigabitEthernet0/1 Receive 1403621187 Bytes 688155122 Bytes 2078441936 Unicast frames 553916708 Unicast frames 76440603 Multicast frames 1262744 Multicast frames 143370555 Broadcast frames 36219244 Broadcast frames 0 Discarded frames 297234 No dest, unicast 0 Too old frames 98961 No dest, multicast 0 Deferred frames 164593 No dest, broadcast 0 1 collision frames 0 2 collision frames 0 FCS errors 0 3 collision frames 0 Oversize frames 0 4 collision frames 0 Undersize frames 0 5 collision frames 0 Collision fragments 0 6 collision frames 0 7 collision frames 452296833 Minimum size frames 0 8 collision frames 1599039839 65 to 127 byte frames 0 9 collision frames 472572638 128 to 255 byte frames 0 10 collision frames 1736968854 256 to 511 byte frames 0 11 collision frames 1690123696 512 to 1023 byte frames 0 12 collision frames 1951257046 1024 to 1518 byte frames 0 13 collision frames 0 14 collision frames 0 Flooded frames 0 15 collision frames 38467786 Overrun frames 0 Excessive collisions 1584 VLAN filtered frames 0 Late collisions 0 Source routed frames 0 Good (1 coll) frames 0 Valid oversize frames 0 Good(>1 coll) frames 0 Pause frames 11821436 Pause frames 0 Symbol error frames 0 VLAN discard frames 0 Invalid frames, too large 0 Excess defer frames 0 Valid frames, too large 0 Too large frames 0 Invalid frames, too small 2433486837 64 byte frames 1318102956 Valid frames, too small 167069862 127 byte frames 3708440077 255 byte frames 1135957489 511 byte frames 1327615098 1023 byte frames 2115619470 1518 byte frames Растут: 38467786 Overrun frames 11821436 Pause frames 1318102956 Valid frames, too small Может у кого-то есть соображения, в чем может быть причина таких симптомов? L3-функция на GE-интерфейсах в 3550 ведь не oversubscribed?

8.1 нормально работает: igb0: <Intel® PRO/1000 Network Connection version - 2.0.1> igb0: Using MSIX interrupts with 5 vectors

Отсюда и нужно начинать, очень помогает. Не думал, что будет все так просто.... забираю назад весь свой скептицизм :) Прибив dummynet к одному ядру, он опустился в top'e просто ниже приличного: # top -PSH last pid: 52050; load averages: 0.26, 0.21, 0.17 up 36+10:46:46 21:26:10 126 processes: 6 running, 93 sleeping, 27 waiting CPU 0: 0.0% user, 0.0% nice, 6.5% system, 3.2% interrupt, 90.3% idle CPU 1: 0.0% user, 0.0% nice, 8.9% system, 3.3% interrupt, 87.8% idle CPU 2: 0.0% user, 0.0% nice, 3.3% system, 1.6% interrupt, 95.1% idle CPU 3: 0.0% user, 0.0% nice, 5.7% system, 4.1% interrupt, 90.2% idle Mem: 116M Active, 76M Inact, 205M Wired, 210M Buf, 1546M Free Swap: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 64K CPU0 0 863.7H 99.46% {idle: cpu0} 11 root 171 ki31 0K 64K CPU2 2 868.3H 95.41% {idle: cpu2} 11 root 171 ki31 0K 64K CPU3 3 869.3H 92.43% {idle: cpu3} 11 root 171 ki31 0K 64K RUN 1 863.4H 88.92% {idle: cpu1} 965 root 46 - 0K 64K RUN 1 155:16 4.49% {ng_queue1} 965 root 46 - 0K 64K sleep 3 156:18 3.03% {ng_queue2} 965 root 46 - 0K 64K sleep 2 156:32 2.93% {ng_queue3} 965 root 46 - 0K 64K sleep 0 155:56 2.93% {ng_queue0} 12 root -68 - 0K 432K WAIT 1 69:00 2.25% {irq257: igb0:que} 12 root -68 - 0K 432K WAIT 3 68:50 1.86% {irq259: igb0:que} 12 root -68 - 0K 432K WAIT 3 71:41 1.46% {irq264: igb1:que} 12 root -68 - 0K 432K WAIT 0 95:59 1.42% {irq256: igb0:que} 0 root -68 0 0K 224K - 2 82:59 1.12% {igb0 que} 12 root -68 - 0K 432K WAIT 2 65:19 0.93% {irq258: igb0:que} 12 root -68 - 0K 432K WAIT 2 45:38 0.93% {irq263: igb1:que} 12 root -68 - 0K 432K WAIT 1 53:34 0.68% {irq262: igb1:que} 12 root -68 - 0K 432K WAIT 0 48:26 0.68% {irq261: igb1:que} 12 root -32 - 0K 432K WAIT 0 386:29 0.05% {swi4: clock} 0 root -68 0 0K 224K - 3 336:01 0.00% {dummynet} Всем спасибо !

ок, это все понятно Вопрос в другом, попробую перефразировать - является ли нормальным такое потребление процессорного времени dummynet'ом при трафике в 50kpps, 250 pptp-туннелях, шейпе dummynet/tablearg (dummynet не прибит к конкретному ядру) и процессоре класса Сore i5 760? Параметр уcтановлен:

ок, с ng_queue понятно - прибить на разные ядра А как быть с dummynet, не многовато ли 32% на таком трафике с таким кол-вом сессий? Ведь dummynet крутится как один процесс и по ядрам его не раскидаешь - значит нужно как-то снижать потребление процессорного времени.

тем не менее в топе CPU 0: 0.0% user, 0.0% nice, 2.2% system, 3.3% interrupt, 94.4% idle CPU 1: 0.0% user, 0.0% nice, 60.0% system, 2.8% interrupt, 37.2% idle CPU 2: 0.0% user, 0.0% nice, 1.7% system, 3.3% interrupt, 95.0% idle CPU 3: 0.0% user, 0.0% nice, 2.8% system, 2.2% interrupt, 95.0% idle 0 root -68 0 0K 224K - 2 187:29 31.45% {dummynet} 965 root 48 - 0K 64K sleep 0 64:45 8.11% {ng_queue0} 965 root 48 - 0K 64K sleep 1 65:23 7.28% {ng_queue2} 965 root 48 - 0K 64K sleep 1 65:33 7.23% {ng_queue3} 965 root 48 - 0K 64K sleep 0 64:25 6.49% {ng_queue1} 8.11 + 6.49 как то больше чем (2.2% system, 3.3% interrupt) dummynet, как я понимаю бегает одним процессом, но это не объясняет почему он ест 32% от ядра

ну это я так понимаю ng_car? в любом случае, не объяснеят по чему все ng_queueX висят на одном ядре

Добрый день, может кто подскажет? Дано: FreeBSD 8.1-RELEASE (именно релиз), CPU Intel Core i5 CPU 760 @ 2.80GHz, сетвые Intel ET, обновленный драйвер igb (взят из пака от wawa.) Индивидульаные настройки такие: # cat /etc/sysctl.conf net.inet.flowtable.enable=0 net.inet.ip.dummynet.expire=1 net.inet.ip.dummynet.hash_size=512 net.inet.ip.dummynet.io_fast=1 net.inet.ip.fw.dyn_max=65535 net.inet.ip.fw.one_pass=1 # cat /boot/loader.conf kern.hz=2000 kern.maxusers=512 kern.ipc.nmbclusters=131072 net.graph.maxalloc=2048 hw.igb.rxd=1024 hw.igb.txd=1024 hw.igb.num_queues=4 hw.igb.lro=0 hw.igb.enable_msix=1 hw.igb.rx_process_limit=2048 hw.igb.fc_setting=0 # sysctl -a |grep dummynet net.inet.ip.dummynet.io_pkt_drop: 84795758 net.inet.ip.dummynet.io_pkt_fast: 1410048755 net.inet.ip.dummynet.io_pkt: 3323982346 net.inet.ip.dummynet.queue_count: 0 net.inet.ip.dummynet.fsk_count: 18 net.inet.ip.dummynet.si_count: 305 net.inet.ip.dummynet.schk_count: 36 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: 32002371 net.inet.ip.dummynet.tick_adjustment: 20236524 net.inet.ip.dummynet.tick_delta_sum: 284 net.inet.ip.dummynet.tick_delta: 500 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.expire_cycle: 0 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.io_fast: 1 net.inet.ip.dummynet.pipe_byte_limit: 1048576 net.inet.ip.dummynet.pipe_slot_limit: 100 net.inet.ip.dummynet.hash_size: 512 На машине только терминация pptp-туннелей на mpd5.5 и шейп dummynet/tablearg. Трафик детский - около 50k: input (Total) output packets errs idrops bytes packets errs bytes colls 46K 0 0 28M 53K 0 38M 0 45K 0 0 27M 50K 0 37M 0 46K 0 0 28M 52K 0 38M 0 Cессий также мало: # ifconfig |grep ng |wc -l 222 При этом всем загрузка ядер: # top -PSHI last pid: 85116; load averages: 0.12, 0.12, 0.08 up 34+03:53:20 14:32:44 124 processes: 5 running, 92 sleeping, 27 waiting CPU 0: 0.0% user, 0.0% nice, 2.2% system, 3.3% interrupt, 94.4% idle CPU 1: 0.0% user, 0.0% nice, 60.0% system, 2.8% interrupt, 37.2% idle CPU 2: 0.0% user, 0.0% nice, 1.7% system, 3.3% interrupt, 95.0% idle CPU 3: 0.0% user, 0.0% nice, 2.8% system, 2.2% interrupt, 95.0% idle Mem: 104M Active, 70M Inact, 202M Wired, 100K Cache, 210M Buf, 1567M Free Swap: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 64K CPU3 3 817.5H 100.00% {idle: cpu3} 11 root 171 ki31 0K 64K CPU2 2 817.0H 100.00% {idle: cpu2} 11 root 171 ki31 0K 64K RUN 0 813.4H 96.97% {idle: cpu0} 11 root 171 ki31 0K 64K CPU1 1 812.8H 43.26% {idle: cpu1} 0 root -68 0 0K 224K - 2 187:29 31.45% {dummynet} 965 root 48 - 0K 64K sleep 0 64:45 8.11% {ng_queue0} 965 root 48 - 0K 64K sleep 1 65:23 7.28% {ng_queue2} 965 root 48 - 0K 64K sleep 1 65:33 7.23% {ng_queue3} 965 root 48 - 0K 64K sleep 0 64:25 6.49% {ng_queue1} 12 root -68 - 0K 432K WAIT 1 29:36 1.66% {irq257: igb0:que} 12 root -68 - 0K 432K WAIT 3 29:26 1.03% {irq259: igb0:que} 12 root -68 - 0K 432K WAIT 0 42:31 0.98% {irq256: igb0:que} 0 root -68 0 0K 224K - 3 34:27 0.98% {igb0 que} 12 root -68 - 0K 432K WAIT 2 27:01 0.83% {irq258: igb0:que} 12 root -68 - 0K 432K WAIT 2 17:11 0.83% {irq263: igb1:que} 12 root -68 - 0K 432K WAIT 0 19:00 0.68% {irq261: igb1:que} 12 root -68 - 0K 432K WAIT 3 29:35 0.63% {irq264: igb1:que} 12 root -68 - 0K 432K WAIT 1 25:22 0.29% {irq262: igb1:que} 61863 root 44 0 40180K 12280K select 1 1:38 0.05% {mpd5} Сразу бросается в галаза, что все нити ng_queue висят на одном ядре: CPU 1: 0.0% user, 0.0% nice, 60.0% system, 2.8% interrupt, 37.2% idle 0 root -68 0 0K 224K - 2 187:29 31.45% {dummynet} 965 root 48 - 0K 64K sleep 0 64:45 8.11% {ng_queue0} 965 root 48 - 0K 64K sleep 1 65:23 7.28% {ng_queue2} 965 root 48 - 0K 64K sleep 1 65:33 7.23% {ng_queue3} 965 root 48 - 0K 64K sleep 0 64:25 6.49% {ng_queue1} Почему так? dummynеt отедает 31.45% от ядра, это нормально? При этом ipfw/pipe такого вида: IF_EXT="igb0" ${IPFW} pipe 21 config bw 250kbit/s queue 10 mask dst-ip 0xffffffff ${IPFW} pipe 22 config bw 250kbit/s queue 10 mask src-ip 0xffffffff .... ${IPFW} pipe 81 config bw 8Mbit/s mask dst-ip 0xffffffff ${IPFW} pipe 82 config bw 8Mbit/s mask src-ip 0xffffffff ${IPFW} add pipe tablearg ip from any to 'table(11)' in recv ${IF_EXT} ${IPFW} add pipe tablearg ip from 'table(12)' to any out xmit ${IF_EXT} ${IPFW} add allow ip from any to ${LOCAL_PPP} out xmit ng* ${IPFW} add allow ip from ${LOCAL_PPP} to any in recv ng* # ipfw table 11 list |wc -l 219 # ipfw table 12 list |wc -l 219 # ipfw pipe show |grep active sched 65607 type FIFO flags 0x1 512 buckets 69 active sched 65608 type FIFO flags 0x1 512 buckets 73 active sched 65617 type FIFO flags 0x1 512 buckets 5 active sched 65557 type FIFO flags 0x1 512 buckets 1 active sched 65618 type FIFO flags 0x1 512 buckets 5 active sched 65558 type FIFO flags 0x1 512 buckets 1 active sched 65628 type FIFO flags 0x1 512 buckets 6 active sched 65627 type FIFO flags 0x1 512 buckets 7 active sched 65567 type FIFO flags 0x1 512 buckets 0 active sched 65638 type FIFO flags 0x1 512 buckets 5 active sched 65568 type FIFO flags 0x1 512 buckets 0 active sched 65637 type FIFO flags 0x1 512 buckets 5 active sched 65578 type FIFO flags 0x1 512 buckets 32 active sched 65577 type FIFO flags 0x1 512 buckets 32 active sched 65587 type FIFO flags 0x1 512 buckets 0 active sched 65588 type FIFO flags 0x1 512 buckets 0 active sched 65598 type FIFO flags 0x1 512 buckets 34 active sched 65597 type FIFO flags 0x1 512 buckets 34 active

Собственно сам нашел ответ: http://forum.nag.ru/forum/index.php?showtopic=58972 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/148316

Наблюдаю странную работу (точнее неработу :) ) квагги на FreeBSD 8.1, похожий баг был с 7-кой (https://bugzilla.quagga.net/show_bug.cgi?id=420). В моем случае с одной стороны стоит linux + quagga-0.99.5, с другой FreeBSD 8.1-RELEASE + quagga-0.99.16. Пытаюсь научить их общаться на OSPF в режиме multicast, но похоже у квагги на FreeBSD 8.1 c этим проблемы: На linux видно, что hello-пакеты уходят/приходят из интерфейса, в логах видно что hello от соседа обрабатываются: /var/log/quagga/ospfd.log: 2010/09/25 22:18:11 OSPF: make_: options: 2, int: eth0.11:xxx.xxx.xxx.233 2010/09/25 22:18:11 OSPF: Packet 10.0.0.2 [Hello:RECV]: Options *|-|-|-|-|-|E|* 2010/09/25 22:18:21 OSPF: make_hello: options: 2, int: eth0.11:xxx.xxx.xxx.233 2010/09/25 22:18:21 OSPF: Packet 10.0.0.2 [Hello:RECV]: Options *|-|-|-|-|-|E|* # tcpdump -ni eth0.11 proto ospf 22:18:11.623988 IP xxx.xxx.xxx.233 > 224.0.0.5: OSPFv2, Hello, length: 48 22:18:11.632215 IP xxx.xxx.xxx.234 > 224.0.0.5: OSPFv2, Hello, length: 44 22:18:21.624944 IP xxx.xxx.xxx.233 > 224.0.0.5: OSPFv2, Hello, length: 48 22:18:21.632772 IP xxx.xxx.xxx.234 > 224.0.0.5: OSPFv2, Hello, length: 44 На FreeBSD hello-пакеты уходят/приходят из интерфейса, НО логах не видно чтоб hello от соседа обрабатывались: /var/log/quagga/ospfd.log: 22:18:08.759941 IP xxx.xxx.xxx.233 > 224.0.0.5: OSPFv2, Hello, length 48 22:18:08.766586 IP xxx.xxx.xxx.234 > 224.0.0.5: OSPFv2, Hello, length 44 22:18:18.761290 IP xxx.xxx.xxx.233 > 224.0.0.5: OSPFv2, Hello, length 48 22:18:18.767324 IP xxx.xxx.xxx.234 > 224.0.0.5: OSPFv2, Hello, length 44 # tcpdump -ni igb0 proto ospf 2010/09/25 22:18:08 OSPF: make_hello: options: 2, int: igb0:xxx.xxx.xxx.234 2010/09/25 22:18:18 OSPF: make_hello: options: 2, int: igb0:xxx.xxx.xxx.234 Причем на FreeBSD интерфейс по которому бегает ospf (igb0) не слушает multicast-группу 224.0.0.5: # ifmcstat -i igb0 igb0: inet xxx.xxx.xxx.234 igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 group 224.0.0.1 mode exclude mcast-macaddr 01:00:5e:00:00:01 но в тоже время в этой группе второй интерфейс на этой машине: # ifmcstat -i igb1 igb1: inet xxx.xxx.xxx.14 igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 group 224.0.0.6 mode exclude mcast-macaddr 01:00:5e:00:00:06 group 224.0.0.5 mode exclude mcast-macaddr 01:00:5e:00:00:05 group 224.0.0.1 mode exclude mcast-macaddr 01:00:5e:00:00:01 Наблюдает ли еще кто-нибудь подобную проблему?

первые две вещи которые настораживают: 2.6.18-164.11.1.el5xen

В будущем было бы плюсом прямое управление дисциплинами (через libnl?), но думаю на первом этапе это не столь необходимо ведь у каждого своя схема - кто-то ограничивает через tbf , кто-то строит иерархии классов и прочее. Вызов скрипта и передача ему новых атрибутов - первоочередная задача (на мой взгляд). И тут стоит учесть возможность скрипту вернуть код успешности/не успешности обработки атрибутов, и далее на основе этого передавать радиусу coa-nak или coa-ack. 2 NiTr0 я уже присматривался, возможно так и будет :)

понимаю, что не стоит торопить события :) но когда по планам предвидится обработка CoA-Request?

если есть возможность, поставьте ядро из lenny-backports PS кстати, какие правила передаются tc, используется ли ifb PPS nuclearcat кажется наблюдал подобный баг, может он сможет подсказать

но планка то - 70kpps... это мало с dos'ом или без него

Если проц не загружен под 100%, то проблема не в фильтрах, а в недостаточном размере каких-то буферов для хранения пакетов, IMHO. см. пост #11иначе были бы значительные дропы

то бишь на ingress ограничивается скорость всего трафика? или с ingerss все-таки перенаправляется скажем на ifb, а там свои классы? имхо, надо все-таки u32-фильтры переделывать

перенаправить вывод консоли на последовательный порт, подключиться с другой машины и писать логи

Лично мне не совсем понятно, на что именно влияют значения /proc/sys/net/core/rmem|wmem_max , потому что для буферов сокетов есть другие параметры помимо tcp/udp есть и другие протоколы, например netlink

rmem и wmem тут уж точно не помогут, они влияют лишь на буферы сокетов (tcp, udp, netlink и прочее) ps замена sfq на pfifo сильно изменила ситуацию?

Поделитесь, есть ли у кого есть MIB'ы для Mediant 600. Спасибо!

cудя по выводу профайлера, который привел топикстартер, sfq ест не много:1177341 2.4381 sch_sfq сам использую sfq, классов около 4000: 1023.00 - 1.2% : sfq_enqueue [sch_sfq]

нужно многоуровневые строить

оу, будем знать, ибо nmi_watchdog используется активно

ну если шейпа нет, то фиксированное значение HZ и отказ от hrtimers может будет и лучше... но если шейп то hrtimers и соответственно NO_HZ оно то кончено да, но помнится были какие-то проблемы еще в 2.6.28....порылся и нашел: http://lists.openwall.net/netdev/2009/01/09/63 http://lists.openwall.net/netdev/2009/01/13/14