[sirius_black]

 

На бордерах Core2Duo, перестанет хватать - будет Core i7. pfnat совсем не параллелится, работает на одном ядре с поллингом.

Расход ресурсов естественно на бордере больше чем на бридже.

[[GP]Villi]

а эксперименты с ipfw нат не проводили, вдруг оно нормально параллелится.

[sirius_black]

а эксперименты с ipfw нат не проводили, вдруг оно нормально параллелится.

Параллелится нормально только ng_nat, но он как и ipfw нат на libalias. А в нем опять утечки нашли.

[kapa]

Что такое "раскидывать трафик", и при чем там src mac ? Есть border1, border2 и routerN, между ними ospf. Бриджи прозрачны и занимаются только фильтрацией и шейпингом. Если nexthop - border2, трафик попадает в bridge0, если border1 - трафик попадает в bridge1.

у самого похожая схема, только бридж из 3-ёх сетевых (ещё из 1 Гигабита не выросли).

 

по bgp, если я правильно понимаю, только дефолт получаете?

[sirius_black]

по bgp, если я правильно понимаю, только дефолт получаете?

Куда получаю ? На рутера дефолт+MSK-IX. На бордерах full-view. Но вообще если поагрегировать плотненько, то можно все лить в ospf.

[[GP]Villi]

как это дефолт, а как же многоногость, я так понимаю у вас у одного бордера 1 аплинк, у другого другой. по идее пакеты должны распределяться в соотвествиии best-path, ну или что вы накрутите, но все равно чтобы был горячий резерв. а так отваливается 1 аплинк и часть клиентов сосет болт что ли?

[sirius_black]

как это дефолт, а как же многоногость, я так понимаю у вас у одного бордера 1 аплинк, у другого другой. по идее пакеты должны распределяться в соотвествиии best-path, ну или что вы накрутите, но все равно чтобы был горячий резерв. а так отваливается 1 аплинк и часть клиентов сосет болт что ли?

:-) Я же написал - там BGP. Если отваливается любой из аплинков, все продолжает работать.

[kapa]

по bgp, если я правильно понимаю, только дефолт получаете?

Куда получаю ? На рутера дефолт+MSK-IX. На бордерах full-view. Но вообще если поагрегировать плотненько, то можно все лить в ospf.

я про бордеры спрашивал.

 

у Вас у всех абонентов белые IP?

 

[[GP]Villi]

как это дефолт, а как же многоногость, я так понимаю у вас у одного бордера 1 аплинк, у другого другой. по идее пакеты должны распределяться в соотвествиии best-path, ну или что вы накрутите, но все равно чтобы был горячий резерв. а так отваливается 1 аплинк и часть клиентов сосет болт что ли?

:-) Я же написал - там BGP. Если отваливается любой из аплинков, все продолжает работать.

так они только в режиме резервирования работают, или в режиме балансинга? дефолт роут только же на один из бордеров может быть.

[sirius_black]

так они только в режиме резервирования работают, или в режиме балансинга? дефолт роут только же на один из бордеров может быть.

В режиме резервирования. Балансинг там получается автоматически. Пока. При необходимости ничто не мешает лить в ospf агрегированный full-view.

 

 

 

я про бордеры спрашивал.

 

у Вас у всех абонентов белые IP?

Нет конечно, большинство за NAT'ом. Без NAT'а можно было бы вообще обойтись одним бордером. Но RIPE не поймет.

[kapa]

я про бордеры спрашивал.

 

у Вас у всех абонентов белые IP?

Нет конечно, большинство за NAT'ом. Без NAT'а можно было бы вообще обойтись одним бордером. Но RIPE не поймет.

А как тогда пакеты, выйдя через один бордер возвращаются через другой?

[Dyr]

Можно конечно и два бриджа поставить рядом, но тогда необходимо распихивать юзеров по бриджам и синхронизировать таблички файерволла, что усложняет систему.

Из картинки я думал, что у вас именно так и реализовано, почему и заинтересовался.

А чтобы на каждый бридж по своему BGP бордеру приходилось, не так неинтересно.

 

