Перейти к содержимому
Калькуляторы

vinnipux

Пользователи
  • Публикации

    14
  • Зарегистрирован

  • Посещение

О vinnipux

  • Звание
    Абитуриент

Информация

  • Пол
    Не определился

Город

  • Город
    Украина, Луганск
  1. Спасибо за советы, на днях попробую 64-х битку с учетом ваших рекомендаций. Результат отпишу.
  2. О хешировании я в курсе, и в курсе о достаточно удобном скрипте sc, но его я пока тестирую в виртуалках и на практике не применяю. Не уверен, что в моих условиях это то, что мне нужно. Клиентов согласно тарифов я жму на брасах. Я просто пытаюсь понять - 10 правил на конкретные адреса/сетки на 4-16 адресов и одно правило для всего остального могут так влиять на пропускную способность на скорости выше 1.5Гбит? Я ведь не пытаюсь прописать тысячи правил, в которых будут перечислены каждый из 3-х тысяч моих ip-адресов ... И неужели конструкция вида /sbin/tc class add dev bond0 parent 1:2 classid 1:900 htb rate 100Mbit ceil 1950Mbit prio 1 /sbin/tc qdisc add dev bond0 parent 1:900 handle 900 pfifo limit 50000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.0/21 classid 1:900 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 191.21.12.0/22 classid 1:900 способна привести к такому росту затрат на проверку, одну проверку каждого пакета, ведь в данном случае по идее должна матчиться какая-то часть заголовка dst длина которого определяет маска. Может u32 match сам по себе не оптимален и не высокопроизводителен? Кроме всего прочего, правильно ли я понял прочитав кучу разных источников, что шейпер собственно в текущей его реализации не паралеллится толком, что приводит к блокировкам и эффекту бутылочного горлышка, не важно сколько у тебя очередей в картах и ядер в проце? .... Или по уму мне нужно все-таки создать описание для каждого ip-адреса из всех моих сетей, используя хеши, что породит кучу правил, пускай они будут и оптимизированные. Не усугубит ли такой вариант текущее положение? Просто на текущий момент пока все что мне нужно это отрегулировать скорость на десяток небольших сеток и обозначить некую общую скорость для всех остальных, не уточняя полосу для каждого ip из имеющегося пула, но хотелось бы. Есть сомнения, что роутер прожует это все, даже если набор правил будет оптимизирован хешами. И еще очень интересно какая у кого максимальная скорость была достигнута на роутере с включенным шейпером.
  3. Подскажите, я вот сколько не мучаюсь, а мне не удается подтюнить все таким образом, что-бы умудряться до 2Гбит пережевывать и при этом что-бы HTB был активен. По наблюдениям упираюсь в полочку 1.3-1.4Гбит/сек, снимаю шейп - железо жует до 2Гбит в пиках. Роутер: Motherboard: Intel Corporation S1200BTL CPU: Intel® Xeon® CPU E31240 @ 3.30GHz 4-ядра + HT RAM: 2048 Mb (DIMM DDR3 Synchronous 1333 MHz) Две дуальных Интеловских сетевых карты E1G42ET с чипом 82576 (8 Tx/8 Rx очередей) - отличные карты. *-network:0 description: Ethernet interface product: 82576 Gigabit Network Connection vendor: Intel Corporation physical id: 0 bus info: pci@0000:02:00.0 logical name: eth1 version: 01 serial: 90:e2:ba:01:00:ca size: 1Gbit/s capacity: 1Gbit/s width: 32 bits clock: 33MHz capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=igb driverversion=4.0.1-k duplex=full firmware=1.21, 0x0000c822 latency=0 link=yes multicast=yes port=twisted pair slave=yes speed=1Gbit/s resources: irq:17 memory:84020000-8403ffff memory:83c00000-83ffffff ioport:4020(size=32) memory:84050000-84053fff memory:83800000-83bfffff memory:840c0000-840dffff memory:840a0000-840bffff Использую Fedora release 16, ядро Linux 3.6.2-1.fc16.i686 SMP. Первый вопрос - имеет ли смысл использовать 64-х битную платформу, учитывая то, что все равно ширина шины PCI Express 32 бита для этой карты? Однозначного ответа на форуме я не нашел. Ядра менял, было из ветки 3.2.x, 3.5.x и сейчас 3.6.x. Разница заметил только в стратегии ITR по умолчанию в драйвере igb, в 3.6.x по умолчанию пытается генерить максимальное их количество ради low latency. Организованы сетевые карты в 2 bond-а, роутер прокачивает транзитный трафик. Поверх одного из bond-ов 2 vlan-а к upstream-у. Пытаюсь оставить шейпер, который ранее работал, пока транзитная скорость не превысила порог в 1.3-1.5Гбит/сек. Пакетов в эти моменты 190 - 220 kpps. [root@router ~]# netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg bond0 1500 0 19185494382 15 448 0 21329148281 0 0 0 BMmRU bond1 1500 0 25699052468 0 2 0 22855408501 0 0 0 BMmRU eth1 1500 0 12836963978 0 2 0 11465654686 0 0 0 BMsRU lo 16436 0 1558 0 0 0 1558 0 0 0 LRU p2p1 1500 0 12862089479 0 0 0 11389754828 0 0 0 BMsRU p3p1 1500 0 9587131662 15 423 0 10665163154 0 0 0 BMsRU p3p2 1500 0 9598368418 0 25 0 10663991273 0 0 0 BMsRU p4p1 1500 0 525383653 1 27230 0 702324681 0 0 0 BMRU vlan2221 1500 0 14003950137 0 0 0 14642263912 0 0 0 BMRU vlan2222 1500 0 5376330383 0 0 0 6784434053 0 0 0 BMRU Особых проблем здесь не вижу /sbin/tc class add dev bond0 parent 1: classid 1:2 htb rate 1950Mbit /sbin/tc class add dev bond0 parent 1:2 classid 1:20 htb rate 20Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:20 handle 20 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 191.21.12.248/29 classid 1:20 /sbin/tc class add dev bond0 parent 1:2 classid 1:25 htb rate 4Mbit ceil 10Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:25 handle 25 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 191.21.12.45 classid 1:25 /sbin/tc class add dev bond0 parent 1:2 classid 1:30 htb rate 2Mbit ceil 2Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:30 handle 30 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 191.21.12.240/29 classid 1:30 /sbin/tc class add dev bond0 parent 1:2 classid 1:35 htb rate 10Mbit ceil 50Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:35 handle 35 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.248/29 classid 1:35 /sbin/tc class add dev bond0 parent 1:2 classid 1:40 htb rate 10Mbit ceil 100Mbit prio 4 /sbin/tc qdisc add dev bond0 parent 1:40 handle 40 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.180/30 classid 1:40 /sbin/tc class add dev bond0 parent 1:2 classid 1:50 htb rate 8Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:50 handle 50 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.228/30 classid 1:50 /sbin/tc class add dev bond0 parent 1:2 classid 1:51 htb rate 8Mbit ceil 30Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:51 handle 51 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.188/30 classid 1:51 /sbin/tc class add dev bond0 parent 1:2 classid 1:60 htb rate 10Mbit ceil 100Mbit prio 2 /sbin/tc qdisc add dev bond0 parent 1:60 handle 60 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.232/30 classid 1:60 /sbin/tc class add dev bond0 parent 1:2 classid 1:70 htb rate 2Mbit ceil 10Mbit burst 512Kbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:70 handle 70 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 146.11.40.224/30 classid 1:70 /sbin/tc class add dev bond0 parent 1:2 classid 1:80 htb rate 4Mbit ceil 5Mbit prio 0 /sbin/tc qdisc add dev bond0 parent 1:80 handle 80 pfifo limit 10000 /sbin/tc filter add dev bond0 parent 1:0 protocol ip prio 100 u32 match ip dst 191.21.12.86 classid 1:80 /sbin/tc class add dev bond0 parent 1:2 classid 1:9000 htb rate 100Mbit ceil 1950Mbit prio 1 /sbin/tc qdisc add dev bond0 parent 1:9000 handle 9000 pfifo limit 50000 Пробовал строить классы по разному, если выделять все свои сети в отдельный класс и матчить их по единой маске 146.11.40.0/21 и 191.21.12.0/22 то это приводит к плачевным результатам, становится ощутимой задержка, от десятков до сотен мсек, увеличивается в процентах _raw_spin_lock на полтора десятка, в общем решил упростить шейпер по максимуму. Но это все равно не помогает. Распределение прерываний CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 125 0 0 0 0 0 0 0 IO-APIC-edge timer 8: 1 0 0 0 0 0 0 0 IO-APIC-edge rtc0 9: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi acpi 20: 410 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2 22: 64 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1 40: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 41: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 42: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 43: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 44: 0 0 0 0 0 0 0 0 PCI-MSI-edge PCIe PME 45: 255336 0 0 0 0 0 0 0 PCI-MSI-edge ahci 46: 2 0 0 0 0 0 0 0 PCI-MSI-edge eth1 47: 5991745 0 0 0 0 0 199810568 0 PCI-MSI-edge eth1-TxRx-0 48: 12901302 0 0 0 0 232654567 0 0 PCI-MSI-edge eth1-TxRx-1 49: 5974164 0 0 0 201890361 0 0 0 PCI-MSI-edge eth1-TxRx-2 50: 5730835 0 0 199537269 0 0 0 0 PCI-MSI-edge eth1-TxRx-3 51: 6169897 0 199089475 0 0 0 0 0 PCI-MSI-edge eth1-TxRx-4 52: 6014566 199061856 0 0 0 0 0 0 PCI-MSI-edge eth1-TxRx-5 53: 208085233 0 0 0 0 0 0 0 PCI-MSI-edge eth1-TxRx-6 54: 6258764 0 0 0 0 0 0 200327414 PCI-MSI-edge eth1-TxRx-7 55: 632 0 0 0 0 0 89950 0 PCI-MSI-edge eth0 56: 2 0 0 0 0 0 0 0 PCI-MSI-edge p2p1 57: 6204529 0 0 0 198922711 0 0 0 PCI-MSI-edge p2p1-TxRx-0 58: 13394220 0 0 230589054 0 0 0 0 PCI-MSI-edge p2p1-TxRx-1 59: 6135941 0 199756903 0 0 0 0 0 PCI-MSI-edge p2p1-TxRx-2 60: 6639134 198238947 0 0 0 0 0 0 PCI-MSI-edge p2p1-TxRx-3 61: 205084685 0 0 0 0 0 0 0 PCI-MSI-edge p2p1-TxRx-4 62: 6208566 0 0 0 0 0 0 199051642 PCI-MSI-edge p2p1-TxRx-5 63: 5931442 0 0 0 0 0 199487980 0 PCI-MSI-edge p2p1-TxRx-6 64: 5977224 0 0 0 0 200533387 0 0 PCI-MSI-edge p2p1-TxRx-7 65: 1766399 0 0 0 89456666 0 0 0 PCI-MSI-edge p4p1-rx-0 66: 1991472 0 0 107225385 0 0 0 0 PCI-MSI-edge p4p1-tx-0 67: 3 0 0 0 0 0 0 0 PCI-MSI-edge p4p1 68: 2 0 0 0 0 0 0 0 PCI-MSI-edge p3p1 69: 211719881 0 0 0 0 0 0 0 PCI-MSI-edge p3p1-TxRx-0 70: 7012438 0 0 0 0 0 0 203903436 PCI-MSI-edge p3p1-TxRx-1 71: 7003509 0 0 0 0 0 203555130 0 PCI-MSI-edge p3p1-TxRx-2 72: 6919736 0 0 0 0 202754172 0 0 PCI-MSI-edge p3p1-TxRx-3 73: 7027187 0 0 0 204993214 0 0 0 PCI-MSI-edge p3p1-TxRx-4 74: 7139353 0 0 203823562 0 0 0 0 PCI-MSI-edge p3p1-TxRx-5 75: 6759960 0 204092355 0 0 0 0 0 PCI-MSI-edge p3p1-TxRx-6 76: 7204501 204422491 0 0 0 0 0 0 PCI-MSI-edge p3p1-TxRx-7 77: 2 0 0 0 0 0 0 0 PCI-MSI-edge p3p2 78: 6877916 0 0 0 0 0 0 204781334 PCI-MSI-edge p3p2-TxRx-0 79: 6393147 0 0 0 0 0 203716187 0 PCI-MSI-edge p3p2-TxRx-1 80: 7141383 0 0 0 0 204750428 0 0 PCI-MSI-edge p3p2-TxRx-2 81: 7022920 0 0 0 205615894 0 0 0 PCI-MSI-edge p3p2-TxRx-3 82: 6970851 0 0 204054467 0 0 0 0 PCI-MSI-edge p3p2-TxRx-4 83: 7004182 0 203495312 0 0 0 0 0 PCI-MSI-edge p3p2-TxRx-5 84: 6911389 204867882 0 0 0 0 0 0 PCI-MSI-edge p3p2-TxRx-6 85: 213496439 0 0 0 0 0 0 0 PCI-MSI-edge p3p2-TxRx-7 NMI: 91201 70585 69293 73489 58301 74423 66984 43383 Non-maskable interrupts LOC: 13766383 8523304 8673018 8005414 7866149 7767025 8371333 6477920 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 91201 70585 69293 73489 58301 74423 66984 43383 Performance monitoring interrupts IWI: 10 7 6 7 5 7 6 2 IRQ work interrupts RTR: 5 0 0 0 0 0 0 0 APIC ICR read retries RES: 385924 544144 22135 8521 6339 4366 3465 4986 Rescheduling interrupts CAL: 15186 17432 16232 17279 16851 29530 25873 22421 Function call interrupts TLB: 0 0 0 0 0 0 0 0 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 605 605 605 605 605 605 605 605 Machine check polls ERR: 0 MIS: 0 cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc [root@router ~]# mpstat -P ALL 1 Linux 3.6.2-1.fc16.i686 (router) 06.11.2012 _i686_ (8 CPU) 20:02:51 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 20:02:52 all 0,13 0,00 0,13 0,00 0,63 30,43 0,00 0,00 68,69 20:02:52 0 0,00 0,00 1,01 0,00 0,00 27,27 0,00 0,00 71,72 20:02:52 1 0,00 0,00 0,00 0,00 1,02 29,59 0,00 0,00 69,39 20:02:52 2 0,00 0,00 0,00 0,00 1,01 31,31 0,00 0,00 67,68 20:02:52 3 0,00 0,00 0,00 0,00 1,01 31,31 0,00 0,00 67,68 20:02:52 4 0,00 0,00 0,00 0,00 1,01 29,29 0,00 0,00 69,70 20:02:52 5 0,00 0,00 0,00 0,00 0,00 34,02 0,00 0,00 65,98 20:02:52 6 0,00 0,00 0,00 0,00 1,00 31,00 0,00 0,00 68,00 20:02:52 7 0,00 0,00 0,00 0,00 0,00 29,59 0,00 0,00 70,41 20:02:52 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 20:02:53 all 0,00 0,00 0,13 0,00 0,76 29,33 0,00 0,00 69,79 20:02:53 0 0,00 0,00 0,00 0,00 1,01 27,27 0,00 0,00 71,72 20:02:53 1 0,00 0,00 0,00 0,00 0,00 27,55 0,00 0,00 72,45 20:02:53 2 0,00 0,00 0,00 0,00 1,02 31,63 0,00 0,00 67,35 20:02:53 3 0,00 0,00 0,00 0,00 1,01 30,30 0,00 0,00 68,69 20:02:53 4 0,00 0,00 0,00 0,00 0,00 28,57 0,00 0,00 71,43 20:02:53 5 0,00 0,00 0,00 0,00 1,00 32,00 0,00 0,00 67,00 20:02:53 6 0,00 0,00 0,00 0,00 1,01 28,28 0,00 0,00 70,71 20:02:53 7 0,00 0,00 0,00 0,00 1,00 29,00 0,00 0,00 70,00 20:02:53 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 20:02:54 all 0,13 0,00 0,00 0,00 0,63 29,76 0,00 0,00 69,48 20:02:54 0 1,01 0,00 0,00 0,00 0,00 29,29 0,00 0,00 69,70 20:02:54 1 0,00 0,00 0,00 0,00 1,00 30,00 0,00 0,00 69,00 20:02:54 2 0,00 0,00 0,00 0,00 0,00 30,30 0,00 0,00 69,70 20:02:54 3 0,00 0,00 0,00 0,00 1,01 30,30 0,00 0,00 68,69 20:02:54 4 0,00 0,00 0,00 0,00 1,01 28,28 0,00 0,00 70,71 20:02:54 5 0,00 0,00 0,00 0,00 0,00 33,33 0,00 0,00 66,67 20:02:54 6 0,00 0,00 0,00 0,00 0,00 28,57 0,00 0,00 71,43 20:02:54 7 0,00 0,00 0,00 0,00 1,02 28,57 0,00 0,00 70,41 20:02:54 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 20:02:55 all 0,00 0,00 0,13 0,00 0,63 29,55 0,00 0,00 69,70 20:02:55 0 0,00 0,00 1,01 0,00 1,01 29,29 0,00 0,00 68,69 20:02:55 1 0,00 0,00 0,00 0,00 1,00 28,00 0,00 0,00 71,00 20:02:55 2 0,00 0,00 0,00 0,00 1,01 27,27 0,00 0,00 71,72 20:02:55 3 0,00 0,00 0,00 0,00 1,01 32,32 0,00 0,00 66,67 20:02:55 4 0,00 0,00 0,00 0,00 1,00 31,00 0,00 0,00 68,00 20:02:55 5 0,00 0,00 0,00 0,00 1,00 32,00 0,00 0,00 67,00 20:02:55 6 0,00 0,00 0,00 0,00 1,00 26,00 0,00 0,00 73,00 20:02:55 7 0,00 0,00 0,00 0,00 0,00 30,30 0,00 0,00 69,70 ^C [root@router ~]# Linux 3.6.2-1.fc16.i686 06.11.2012 _i686_ (8 CPU) 15:33:56 CPU intr/s 15:33:58 all 33778,50 15:33:58 0 4000,00 15:33:58 1 3997,50 15:33:58 2 3999,00 15:33:58 3 4633,00 15:33:58 4 4629,00 15:33:58 5 4000,00 15:33:58 6 3995,00 15:33:58 7 3997,50 15:33:58 CPU intr/s 15:34:00 all 33641,50 15:34:00 0 3997,50 15:34:00 1 3998,00 15:34:00 2 3997,50 15:34:00 3 4622,00 15:34:00 4 4648,50 15:34:00 5 3999,50 15:34:00 6 3995,50 15:34:00 7 3995,50 15:34:00 CPU intr/s 15:34:02 all 33674,50 15:34:02 0 4001,00 15:34:02 1 3996,50 15:34:02 2 3997,50 15:34:02 3 4647,00 15:34:02 4 4654,00 15:34:02 5 3999,00 15:34:02 6 3996,00 15:34:02 7 3997,50 Samples: 17K of event 'cycles', Event count (approx.): 1618677353 7,94% [kernel] [k] ipt_do_table 7,58% [kernel] [k] fib_table_lookup 5,53% [igb] [k] igb_poll 3,90% [kernel] [k] _raw_spin_lock 2,11% [igb] [k] igb_xmit_frame_ring 2,05% [sch_htb] [k] htb_dequeue 2,03% [kernel] [k] dev_queue_xmit 2,01% [cls_u32] [k] u32_classify 2,00% [kernel] [k] nf_iterate 1,46% [kernel] [k] __netif_receive_skb 1,22% [kernel] [k] build_skb 1,20% [kernel] [k] ip_route_input_noref 1,14% [kernel] [k] __slab_free 1,12% [kernel] [k] local_bh_enable 1,09% [ip_set_hash_net] [k] hash_net4_test 1,07% [kernel] [k] check_leaf 1,00% [kernel] [k] __slab_alloc.constprop.23 0,94% [kernel] [k] dev_hard_start_xmit 0,88% [kernel] [k] ip_forward 0,85% [kernel] [k] ip_rcv 0,84% [kernel] [k] inet_gro_receive 0,81% [kernel] [k] ip_finish_output 0,80% [kernel] [k] put_page 0,80% [kernel] [k] dev_gro_receive 0,78% [kernel] [k] ip_rcv_finish 0,77% [ip_set] [k] ip_set_test 0,74% perf [.] 0x0004bb19 0,70% [kernel] [k] kmem_cache_alloc 0,68% [kernel] [k] netif_skb_features 0,68% [igb] [k] igb_alloc_rx_buffers 0,68% [kernel] [k] harmonize_features 0,66% [kernel] [k] tcp_gro_receive 0,64% [kernel] [k] vlan_do_receive 0,60% [kernel] [k] ip_forward_finish 0,60% [iptable_mangle] [k] iptable_mangle_hook 0,59% [kernel] [k] __netdev_alloc_frag 0,58% [kernel] [k] _raw_read_lock_bh 0,58% [bonding] [k] bond_start_xmit 0,57% [kernel] [k] _raw_read_lock 0,56% [kernel] [k] napi_gro_receive 0,54% [kernel] [k] nommu_map_page 0,53% [kernel] [k] check_addr 0,53% [bonding] [k] bond_handle_frame 0,51% [bonding] [k] bond_3ad_xmit_xor 0,50% [nf_conntrack_ipv4] [k] ipv4_helper 0,48% [kernel] [k] skb_release_head_state 0,48% [kernel] [k] local_bh_disable 0,47% [kernel] [k] native_sched_clock 0,47% [bonding] [k] bond_xmit_hash_policy_l34 0,47% [iptable_raw] [k] iptable_raw_hook 0,47% [kernel] [k] nf_hook_slow 0,47% [kernel] [k] irq_entries_start 0,46% [kernel] [k] ktime_get 0,45% [kernel] [k] page_address 0,45% [kernel] [k] __list_del_entry 0,44% [sch_htb] [k] htb_enqueue 0,44% [nf_conntrack] [k] nf_conntrack_in 0,43% [kernel] [k] get_page_from_freelist 0,42% [iptable_nat] [k] nf_nat_in 0,41% [kernel] [k] add_interrupt_randomness 0,41% [kernel] [k] lookup_page_cgroup_used 0,41% [kernel] [k] qdisc_dequeue_head 0,40% [kernel] [k] skb_free_head 0,40% [kernel] [k] read_tsc 0,40% [kernel] [k] account_system_vtime 0,40% [kernel] [k] skb_release_data 0,38% [kernel] [k] iptable_filter_hook Press '?' for help on key bindings растолкуйте _raw_spin_lock - как я понял, это некая блокировка, скорее всего карты очередями толкаются и возможно за прерывания дерутся? После включения шейпера эта блокировка вырастает процентов на 10 в perf top. на всех сетевых картах: ethtool -G eth0 rx 4096 tx 4096 ethtool -G eth1 rx 4096 tx 4096 ethtool -G p2p1 rx 4096 tx 4096 ethtool -G p3p1 rx 4096 tx 4096 ethtool -G p3p2 rx 4096 tx 4096 ethtool -G p4p1 rx 4096 tx 4096 ethtool -C eth1 rx-usecs 1000 ethtool -C p2p1 rx-usecs 1000 ethtool -C p3p1 rx-usecs 1000 ethtool -C p3p2 rx-usecs 1000 ethtool -C p4p1 rx-usecs 1000 подбирал опытным путем, по умолчанию выставлено 3, что означает динамический консервативный режим, который выставлял мне до 300 тыс. прерываний в сек. что не есть гуд. Драйвер ядреный, igb от Intel скомпилил, но пока еще не применял - не удобно регулировать и подбирать значение ITR на лету, на работающем канале, через rmmod и modprobe. gro, tso - что выключено, что включено, особой роли не играет. на данный момент оставил включенными. ifconfig eth0 txqueuelen 10000 ifconfig eth1 txqueuelen 10000 ifconfig p2p1 txqueuelen 10000 ifconfig p3p1 txqueuelen 10000 ifconfig p3p2 txqueuelen 10000 ifconfig p4p1 txqueuelen 10000 По всем очередям/буферам, как аппаратным, так и программым перестраховался по максимуму, не знаю, может не прав, буду признателен, если укажете на ошибочность принятого мной решения. Находил здесь расхожие мнения на этот счет. То же самое про Hyper Threading, как я понял, некоторые считают, что это технология для роутинга никак не помогает, даже мало того, мешает, вымывая кеш процессора. Стоит ли оставить только 4 ядра, и по 4 очереди на сетевых картах? Правильно ли будет разделять Tx и Rx на две раздельных очереди и каждую вешать на свое прерывание или стоит их объединить? Нужно ли rx с одного интерфейса группировать с tx другого интерфейса на одном ядре процессора? Или достаточно их развести на разные ядра? До oprofile пока еще не дошел. Что касается iptables: Выключаю conntrack для своих сеток Таблица raw -A PREROUTING -s 191.21.12.0/22 -j NOTRACK -A PREROUTING -d 191.21.12.0/22 -j NOTRACK -A PREROUTING -s 146.11.40.0/21 -j NOTRACK -A PREROUTING -d 146.11.40.0/21 -j NOTRACK -A OUTPUT -s 191.21.12.0/22 -j NOTRACK -A OUTPUT -d 191.21.12.0/22 -j NOTRACK -A OUTPUT -s 146.11.40.0/21 -j NOTRACK -A OUTPUT -d 146.11.40.0/21 -j NOTRACK В INPUT набор stateless правил, что-бы ограничить доступ к роутеру. В FORWARD дроп фейковых адресов и счетчики для интересующих меня адресов. - возможно это тоже здесь лишнее и даже простой count приводит к проблемам ? -A FORWARD -s 192.168.0.0/16 -j DROP -A FORWARD -d 192.168.0.0/16 -j DROP -A FORWARD -d 191.21.12.248/29 -j customer1 -A FORWARD -s 191.21.12.248/29 -j customer1 -A FORWARD -d 191.21.12.45/32 -j customer2 -A FORWARD -s 191.21.12.45/32 -j customer2 -A FORWARD -d 191.21.12.240/29 -j customer3 -A FORWARD -s 191.21.12.240/29 -j customer3 -A FORWARD -d 146.11.40.248/29 -j customer4 -A FORWARD -s 146.11.40.248/29 -j customer4 -A FORWARD -d 146.11.40.240/29 -j customer5 -A FORWARD -s 146.11.40.240/29 -j customer5 -A FORWARD -d 146.11.40.224/30 -j customer6 -A FORWARD -s 146.11.40.224/30 -j customer6 -A FORWARD -d 146.11.40.232/30 -j customer7 -A FORWARD -s 146.11.40.232/30 -j customer7 -A FORWARD -d 146.11.40.228/30 -j customer8 -A FORWARD -s 146.11.40.228/30 -j customer8 -A FORWARD -d 146.11.40.220/30 -j customer9 -A FORWARD -s 146.11.40.220/30 -j customer9 -A FORWARD -d 146.11.40.208/30 -j customer10 -A FORWARD -s 146.11.40.208/30 -j customer10 Пробовал правила сбрасывать - разницы особой не заметил, что с правилами,что без ... Пока склоняюсь к мысли, что я подошел к верхней планке возможностей, и на скоростях выше полутора гигабит нужно забыть об использовании шейпера, и делать видимо это уже нужно не на транзитном роутере. Особенно, если ожидается раширение bond-ов, например раза в 2, пока не произойдет переход на 10G. А когда это произойдет, то в этом случае мне кажется тем более можно забыть про шейпер на PC-платформе. Или я ошибаюсь? Как может влиять bonding на сетевую производительность? Вижу выход в том, что можно увести всех небольших потребителей трафика на другой роутер, на котором собственно и строить шейпер для них. А этот роутер оставить в покое - только перекачка суммарного трафика всей сети с интерфейса в интерфейс. Прошу поделиться опытом, привести примеры, кто сколько прокачивает с включенным шейпером и какие у вас при этом настройки.
  4. accel pptpd

    Доброго времени суток! Долгое время боролся с проблемой внезапных падений accel-pppd на ровном месте в процессе эксплуатации, высылал сюда и на сайт проекта bug-report-ы с корками. http://forum.nag.ru/forum/index.php?showtopic=45266&view=findpost&p=690580 http://forum.nag.ru/forum/index.php?showtopic=45266&view=findpost&p=737560 Автор несколько раз пытался помочь, в результате в конфиг попала такая опция в секции [core] stack-size= для попытки отрегулировать объем стека рабочего процесса — было подозрение на утечку памяти. Увеличив объем в 10 раз от стандартного 1 Мбайта и проведя наблюдение в течении двух недель я не добился серьезных изменений. Нет, конечно падать стало реже, раз-два в сутки, но я точно не знаю, помогло ли именно это, или это было просто стечение обстоятельств. На мой взгляд, если бы дело было все-таки в утечке памяти, то эта проблема должна была бы проявляться гораздо реже, т.е. Должна была бы прослеживаться линейная зависимость между увеличением объема stack-size и временем работы без сбоев. Этой зависимости не наблюдалось. В общем решил я сам немного поковыряться во внутренностях coredump-ов. Делал в первый раз, прошу не судить строго )) Дальнейшие изыскания я прикрепляю в файле к этому посту. Версия accel-pppd: 1.7.2 скомпилено с Debug OS: Fedora 17 32-bit PAE Linux-ядро: 3.5.3-1.fc17.i686.PAE на двух других серверах: Версия accel-pppd: 1.7.2 скомпилено с Debug OS: Fedora 16 32-bit Linux-ядро: 3.2.7-1.fc16.i686 core.5805.gz - сбой при сбросе юзера через snmp core.13212.gz - сбой при выполнении команды через телнет Вывод: имеется серьезная ошибка в процедуре сброса пользователя по логину terminate match username test1 hard и ее аналоге в snmp-реализации, приводящая к аварийному завершению процесса accel-pppd. После того, как я отказался от использования snmp и сбрасываю юзера по ip или по интерфейсу через telnet, я вот уже как за 10 дней наблюдения забыл про сбои процесса accel-pppd и теперь мои клиенты довольны. :) Прошу уважаемого xeb-а обратить внимание на мои скромные изыскания )) accel-отчет-об-ошибке.txt accel-отчет-об-ошибке.pdf core.5805.gz core.13212.gz
  5. accel pptpd

    commit 994905a05a6388cb9e832e09c05bb6a363c73ecc Author: Kozlov Dmitry <xeb@mail.ru> Date: Mon Jul 30 23:19:36 2012 +0400 make worker stack size configurable [core] stack-size=1048576 по умолчанию 1048576 Спасибо! Буду тестить - результат напишу!
  6. accel pptpd

    Несколько месяцев назад я писал о проблеме на Fedora 16 (ядро версии 3.2.7-1.fc16.i686) с периодическими segfault случайно, два три раза в сутки. После этого уважаемый xeb в одной из следующих версий увеличил размер стека и это вроде-бы как помогло, с частотой падений - стало реже, но все-же осталось. Сейчас на серваке крутится accel-ppp version 1.7.0, надежда на решение проблемы путем смены версий с прошлой 1.4.0 до 1.7.0 не оправдалась. Как вариант хочу сменить основу - заменить fedora 16 на 17, как следствие сменится ядро на 3.4.x и версии либ посвежее станут - может поможет ... Сейчас ситуация у меня следующая - каждую ночь в 3:00 я ребучу тестовый сервак, т.к. кроме проблемы с segfault, есть другая проблема, не связанная с accel (при постоянной работе на 2-3 сутки softirq съедает все время CPU и ничего кроме ребута не помогает, насколько я понял, это проблема железа и драйвера для него, сетевка Intel, но не шибко модная, здесь в других ветках когда-то обсуждалось ...) В общем теперь, с учетом, что каждые сутки сервак стартует с нуля, за 24 часа segfault может не вылететь ни разу, и так может продолжаться и два и три дня подряд, и даже изредка до недели, а может каждый день вылет по segfault происходить. Может сделать еще раз 10 :) core: increase stack size - мне памяти не жалко, все равно ее основная часть курит на серваках ... Или сделать этот параметр настраиваемым в каких-то пределах через конфиг, что-бы подобрать этот объем стека опытным путем ?!? ... Конечно, если память течет, то все равно рано или поздно segfault-нется, но в моем случае лучше позже ... :) Правда, доп. увеличение объема стека может не помочь, потому как я не знаю, сколько accel его хочет в эти моменты, а т.к. проблема проявляется не четко, сложно поймать зависимость, от чего это происходит ... debug.log:Jul 21 00:13:16 nas2 kernel: [65563.522638] accel-pppd[32256]: segfault at ccb002 ip 00b85c09 sp b47fc180 error 4 in libcrypto.so.1.0.0g[b41000+173000] http://dl.dropbox.com/u/9391376/core.5090.tgz debug.log:Jul 27 14:03:36 nas2 kernel: [28983.057607] accel-pppd[25880]: segfault at 4ce008 ip 0025dc09 sp af3fd180 error 4 in libcrypto.so.1.0.0g[219000+173000] http://dl.dropbox.com/u/9391376/core.5098.tgz debug.log:Jul 29 06:02:04 nas2 kernel: [ 91.461150] accel-pppd[6679]: segfault at 3d9003 ip 00154c09 sp b05fe180 error 4 in libcrypto.so.1.0.0g[110000+173000] http://dl.dropbox.com/u/9391376/core.5073.tgz http://dl.dropbox.com/u/9391376/core.5069.tgz http://dl.dropbox.com/u/9391376/core.5099.tgz http://dl.dropbox.com/u/9391376/core.5091.tgz
  7. accel pptpd

    Fedora 16, accel-pppd 1.5.0 Использую pptp+l2tp+pppoe, нагрузка на этот сервер до 400 сессий. К сожалению наблюдаю такую же картину, частота ~ до 4-х раз в сутки, периодика - практически рандомная, но обычно не менее нескольких часов между падениями. [root@nas2 tmp]# uname -r 3.2.7-1.fc16.i686 Компилил accel с Debug. Feb 22 12:03:51 nas2 kernel: [32597.437726] accel-pppd[5486]: segfault at 658003 ip 0032cc09 sp b40fb180 error 4 in libcrypto.so.1.0.0f[2e8000+173000] Feb 22 15:15:44 nas2 kernel: [44110.300208] accel-pppd[31640]: segfault at 621005 ip 00253c09 sp b19fd180 error 4 in libcrypto.so.1.0.0f[20f000+173000] обновил openssl - это не помогло Feb 23 11:21:23 nas2 kernel: [ 1452.497321] accel-pppd[12610]: segfault at 486008 ip 00320c09 sp b04fe180 error 4 in libcrypto.so.1.0.0g[2dc000+173000] Feb 23 13:22:12 nas2 kernel: [ 8701.190502] accel-pppd[9354]: segfault at be5008 ip 00a9ac09 sp b48fc180 error 4 in libcrypto.so.1.0.0g[a56000+173000] Корки лежат здесь: http://dl.dropbox.com/u/54248745/coredumps2.tgz Ссылки по теме: http://sourceforge.net/tracker/?func=detail&aid=3480127&group_id=390718&atid=1622576 http://sourceforge.net/tracker/?func=detail&aid=3486590&group_id=390718&atid=1622576 http://forum.nag.ru/forum/index.php?showtopic=45266&view=findpost&p=685881
  8. accel pptpd

    После недели относительно стабильной работы проблемы вернулись https://sourceforge.net/tracker/?func=detail&aid=3486590&group_id=390718&atid=1622576 версия accel-ppp 1.5.0 P.S. Есть версия, которую я пока еще не подтвердил, что падение случается во время возникновения колец/флуда в некоторых сегментах/vlan-ах сети, где побороть эту проблему пока не получается по разным причинам (старое оборудование и т.д.) ... По крайней мере, как мне показалось, сегодня вырисовалась связь. Буду на днях проверять. P.P.S. Можно ли добавить меняемый на лету и определяемый в конфиге параметр и функционал в программу, ограничивающий максимальное количество подключенных клиентов. Причина: пока еще не унифицировано полностью железо (имеется разное железо с разными возможностями), один роутер может вытянуть до тысячи коннектов а некоторым после 400 плохо становится. Если бы можно было бы настроить так, что бы когда сервер набрал количество коннектов до указанного лимита, он перестал принимать новые входящие соединения, при отключении их/снижении количества ниже указанного порога, он снова начинает их принимать.
  9. accel pptpd

    Xeb, хотел сказать большое спасибо за титанический труд! Есть несколько вопросов. Развернул на Fedora 16, Linux 3.1.9-1.fc16.i686 #1 SMP Fri Jan 13 17:14:41 UTC 2012 i686 i686 i386 GNU/Linux, Accel-ppp 1.5 Раз-два в сутки выхватываю Jan 26 07:25:52 nas2 kernel: [537700.722178] accel-pppd[16273]: segfault at 4c6006 ip 00154c09 sp b00fc200 error 4 in libcrypto.so.1.0.0f[110000+173000] Jan 26 18:37:00 nas2 kernel: [577969.266853] accel-pppd[13615]: segfault at 378007 ip 00168c09 sp b65fe200 error 4 in libcrypto.so.1.0.0f[124000+173000] Сервак тестовый, максимальная нагрузка около 200 человек. Использую все три способа одновременно. /etc/accel-ppp.conf [modules] #path=/usr/lib/accel-ppp log_file #log_tcp #log_pgsql pptp pppoe l2tp auth_mschap_v2 auth_mschap_v1 auth_chap_md5 auth_pap radius #ippool sigchld pppd_compat #shaper_tbf #chap-secrets net-snmp #ipv6_nd #ipv6_dhcp [core] log-error=/var/log/accel-ppp/core.log thread-count=4 [ppp] verbose=1 #min-mtu=1280 min-mtu=1400 mtu=1400 mru=1400 #ccp=0 ccp=0 #sid-case=upper #check-ip=0 #single-session=replace #mppe=require ipv4=require ipv6=deny ipv6-intf-id=0:0:0:1 ipv6-peer-intf-id=0:0:0:2 ipv6-accept-peer-intf-id=1 [lcp] echo-interval=30 echo-failure=3 [auth] #any-login=0 #noauth=0 [pptp] echo-interval=30 verbose=1 [pppoe] interface=vlan11 ................................ interface=vlan360 #ac-name=xxx #service-name=yyy #pado-delay=0 #pado-delay=0,100:100,200:200,-1:500 #ifname-in-sid=called-sid #tr101=1 verbose=1 [l2tp] dictionary=/usr/share/accel-ppp/l2tp/dictionary hello-interval=60 timeout=60 rtimeout=5 retransmit=5 host-name=accel-ppp dir300_quirk=0 verbose=1 [dns] dns1=xxx.xxx.xxx.xxx dns2=xxx.xxx.xxx.xxx [radius] dictionary=/usr/share/accel-ppp/radius/dictionary nas-identifier=nas2 nas-ip-address=xxx.xxx.xxx.xxx gw-ip-address=xxx.xxx.xxx.xxx #auth-server=127.0.0.1:1812,testing123 (obsolete) #acct-server=127.0.0.1:1813,testing123 (obsolete) server=xxx.xxx.xxx.xxx,password #dae-server=127.0.0.1:3799,testing123 verbose=1 #timeout=3 max-try=3 acct-timeout=120 #acct-delay-time=0 [client-ip-range] 192.168.0.0/16 [ip-pool] gw-ip-address=192.168.0.1 192.168.0.2-255 192.168.1.1-255 192.168.2.1-255 192.168.3.1-255 192.168.4.0/24 [log] log-file=/var/log/accel-ppp/accel-ppp.log log-emerg=/var/log/accel-ppp/emerg.log log-fail-file=/var/log/accel-ppp/auth-fail.log #log-debug=/dev/stdout #log-tcp=127.0.0.1:3000 copy=1 #color=1 #per-user-dir=per_user #per-session-dir=per_session #per-session=1 level=3 #log-tcp=127.0.0.1:3000 [log-pgsql] conninfo=user=log log-table=log [pppd-compat] #ip-pre-up=/etc/ppp/ip-pre-up ip-up=/etc/ppp/ip-up ip-down=/etc/ppp/ip-down ip-change=/etc/ppp/ip-change radattr-prefix=/var/run/radattr verbose=1 [chap-secrets] gw-ip-address=xxx.xxx.xxx.xxx #chap-secrets=/etc/ppp/chap-secrets [tbf] #attr=Filter-Id #down-burst-factor=0.1 #up-burst-factor=1.0 #latency=50 [cli] telnet=127.0.0.1:2000 tcp=127.0.0.1:2001 #password=123 [snmp] master=0 agent-name=accel-ppp [ipv6-pool] fc00:0:1::/48,64 delegate=fc00:1::/36,48 [ipv6-dns] #fc00:1::1 #fc00:1::2 #fc00:1::3 #dnssl=suffix1.local.net #dnssl=suffix2.local.net. [ipv6-dhcp] verbose=1 pref-lifetime=604800 valid-lifetime=2592000 route-via-gw=1 Дампы попробую словить и выложить в след. раз. Отписался еще здесь про эту проблему http://sourceforge.net/tracker/?func=detail&aid=3480127&group_id=390718&atid=1622576 Хотел поинтересоваться - есть ли разница, если запускать accel-ppp сугубо под что-то одно: PPTP, L2TP или PPPoE ? Или в принципе работа сразу с тремя протоколами уже может считаться стабильной ? P.S. Еще один момент, о котором хотелось упомянуть - работа с SNMP (запрос кто сейчас подключен) вызывает высокую нагрузку (90-100%) одного из ядер CPU на сервере процессом accel-pppd на время отработки запроса, что как мне кажется может негативно сказаться на работе софт-роутера в целом. У меня достаточно часто происходит опрос на серверах доступа кто онлайн. Переделал в своих скриптах опрос таблицы клиентов на telnet - такой метод не грузит вообще - ~1%. P.P.S. connlimit - это доступно в git версии, не в 1.5 ?
  10. Судя по результатам моего тестирования, уважаемый replicant, Вы правы !!! За что вам большущее спасибо !!! )) Кстати а у e1000e GRO отключено по умолчанию, хотя я тоже думаю, что это обусловлено возможностями чипа.
  11. На моих системах эти опции есть, как для ядра 2.6.34.7 (ethtool version 2.6.33-pre1) так и для 2.6.35.6 (ethtool version 2.6.34) Завтра проведу тесты, посмотрим что получится. Это решение справедливо для случая igb + igb и использования двухголовой карты ?
  12. Я даже разные мат. платы вообще пробовал на разных чипсетах и везде одно и то же. Не думаю что дело в БИОС. Сделаю вывод чуть погодя и выложу, но ведь без шейпера работает, а логически в железяке и в выводе lspci от наличия / отсутствия шейпера вообще ничего не меняется. Какие-то подсистемы ядра 2.6.35.8 работают не так как на старых ядрах и это проявляется именно в комбинации tc + igb. У меня есть еще мнение, что accel-pptp 0.8.5 не стыкуется с ядром 2.6.35.8, потому что шейпер нарезает на ppp интерфейсах. Но 0.8.5 версия работает на этом ядре в комбинации с другой сетевой картой и это вновь меня ставит в тупик. Просто переключаю внешний интерфейс на другую сетевую находу и работает как доктор прописал. Поэтому я обращаюсь к всем, кто может подтвердить или опровергнуть наличие проблем в такой комбинации tc + igb + kernel 2.6.35.7 или 8, где igb внешний и внутренний интерфейсы, а сервер работает под accel-pptp. Готов даже выложить конфиг ядра, но думаю что смысла в этом нет, потому что не работает уже сразу после установки, а это умолчальный конфиг. Кто может помочь в моделировании у себя подобной связки ПО + железо? Нужно смоделировать чистую систему slackware 13.1 (обновиться до current по желанию) + ядро 2.6.35.7 + pptpd + минимальный шейпер на tbf или htb (можно даже взять код шейпера из темы по ссылке в первом посте). Просто поднять snat или dnat, ip_forward и интерфейс ppp0 и прогнать несколько тестов на разных rate. Подтверждаю наличие проблемы. Проблема есть у меня и на ядре 2.6.34.7, хотя на других сетевых картах и драйвере e1000e подобных проблем нет. Сегодня наконец приехали несколько сетевых карт - поставил на тестовый сервак, ввел в работу и огреб по полной :( Потестить подольше пока не получилось, но первое впечатление - не работает tbf, причем в этом случае vpn-соединение работет не на максимально-возможной скорости (как если-бы он не был-бы установлен на ppp-интерфейс) а на минимальной - 128 кБит или около того ... Попробовал ваши рецепты, но никакого эффекта. Железо: серверная мама от Intel - S3420GP проц: Intel® Xeon® CPU X3440 @ 2.53GHz On-board сетевки, с которыми нет проблем, драйвер e1000e (ITR=100000): 1-я Intel 82578DM Gigabit Network Connection 2-я Intel 82574L Gigabit Network Connection Софт: Fedora 14, использую дефолтное ядро 2.6.35.6, accel-pptp-0.8.4, шейпер tbf на каждый ppp-интерфейс, нарезка скорости различная, от 1-2Мбит-а до 10-50Мбит Сетевые, что пытался поставить: Intel E1G42ET (Чип, Intel Corporation 82576 Gigabit Network Connection) driver=igb driverversion=2.1.0-k2 куцый какой-то на опции, ни ITR нет, ни других ... До детального разбора полетов все вернул назад ... Обидно однако ... :(
  13. Доброго времени суток ! Использует ли кто-нибудь в своем хозяйстве коммутаторы Dell ? Кое какие фрагментарные отзывы я нашел здесь, но хотелось бы немного детальнее узнать. Конкретно интересуют модели: Dell PowerConnect 6024F - что умеет vlan-ы, и создавать и роутить интерфейсы это понятно. Какое их кол-во тянет ? С каким трафиком нормально справляется ? Как обстоят дела с мультикастом, то что поддержка IGMP v.2 есть я знаю, но умеет ли он аналог MVR (Cisco) или ISM (D-Link)? Сколько может ACL и какие есть ограничения ? Построен он как я понял на чипах Marvell, нет ли в связи с этим "пасхальных" яиц по типу проблем с хешем, vlan и MAC-ами ? Часть этой информации я так и не нашел непосредственно у Dell-а, разве что это http://support.dell.com/support/edocs/netw...gur.htm#1136535 Ну и плюс интересует инфа по этим моделям Dell 3424 Dell 3324 Dell 3024 Если бы у Вас был выбор, покупать б/у Dell или Extreme, 3Com или новые D-Link (3200-26,3200-28,3100-24,3612G,3627G), что-бы Вы предпочли ? Понятно, что в случае с б/у дешевле, но иногда этот выбор потом обходится себе дороже, если потом выясняется, что это железо в силу своей не первой свежести не умеет/тянет по определенным параметрам, часть из которых я перечислил выше ... Ну и естественно, отсутствие техподдержки, т.к. обычно все б/у уже EOL