И снова к вопросу о BRAS на FreeBSD

Dyr · October 18, 2010

Приветствую уважаемую публику.

Была старая тема про правильную настройку серверов FreeBSD, шейпирующих и NAT'ящих абонентов, но сходу её не нашёл, поэтому открываю новую.

Имею проблему с таким сервером.

Итак, сервер FreeBSD 7.3-STABLE i386 с pf(NAT), ipfw(ACL) и dummynet (shaping).

Пропускает порядка 1500 клиентов, трафик порядка 400-500 Мбит/сек (60kpps), количество сессий PF порядка 300 тысяч.

В течении года загрузка постепенно подобралась к LA 2-3 (на Core2Duo), поменял процессор на Core2Quad.

И настала жопа.

Загрузка не только не уменьшилась, она ещё больше возросла, начались задержки и потери пакетов.

Установка драйверов от Яндекса не помогла.

Игры настройками sysctl net.isr.direct 1/0, dev.em.X.int_delay; привязка cpuset'ом процессов dummynet и emX_xxx к определённым ядрам не приносят практически никакого значимого результата.

Немного помогает уборка следующих правил файервола из ipfw - потери и задержки пакетов уходят, хотя загрузка всё равно высокая:

03000  760849293  645265414446 pipe tablearg ip from any to table(4) xmit vlan3050 // Incoming traffic shaping
03000  802815983  576003644433 pipe tablearg ip from table(5) to any xmit em0 // Outgoing traffic shaping

В цифрах это будет вот так:

 
em0: Excessive collisions = 0
em0: Excessive collisions = 0
em0: Sequence errors = 0
em0: Sequence errors = 0
em0: Defer count = 0
em0: Defer count = 0
em0: Missed Packets = 24553
em0: Missed Packets = 24553
em0: Receive No Buffers = 4547
em0: Receive No Buffers = 4547
em0: Receive Length Errors = 0
em0: Receive Length Errors = 0
em0: Receive errors = 0
em0: Receive errors = 0
em0: Crc errors = 0
em0: Crc errors = 0
em0: Alignment errors = 0
em0: Alignment errors = 0
em0: Collision/Carrier extension errors = 0
em0: Collision/Carrier extension errors = 0
em0: watchdog timeouts = 0
em0: watchdog timeouts = 0
em0: XON Rcvd = 0
em0: XON Rcvd = 0
em0: XON Xmtd = 0
em0: XON Xmtd = 0
em0: XOFF Rcvd = 0
em0: XOFF Rcvd = 0
em0: XOFF Xmtd = 0
em0: XOFF Xmtd = 0
em0: Good Packets Rcvd = 10419220831
em0: Good Packets Rcvd = 10419220831
em0: Good Packets Xmtd = 9848872653
em0: Good Packets Xmtd = 9848872653
em0: TSO Contexts Xmtd = 7362
em0: TSO Contexts Xmtd = 7362
em0: TSO Contexts Failed = 0
em0: TSO Contexts Failed = 0

root@Bastinda:/root/nasscripts (344) netstat -i -I em0 -dh 1
            input          (em0)           output
   packets  errs      bytes    packets  errs      bytes colls drops
       60K     0        61M        43K     0        21M     0     0
       61K     0        60M        44K     0        22M     0     0
       60K     0        59M        44K     0        22M     0     0
       60K     0        60M        43K     0        22M     0     0
       49K     0        47M        36K     0        19M     0     0
       56K  1.8K        54M        42K     0        23M     0     0
       54K     0        54M        39K     0        19M     0     0
       55K     0        53M        40K     0        21M     0     0
       55K     0        55M        40K     0        20M     0     0
       54K     0        52M        40K     0        20M     0     0
       56K     1        55M        40K     0        20M     0     0
       56K     0        55M        41K     0        21M     0     0
       57K     0        56M        41K     0        21M     0     0
       57K     0        57M        41K     0        21M     0     0
       59K     0        59M        43K     0        22M     0     0
       61K     0        62M        44K     0        22M     0     0