"Синхронизировать таблички файерволла" кстати, очень удобно с помощью pfsync. Я так carp'овский fail-over "кластер" сделал.

Можно было бы сделать и раскидывание нагрузки на оба, через carp ARP balance, но неизбежно возникнут проблемы с определением ширины шейпинга(т.е. если, скажем, 30% трафика клиента пойдёт через carp1, а 70% через carp2, то какую ширину канала в ipfw dummynet на каждом из них выставлять, непонятно). :(

 

А как тогда пакеты, выйдя через один бордер возвращаются через другой?

Это как раз довольно тривиальная задача, классический PBR.

Изменено 29 октября, 2009 пользователем Dyr

[kapa]

А как тогда пакеты, выйдя через один бордер возвращаются через другой?

Это как раз довольно тривиальная задача, классический PBR.

Не понимаю.

 

Через бордер1, смотрящий на ИСП1, вышел на гугл пакет от 10.1.1.1, который, вместе с ещё сотней абонентов отнатился IP 1.1.1.1.

Гугл решил, что 1.1.1.1 ему ближе через ИСП2 и ответил туда.

На бордере2, смотрящем на ИСП2, есть правило которое натит 101 абонента IP 1.1.1.1 - в это чисто входит и 10.1.1.1, отправивший запрос.

Как бордер2 узнает кому послать ответ?

[TiFFolk]

Ну может второй бордер не натит в 1.1.1.1, а пакеты пришедшие на этот адрес отправит на первый бордер?

[jab]

Не понимаю.

Через бордер1, смотрящий на ИСП1, вышел на гугл пакет от 10.1.1.1, который, вместе с ещё сотней абонентов отнатился IP 1.1.1.1.

Гугл решил, что 1.1.1.1 ему ближе через ИСП2 и ответил туда.

На бордере2, смотрящем на ИСП2, есть правило которое натит 101 абонента IP 1.1.1.1 - в это чисто входит и 10.1.1.1, отправивший запрос.

Как бордер2 узнает кому послать ответ?

Форвардить пакеты на целевой нат... всего делов.

[kapa]

Форвардить пакеты на целевой нат... всего делов.

и балансировать входящий трафик не по провайдерам, а по гигабитным линкам от свичей к бордерам?

 

на пальцах:

 

есть 2 гигабитных линка между бордерами и свичём.

есть 2 гигабитных линка от свича к аплинкам.

есть 2 входящих потока по 1 гигабиту от аплинков

200 мегабит приходящих на бордер2 форвардятся на бордер1

итого на бордер1 по гигабиту пытается пролезть 1,2

настраиваем бгп так, чтоб бордер1 был дальше - получаем 800 на ИСП1 и 1200 на ИСП2. уже больше гигабита.

 

выход 10-гигабитные линки поднимать?

 

никак у меня картинка не нарисуется...

[jab]

Форвардить пакеты на целевой нат... всего делов.

и балансировать входящий трафик не по провайдерам, а по гигабитным линкам от свичей к бордерам?

 

на пальцах:

 

есть 2 гигабитных линка между бордерами и свичём.

есть 2 гигабитных линка от свича к аплинкам.

есть 2 входящих потока по 1 гигабиту от аплинков

200 мегабит приходящих на бордер2 форвардятся на бордер1

итого на бордер1 по гигабиту пытается пролезть 1,2

настраиваем бгп так, чтоб бордер1 был дальше - получаем 800 на ИСП1 и 1200 на ИСП2. уже больше гигабита.

 

выход 10-гигабитные линки поднимать?

 

никак у меня картинка не нарисуется...

Ну так поднимите еще гигабит напрямую между бордерами и форвардите на здоровье. Либо натьте на разных бордерах разные блоки с разными префиксами. Тогда как ушло, так и возвращаться будет.

[kapa]

Ну так поднимите еще гигабит напрямую между бордерами и форвардите на здоровье.

Не подумал, что можно вернуть через третью сетевуху.

 

Либо натьте на разных бордерах разные блоки с разными префиксами. Тогда как ушло, так и возвращаться будет.

Сейчас так и делаю. Разделяю локалку pbr-ами на роутерах на 2 бордера - с каждого из них анонсирую свой кусок AS и всю AS целиком на случай падения одного из аплинков. Пинговалкой тестирую провайдеров и, при отвале одного из них, меняю pbr-ы.

 

Но хочу прийти к full-view, поэтому интересуюсь.

[Dyr]

Как бордер2 узнает кому послать ответ?

Я же говорю, синхронизируйте (pf) NAT states.

[kkadd]

есть в dummynet фатальная ошибка в каунтерах, изза которой пайпы имеют тенденцию грохать систему.

где-то я видел патч.

Кажется вот так лечится думминет.

http://freebsd.rambler.ru/bsdmail/freebsd-...7/msg01566.html

 

--- ip_dummynet.c_orig Sun Jun 10 20:19:33 2007

+++ ip_dummynet.c Fri Jun 15 07:37:46 2007

@@ -433,7 +433,7 @@

static struct dn_pkt_tag *

dn_tag_get(struct mbuf *m)

{

- struct m_tag *mtag = m_tag_first(m);

+ struct m_tag *mtag = m_tag_find(m, PACKET_TAG_DUMMYNET, NULL);

KASSERT(mtag != NULL &&

mtag->m_tag_cookie == MTAG_ABI_COMPAT &&

mtag->m_tag_id == PACKET_TAG_DUMMYNET,

@@ -698,8 +698,10 @@

if (p->if_name[0]==0 && p->numbytes < 0) { /* this implies bandwidth >0 */

dn_key t=0 ; /* number of ticks i have to wait */

 

- if (p->bandwidth > 0)

- t = ( p->bandwidth -1 - p->numbytes) / p->bandwidth ;

+ if (p->bandwidth > 0)

+ t = ( (u_int64_t)p->bandwidth -1 - p->numbytes) / p->bandwidth ;

+

+ KASSERT( (curr_time + t) >= curr_time, ("wfq overflow"));

dn_tag_get(p->tail)->output_time += t ;

p->sched_time = curr_time ;

heap_insert(&wfq_ready_heap, curr_time + t, (void *)p);

 

FreeBSD 6.2-RELEASE

 

работал сервер нормально до тех пор пока не начал нарезать пайпы....сначала было мало труб ребутиллся раз в мес...искали почему...все пробывали....потом когда возрасло кол-во абонентов так он начал падать оч часто....

хочу применить этот патч но не будет ли хуже???

посмотрел исходник дамайнета на 6,4 и 6,2 каша какая то.... подскажите плз кто нибудь вливал патч и как себя ведет даммайн после этого?

трубы динамические.

И как оказалось, СИСТЕМА ПАДАЕТ КОГДА УДАЛЯЕТСЯ ПРАВИЛО КОТОРОЕ

ОТПРАВЛЯЕТ ПАКЕТЫ НА DUMMYNET, причем без разницы, есть ли в данный

момент пакеты на обработке dummynet.

 

не будет проблем после патча вот в чем дело...и так дела плохи так еще и хуже сделать не охото ((

 

на сервере ng_nat+ipfw шейпинг через DUMMYNET.....

 

[kkadd]

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

[littlesavage]

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

kern/113548 уже 2 года как закрыт, все нужные патчи были еще в 6.3. Там еще после этого несколько раз проблемы с каунтерами было по-моему :)

Здесь какой-то другой баг. Возможно, вот этот: http://svn.freebsd.org/viewvc/base?view=re...revision=193859

Обновитесь хотя-бы до RELENG_7.

[vxb]

имеем kernel panic с предшествующими:

Mar 1 00:00:39 s3 kernel: em1: discard frame w/o packet header

Mar 1 00:00:43 s3 kernel: em0: discard frame w/o packet header

7.2-STABLE, em-6.9.6-RELENG7-yandex-1.36.2.10

имеем аналогичное

как решили проблему ?

[LuckySB]

И как оказалось, СИСТЕМА ПАДАЕТ КОГДА УДАЛЯЕТСЯ ПРАВИЛО КОТОРОЕ

ОТПРАВЛЯЕТ ПАКЕТЫ НА DUMMYNET, причем без разницы, есть ли в данный

момент пакеты на обработке dummynet.

Не делайте так.

Если вам действительно нужен дамминет - используйте таблицы. Примеров на форуме масса.

 

[Ilya Evseev]

Возвращаясь к теме, указанной в заголовке :)

Есть freebsd 7.1-release-p9 на двух серверах:

1) cpu core2quad q6600, сетевая карта intel pro/1000 pt dual port, драйверы em0-6.9.6-yandex-1.36.2.10.

2) cpu core2duo e7300, сетевые встроенные bcm5721, драйвер bge с патчем от Igor Sysoev, включен coalescing.

Используются для ipfw+tables+pipe+dummynet.

Все настройки, кроме em/bge, одинаковые.

 

Проблемы и вопросы:

1) нормально ли, что при примерно одинаковом трафике количество прерываний от сетевых карт на сервере corequad+intel вчетверо больше, чем на coreduo+bge?

quad-em# vmstat -i | grep em
irq256: em0                     84063382       9334
irq257: em1                     82004551       9105

duo-bge# vmstat -i | grep bge
irq256: bge0                    80791213       1861
irq257: bge1                    78573991       1810

 

2) на coreduo процесс dummynet кушает 0%, а на corequad - десятки процентов и является самым прожорливым:

