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

И снова к вопросу о BRAS на FreeBSD Большая загрузка CPU при NAT и шейпировании

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

Была старая тема про правильную настройку серверов 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

 

 

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

Изменено пользователем Dyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что можно в данном случае сделать?
Заменить процессор на c2d e8600.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Заметки на полях. Разработчики 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?

Изменено пользователем Dyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Изменено пользователем Dyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 Мбайта.

Изменено пользователем Dyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Чем NAT на Linux лучше NAT'a на FreeBSD?
Производительностью и простотой.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Простотой? Приведи, пожалуйста, пример 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.

Изменено пользователем Dyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем Dyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

для теста можете отключить шейпинг, должна увеличится пропусканая способность до 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().

Изменено пользователем stalex

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Казалось бы всем хорош 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 не выругается матом при добавлении, но потери больших пакетов гарантированны.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

Изменено пользователем yakuzzza

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Шейплю dummynet'ом.

Изменено пользователем Dyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Шейплю dummynet'ом.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.