root@Bastinda:/root/nasscripts (399) netstat -i -dh 1
            input        (Total)           output
   packets  errs      bytes    packets  errs      bytes colls drops
      146K     0       109M       146K     0       132M     0     0
      147K     0       110M       145K     0       129M     0     0
      147K     0       111M       146K     0       127M     0     0
      142K     0       108M       140K     0       124M     0     0
      140K     0       106M       137K     0       118M     0     0
      145K     0       112M       141K     0       125M     0     0
      141K     0       107M       139K     0       121M     0     0
      143K     0       109M       139K     0       121M     0     0
      142K     0       107M       139K     0       120M     0     0
      135K     0       101M       133K     0       116M     0     0

Интересно, что удаление правил файервола, связанных с шейпером, процесс dummynet всё равно продолжает потреблять ресурсы процессора:

last pid: 80781;  load averages:  4.69,  4.85,  4.99                                              up 4+20:50:51  20:55:56
162 processes: 9 running, 135 sleeping, 18 waiting
CPU 0:  0.0% user,  0.0% nice, 86.1% system,  0.0% interrupt, 13.9% idle
CPU 1:  1.5% user,  0.0% nice, 88.6% system,  2.0% interrupt,  7.9% idle
CPU 2:  0.0% user,  0.0% nice, 81.3% system,  2.0% interrupt, 16.7% idle
CPU 3:  0.0% user,  0.0% nice, 78.9% system,  2.0% interrupt, 19.1% idle
Mem: 53M Active, 1355M Inact, 485M Wired, 29M Cache, 199M Buf, 79M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME      PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   25 root           43    -     0K     8K RUN     1  34.6H 92.58% [em0_rx0_0]
   26 root           43    -     0K     8K CPU1    0  34.6H 91.16% [em0_rx0_1]
   30 root           43    -     0K     8K CPU3    3  33.8H 68.80% [em1_rx0_1]
   29 root           43    -     0K     8K WAIT    2  33.8H 66.26% [em1_rx0_0]
    5 root            8    -     0K     8K RUN     0 784:55 21.39% [thread taskq]
   38 root          -68    -     0K     8K -       2  30.5H 17.38% [dummynet]
   11 root          171 ki31     0K     8K CPU2    2  63.3H 16.80% [idle: cpu2]
   10 root          171 ki31     0K     8K RUN     3  80.8H 16.16% [idle: cpu3]
   13 root          171 ki31     0K     8K RUN     0  59.8H  7.28% [idle: cpu0]
   12 root          171 ki31     0K     8K RUN     1  65.9H  6.05% [idle: cpu1]
   15 root          -32    -     0K     8K WAIT    3 157:18  2.10% [swi4: clock]
   27 root           16    -     0K     8K WAIT    3  76:39  1.56% [swi16: em1_tx]
   23 root           16    -     0K     8K WAIT    1  79:29  1.37% [swi16: em0_tx]
root@Bastinda:/root/nasscripts (342)

root@Bastinda:/root/nasscripts (343) sysctl net.isr
net.isr.swi_count: 53881
net.isr.drop: 0
net.isr.queued: 75222
net.isr.deferred: 0
net.isr.directed: 205468560
net.isr.count: 205468478
net.isr.direct: 1

    3 users    Load  4.76  4.74  4.78                  18 окт 21:14

Mem:KB    REAL            VIRTUAL                       VN PAGER   SWAP PAGER
        Tot   Share      Tot    Share    Free           in   out     in   out
Act   60360    5924   359628     7036  161668  count
All  388820    9176  4624800    18788          pages
Proc:                                                            Interrupts
  r   p   d   s   w   Csw  Trp  Sys  Int  Sof  Flt        cow    9093 total
          1 116      170k    4  169 1094 7866             zfod        atkbd0 1
                                                          ozfod       atapci1+ 1