quad-em# top -abSH
  PID USERNAME PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   14 root     171 ki31     0K     8K CPU0   0 128:03 83.59% [idle: cpu0]
   12 root     171 ki31     0K     8K CPU2   2 131:50 78.47% [idle: cpu2]
   11 root     171 ki31     0K     8K CPU3   3 130:41 68.46% [idle: cpu3]
   13 root     171 ki31     0K     8K RUN    1 129:58 62.79% [idle: cpu1]
   51 root     -68    -     0K     8K -      2  39:45 47.80% [dummynet]
   32 root      43    -     0K     8K CPU0   0  17:35 19.14% [em1_rx_kthread_1]
   31 root      43    -     0K     8K WAIT   3  17:35 18.60% [em1_rx_kthread_0]
   28 root      43    -     0K     8K WAIT   0  15:10 14.99% [em0_rx_kthread_1]
   27 root      43    -     0K     8K WAIT   2  15:08 14.94% [em0_rx_kthread_0]
3754 bind      44    0  3128K  1724K select 1   2:00  0.44% /usr/local/sbin/unbound
   15 root     -32    -     0K     8K WAIT   0   1:58  0.34% [swi4: clock sio]
   30 root     -68    -     0K     8K WAIT   3   0:40  0.00% [em1_txcleaner]
   26 root     -68    -     0K     8K WAIT   2   0:35  0.00% [em0_txcleaner]
   18 root     -16    -     0K     8K -      0   0:23  0.00% [yarrow]