95.2%Sys   0.7%Intr  0.0%User  0.0%Nice  4.0%Idle        %ozfod       skc0 irq24
|    |    |    |    |    |    |    |    |    |    |       daefr  1995 cpu0: time
================================================          prcfr   549 em0 irq256
                                        33 dtbuf          totfr   546 em1 irq257
Namei     Name-cache   Dir-cache    100000 desvn          react  1995 cpu1: time
   Calls    hits   %    hits   %     88426 numvn          pdwak  2004 cpu2: time
                                     25000 frevn          pdpgs  2004 cpu3: time
                                                          intrn
Disks   ad6                                        493080 wire
KB/t   0.00                                         56020 act
tps       0                                       1338324 inact
MB/s   0.00                                          6128 cache
%busy     0                                        155540 free

root@Bastinda:/root/nasscripts (397) netstat -m
8702/9733/18435 mbufs in use (current/cache/total)
8699/9695/18394/262144 mbuf clusters in use (current/cache/total/max)
8695/8841 mbuf+clusters out of packet secondary zone in use (current/cache)
0/178/178/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
0/347/347/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
19629K/25658K/45287K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/7/10240 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

grep -v ^# /etc/sysctl.conf | sort
dev.em.0.rx_abs_int_delay=1800
dev.em.0.rx_int_delay=900
dev.em.0.tx_abs_int_delay=1800
dev.em.0.tx_int_delay=900
dev.em.1.rx_abs_int_delay=1800
dev.em.1.rx_int_delay=900
dev.em.1.rx_kthreads=2
dev.em.1.rx_kthreads=2
dev.em.1.tx_abs_int_delay=1800
dev.em.1.tx_int_delay=900
kern.ipc.maxsockbuf=2097152
kern.ipc.nmbclusters=262144
kern.ipc.somaxconn=4096
kern.maxfiles=20480 # For PPP
kern.polling.user_frac=25
kern.timecounter.hardware=HPET
net.inet.carp.log=6
net.inet.carp.preempt=1
net.inet.ip.dummynet.expire=0
net.inet.ip.dummynet.hash_size=1024
net.inet.ip.dummynet.io_fast=1
net.inet.ip.fastforwarding=1
net.inet.ip.fw.one_pass=0
net.inet.ip.process_options=0
net.inet.ip.random_id=1
net.inet.ip.redirect=0
net.inet.ip.stealth=1
net.inet.tcp.delayed_ack=0
net.inet.tcp.drop_synfin=1
net.inet.tcp.recvspace=65228
net.inet.tcp.sendspace=65228
net.inet.tcp.syncookies=1
net.inet.udp.maxdgram=57344
net.inet.udp.recvspace=65228
net.link.ether.inet.log_arp_wrong_iface=0

Конфигурация шейперов (на примере):

# Login 1239282656, ID 20, Tariff 2, Bandwidth 1024 Kb/s, IP 10.54.3.8/29'
/sbin/ipfw -q pipe 20 config bw 1126Kb/s mask dst-ip 0xFFFFFFFF queue 100 gred 0.002/17/51/0.1 
/sbin/ipfw -q pipe 10020 config bw 1126Kb/s mask src-ip 0xFFFFFFFF queue 100 gred 0.002/17/51/0.1

root@Bastinda:/root/nasscripts (372) sysctl net.inet.ip.dummynet
net.inet.ip.dummynet.debug: 0
net.inet.ip.dummynet.pipe_byte_limit: 1048576
net.inet.ip.dummynet.pipe_slot_limit: 100
net.inet.ip.dummynet.io_pkt_drop: 8885604
net.inet.ip.dummynet.io_pkt_fast: 992352269
net.inet.ip.dummynet.io_pkt: 2310923696
net.inet.ip.dummynet.io_fast: 1
net.inet.ip.dummynet.tick_lost: 0
net.inet.ip.dummynet.tick_diff: 8941128
net.inet.ip.dummynet.tick_adjustment: 6792058
net.inet.ip.dummynet.tick_delta_sum: 314
net.inet.ip.dummynet.tick_delta: 0
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.max_chain_len: 16
net.inet.ip.dummynet.expire: 0
net.inet.ip.dummynet.search_steps: -1984046616
net.inet.ip.dummynet.searches: -1984043600
net.inet.ip.dummynet.extract_heap: 0
net.inet.ip.dummynet.ready_heap: 272
net.inet.ip.dummynet.hash_size: 1024

root@Bastinda:/root/nasscripts (361) grep -v ^# /boot/loader.conf | sort
autoboot_delay="1"
hw.em.rxd=4096
hw.em.txd=4096
ichsmb_load="YES"
if_sk_load="YES"
kern.ipc.nsfbufs=10240
net.inet.tcp.syncache.bucketlimit=100
net.inet.tcp.syncache.hashsize=1024
net.inet.tcp.tcbhashsize=16384    # Set the value of TCBHASHSIZE
vm.kmem_size=768M
vm.kmem_size_max=1G

em0@pci0:13:0:0:        class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (82573E)'
    class      = network
    subclass   = ethernet
em1@pci0:15:0:0:        class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Intel PRO/1000 PL Network Adaptor (82573L)'
    class      = network
    subclass   = ethernet

Что можно в данном случае сделать?

Edited October 18, 2010 by Dyr

Ivan_83 · October 18, 2010

Игры настройками sysctl net.isr.direct 1/0, dev.em.X.int_delay; привязка cpuset'ом процессов dummynet и emX_xxx к определённым ядрам не приносят практически никакого значимого результата.

Ядра не равнозначные.

4 ядра это просто два двух ядерных в одной упаковке да ещё и доп кеш общий.

Видимо получилось что частота ниже, и частые пенальти из за рассинхронизации кешей.

Ilya Evseev · October 18, 2010

Что можно в данном случае сделать?

Заменить процессор на c2d e8600.

Разнести шейпер и nat на разные серверы. Шейпер сделать мостом, для nat использовать linux.

Dyr · October 19, 2010

Шейпер на другой сервер и мостом вчера таки сделал, да. :)

Заметки на полях. Разработчики FreeBSD похоже, никогда сами не пробовали использовать описанные в handbook атрибуты rc.conf autobridge, поскольку они просто не работают нормально. Пришлось создание бриджей на вланах запихнуть в /etc/rc.local.

Попутно выяснилось, что при поднятом бридже и поднятых родительских интерфейсах вланов, сами дочерние влановские интерфейсы остаются в DOWN, соответственно чтобы bridge заработал, надо указывать ifconfig emX.YYYY up.

А ещё без передёргивания "ifconfig emX down && ifconfig emX up" после старта бриджа пинг будет минимум 2-3 мс, а через промежуточный коммутатор и 5-6. Стоит передёрнуть, и пинг возвращается в нормальные 1мс. Чудеса, блин.

С различными вариантами шедулеров на 8 ветке не игрался? Особенно с QFQ?

Чем NAT на Linux лучше NAT'a на FreeBSD?

Edited October 19, 2010 by Dyr

Dyr · October 19, 2010

Игры настройками sysctl net.isr.direct 1/0, dev.em.X.int_delay; привязка cpuset'ом процессов dummynet и emX_xxx к определённым ядрам не приносят практически никакого значимого результата.
 Ядра не равнозначные.4 ядра это просто два двух ядерных в одной упаковке да ещё и доп кеш общий.Видимо получилось что частота ниже, и частые пенальти из за рассинхронизации кешей.

Так непонятно, почему тогда производительность не остаётся на прежнем уровне, если ВСЕ системные процессы привязать к, например, ядрам 0,1.

P.S. Процы такие.