duo-bge# top -abSH
  PID USERNAME PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   11 root     171 ki31     0K    16K RUN    1 562:37 71.97% [idle: cpu1]
   12 root     171 ki31     0K    16K CPU0   0 572:13 69.97% [idle: cpu0]
   24 root     -68    -     0K    16K WAIT   1 125:13 23.00% [irq257: bge1]
   23 root     -68    -     0K    16K WAIT   0 109:53 23.00% [irq256: bge0]
   41 root     -68    -     0K    16K -      0  63:27  0.00% [dummynet]
   14 root     -32    -     0K    16K WAIT   1   3:43  0.00% [swi4: clock sio]
14518 bind      44    0 35328K 27076K select 1   2:37  0.00% /usr/local/sbin/unbound
   16 root     -16    -     0K    16K -      1   1:12  0.00% [yarrow]
   47 root      20    -     0K    16K syncer 0   0:52  0.00% [syncer]
   13 root     -44    -     0K    16K WAIT   0   0:04  0.00% [swi1: net]
    3 root      -8    -     0K    16K -      1   0:03  0.00% [g_up]

 

3) при том же трафике (~70-80kpps, 400mbps=2*(150 in+50 out))

quad-em расходует почти вдвое больше процессорного времени, чем duo-bge,

то есть получается, что предельная загрузка у них будет примерно одинаковой - около 400mbps.

 