А может, кто-то уже пробовал и конфигурацию на других процессорах - Core i5 всяких, Ксеонах?

Edited October 19, 2010 by Dyr

Ivan_83 · October 19, 2010

if_bridge мне категорически не нравится, он выглядит как огромный мегакостыль.

Я бы вообще его из системы выкорчевал нафик.

Есть ng_switch который решает эту же проблему, будучи подцепленным к ether lower/upper хукам на каждой сетевухе.

При этом всё динамически конфигурится и никаких кучи доп проверок в ядре нет.

Частота походу ниже, чем у исходного проца.

И далеко не факт что 0 и 1 это ядра с общим l2 кешем.

Возможно дефекты самого проца.

Dyr · October 19, 2010

Ivan_83, а вы бы не могли пояснить по if_bridge и его отличие от ng_bridge (а теперь ещё и ng_switch :))?

Про ng_switch man вообще не знает, а про ng_bridge говорит, что ipfw с ним работать "поинтерфейсно" не умеет:

IPFW PROCESSING
Processing of IP packets via the ipfirewall(4) mechanism on a per-link

basis is not yet implemented.

Сейчас посмотрел внимательнее на использовавшиеся процессоры, вы правы - частота была выше, да и кеша на два ядра аж 3 Мбайта.

Edited October 19, 2010 by Dyr

Ilya Evseev · October 19, 2010

Чем NAT на Linux лучше NAT'a на FreeBSD?

Производительностью и простотой.

Единственный параметр, который пришлось поправить, чтобы получить 900mbps на E4700+bge - размер таблицы трансляций.

Dyr · October 19, 2010

Простотой? Приведи, пожалуйста, пример NAT'a сетки в сетку.

Во FreeBSD с помощью PF это (и binat) выглядит так:

pfctl -sn

nat on em0 from <allow-nat> to any -> <dst_nat1> round-robin sticky-address static-port
nat on em0 inet from 10.78.78.0/24 to any -> 93.92.199.248/29 source-hash 0xe7b94f63863d9907f0f759bb0eaa7595 static-port
binat-anchor "binat" all
binat on em0 inet from 10.78.78.2 to any -> 93.92.199.252

Куда ж проще-то?

С бОльшей производительностью тоже интересно. Ты же, надеюсь, сравниваешь производительность не бывшего NAS2 с шейперами и NAT'ом, на котором после переезда на Linux остался только NAT?

P.S. Мегабиты при NAT'е не показательны, гораздо лучше его характеризует количество сессий и pps.

Edited October 19, 2010 by Dyr

Ilya Evseev · October 19, 2010

Простотой? Приведи, пожалуйста, пример NAT'a сетки в сетку.

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j NETMAP --to 10.20.30.0/24

Dyr · October 19, 2010

Простотой? Приведи, пожалуйста, пример NAT'a сетки в сетку.
 iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j NETMAP --to 10.20.30.0/24

Строго говоря, здесь то, что в PF называется binat, то есть строго адрес в адрес для всей сетки.

Ivan_83 · October 19, 2010

Ivan_83, а вы бы не могли пояснить по if_bridge и его отличие от ng_bridge (а теперь ещё и ng_switch :))?
Про ng_switch man вообще не знает, а про ng_bridge говорит, что ipfw с ним работать "поинтерфейсно" не умеет:

ng_bridge - конечно же.

свич это я перепутал по принципу работы самого бриджа в стравнении с ng_hub да ещё название заметки:

http://www.lissyara.su/articles/freebsd/tuning/ng_bridge/

Теоретически можно попробовать lower хуки с ether интерфейсов в ipfw завести, примерно как тут показано

http://habrahabr.ru/blogs/bsdelniki/88022/#habracut

при этом не забыть выставить промиск и автосрц как статье по ссылке выше

Dyr · October 19, 2010

Есть у меня мысль, что если не нужно STP, то наверное можно было бы обойтись и без ng_bridge, оставив только ng_ether и ng_vlan с ng_ipfw.

Edited October 19, 2010 by Dyr

stalex · November 10, 2010

для теста можете отключить шейпинг, должна увеличится пропусканая способность до 1Г.

а при шейпенге одно ядно в вашем пике 500Mbit должно уйти в 100%.

есть мнение что dummynet живет сугубо на одном ядре и выше его производительности не прыгает.

сейчас собираем NASы на corei7 -есть выигрыш порядка 20% как по pps так и по Mbps - получали 600Mbps и ок 100k pps

--

http://cvsup.de.freebsd.org/base/head/sys/...fw/dummynet.txt

LOCKING

=======

At the moment the entire processing occurs under a single lock

which is expected to be acquired in exclusive mode

DN_BH_WLOCK() / DN_BH_WUNLOCK().

Edited November 10, 2010 by stalex

cmhungry · November 10, 2010

поставьте линукс и полисинг

gorec2005 · November 11, 2010

используйте для шейпинга ng_car ?

Deac · November 11, 2010

if_bridge мне категорически не нравится, он выглядит как огромный мегакостыль.
Я бы вообще его из системы выкорчевал нафик.

Есть ng_switch который решает эту же проблему, будучи подцепленным к ether lower/upper хукам на каждой сетевухе.

При этом всё динамически конфигурится и никаких кучи доп проверок в ядре нет.

Казалось бы всем хорош ng_bridge, да вот есть загвоздка - vlan-ы не пропускает, в отличии от if_bridge.

Т.е. если нужно построить прозрачный туннель, то без if_bridge не обойдёшься.

Ivan_83 · November 11, 2010

Казалось бы всем хорош ng_bridge, да вот есть загвоздка - vlan-ы не пропускает, в отличии от if_bridge.
Т.е. если нужно построить прозрачный туннель, то без if_bridge не обойдёшься.

Ну как дети :)

ng_ether_input вызывается раньше, чем BRIDGE_INPUT в ether_input.

А ровно перед этим влан деинкапсулируется, и в мбуф добавляется флаг что был влан и номер сохраняется.

Быстрый осмотр if_bridge.c показывает что там bridge_enqueue едиснтвенная содержит "m->m_flags & M_VLANTAG" - те смотри на наличие флага влана и инкапсулирует пакет обратно в влан, а точно после неё вызывается dst_ifp->if_transmit(dst_ifp, m); для отправки пакета

        /*
         * If underlying interface can not do VLAN tag insertion itself
         * then attach a packet tag that holds it.
         */
        if ((m->m_flags & M_VLANTAG) &&
            (dst_ifp->if_capenable & IFCAP_VLAN_HWTAGGING) == 0) {
            m = ether_vlanencap(m, m->m_pkthdr.ether_vtag);
            if (m == NULL) {
                if_printf(dst_ifp,
                    "unable to prepend VLAN header\n");
                dst_ifp->if_oerrors++;
                continue;
            }
            m->m_flags &= ~M_VLANTAG;
        }

в ng_ether.c в функции ng_ether_rcv_lower нет работы с вланами, вообще он ничего не знает про это.

берём в этой функции фрагмент:

    /* Drop in the MAC address if desired */
    if (priv->autoSrcAddr) {

        /* Make the mbuf writable if it's not already */
        if (!M_WRITABLE(m)
            && (m = m_pullup(m, sizeof(struct ether_header))) == NULL)
            return (ENOBUFS);

        /* Overwrite source MAC address */
        bcopy(IF_LLADDR(ifp),
            mtod(m, struct ether_header *)->ether_shost,
            ETHER_ADDR_LEN);
    }

    /* Send it on its way */
    return ether_output_frame(ifp, m);