Настройки:

 

# cat /boot/loader.conf:
hw.em.rxd=4096
hw.em.txd=4096
hw.em.enable_msi=1
hw.em.rx_int_delay=600
hw.em.tx_int_delay=600
hw.em.rx_abs_int_delay=1000
hw.em.tx_abs_int_delay=1000

 

# cat /etc/sysctl.conf
net.inet.ip.fw.verbose=1
net.inet.ip.fw.debug=0  

net.link.ether.inet.log_arp_wrong_iface=0

net.inet.ip.dummynet.io_fast=1
net.inet.ip.fastforwarding=1  
net.inet.ip.redirect=0        

net.inet.ip.fw.dyn_buckets=2048         # default=256
net.inet.ip.dummynet.hash_size=1024     # default=64 

net.inet.ip.fastforwarding=1

net.inet.tcp.blackhole=2              
net.inet.udp.blackhole=1              

dev.em.0.rx_int_delay=600
dev.em.0.tx_int_delay=600
dev.em.0.rx_abs_int_delay=1000
dev.em.0.tx_abs_int_delay=1000
dev.em.0.rx_processing_limit=1024

dev.em.1.rx_int_delay=600
dev.em.1.tx_int_delay=600
dev.em.1.rx_abs_int_delay=1000
dev.em.1.tx_abs_int_delay=1000
dev.em.1.rx_processing_limit=1024

net.inet.ip.intr_queue_maxlen=2048

 

quad-em# sysctl dev.em
dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6.Yandex[$Revision: 1.36.2.10 $]
dev.em.0.%driver: em
dev.em.0.%location: slot=0 function=0
dev.em.0.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x8086 subdevice=0x115e class=0x020000
dev.em.0.%parent: pci5
dev.em.0.debug: -1
dev.em.0.stats: -1
dev.em.0.rx_kthreads: 2
dev.em.0.rx_int_delay: 600
dev.em.0.tx_int_delay: 600
dev.em.0.rx_abs_int_delay: 1000
dev.em.0.tx_abs_int_delay: 1000
dev.em.0.rx_kthread_priority: 127
dev.em.1.%desc: Intel(R) PRO/1000 Network Connection 6.9.6.Yandex[$Revision: 1.36.2.10 $]
dev.em.1.%driver: em
dev.em.1.%location: slot=0 function=1
dev.em.1.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x8086 subdevice=0x115e class=0x020000
dev.em.1.%parent: pci5
dev.em.1.debug: -1
dev.em.1.stats: -1
dev.em.1.rx_kthreads: 2
dev.em.1.rx_int_delay: 600
dev.em.1.tx_int_delay: 600
dev.em.1.rx_abs_int_delay: 1000
dev.em.1.tx_abs_int_delay: 1000
dev.em.1.rx_kthread_priority: 127

 

duo-bge# sysctl hw.bge
hw.bge.bge_rxd: 512
hw.bge.allow_asf: 0
duo-bge# sysctl dev.bge
dev.bge.0.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x4201
dev.bge.0.%driver: bge
dev.bge.0.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P8.LAN2
dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x1659 subvendor=0x1043 subdevice=0x8149 class=0x020000
dev.bge.0.%parent: pci3
dev.bge.0.program_coal: 0
dev.bge.0.rx_coal_ticks: 500
dev.bge.0.tx_coal_ticks: 10000
dev.bge.0.rx_max_coal_bds: 64
dev.bge.0.tx_max_coal_bds: 128
dev.bge.1.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x4201
dev.bge.1.%driver: bge
dev.bge.1.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P9.LAN1
dev.bge.1.%pnpinfo: vendor=0x14e4 device=0x1659 subvendor=0x1043 subdevice=0x8149 class=0x020000
dev.bge.1.%parent: pci2
dev.bge.1.program_coal: 0
dev.bge.1.rx_coal_ticks: 500
dev.bge.1.tx_coal_ticks: 10000
dev.bge.1.rx_max_coal_bds: 64
dev.bge.1.tx_max_coal_bds: 128