и добавляем в него переделанный огрызок инкапсуляции в влан, получаем что то типа:

    /* Drop in the MAC address if desired */
    if (priv->autoSrcAddr) {

        /* Make the mbuf writable if it's not already */
        if (!M_WRITABLE(m)
            && (m = m_pullup(m, sizeof(struct ether_header))) == NULL)
            return (ENOBUFS);

        /* Overwrite source MAC address */
        bcopy(IF_LLADDR(ifp),
            mtod(m, struct ether_header *)->ether_shost,
            ETHER_ADDR_LEN);
    }

    /*
     * If underlying interface can not do VLAN tag insertion itself
     * then attach a packet tag that holds it.
     */
    if ((m->m_flags & M_VLANTAG) &&
        (ifp->if_capenable & IFCAP_VLAN_HWTAGGING) == 0) {
        m = ether_vlanencap(m, m->m_pkthdr.ether_vtag);
        if (m == NULL) {
            ifp->if_oerrors++;
            return (ENOBUFS);
        }
        m->m_flags &= ~M_VLANTAG;
    }

    /* Send it on its way */
    return ether_output_frame(ifp, m);

У меня нода собралась, проверять работу вланов мне негде/не охота настраивать.

Разбираться было 5 минут и ещё 15 писать сообщение, править код и тестить что соберётся :)

PS: запостил, kern/152141 - может и включат в дистр.

PPS: на интерфейсах нужно VLAN_HWTAGGING отключить, иначе не будет работать.

PPPS: mtu на интерфейсах должно быть одинаковым, ng_bridge не выругается матом при добавлении, но потери больших пакетов гарантированны.

yakuzzza · November 11, 2010

Рекомендую перейти на ng_car. От dummynet избавиться вообще.

Познакомиться в децствии и с подходами - http://abills.net.ua/wiki/doku.php/abills:docs:manual:ng_car

Edited November 11, 2010 by yakuzzza

stalex · November 16, 2010

Рекомендую перейти на ng_car. От dummynet избавиться вообще.
Познакомиться в децствии и с подходами - http://abills.net.ua/wiki/doku.php/abills:docs:manual:ng_car

Спасибо. Есть ли информация о результах работы ng_car - какая макс производительность

BRASа по pps и по Mbps ? или хоть какаято информация о производительности этого решения ?

yakuzzza · November 16, 2010

ng_car создает очень мало оверхеда, т.к. работает в kernelspace. На MPD некоторые личности получали до 2000 одновременных туннелей и до гигабита трафика.

PPS - по разному, 150К - реально видел у коллеги по цеху. Трафика было под 800Kbps.

Dyr · November 18, 2010

Раскидал шейпер с NAT'ом на разные машины, всё шоколадно.

Делать большое количество ng_car'ов не хочется.

stalex · November 18, 2010

Раскидал шейпер с NAT'ом на разные машины, всё шоколадно.
Делать большое количество ng_car'ов не хочется.

вот бы еще цифры увидеть ? dummynet шейпите или Ng_car ?

Dyr · November 18, 2010

Дык у меня всё скромно, дикие гигабиты не пропускаю - в пиках едва 500Мбит/сек.

Шейплю dummynet'ом.

Edited November 18, 2010 by Dyr

Elisium · November 19, 2010

Дык у меня всё скромно, дикие гигабиты не пропускаю - в пиках едва 500Мбит/сек.
Шейплю dummynet'ом.

Я тут как раз в соседней теме отписывался - шейпим/натим разными тазами в пределах 2 ГБт пока что.

Дамминет + ПФ.

Sign In

И снова к вопросу о BRAS на FreeBSD

Recommended Posts

Dyr

Ivan_83

Ilya Evseev

Dyr

Dyr

Ivan_83

Dyr

Ilya Evseev

Dyr

Ilya Evseev

Dyr

Ivan_83

Dyr

stalex

cmhungry

gorec2005

Deac

Ivan_83

yakuzzza

stalex

yakuzzza

Dyr

stalex

Dyr

Elisium

Join the conversation