sirius_black Опубликовано 28 октября, 2009 · Жалоба На бордерах Core2Duo, перестанет хватать - будет Core i7. pfnat совсем не параллелится, работает на одном ядре с поллингом. Расход ресурсов естественно на бордере больше чем на бридже. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 28 октября, 2009 · Жалоба а эксперименты с ipfw нат не проводили, вдруг оно нормально параллелится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirius_black Опубликовано 28 октября, 2009 · Жалоба а эксперименты с ipfw нат не проводили, вдруг оно нормально параллелится. Параллелится нормально только ng_nat, но он как и ipfw нат на libalias. А в нем опять утечки нашли. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 28 октября, 2009 · Жалоба Что такое "раскидывать трафик", и при чем там src mac ? Есть border1, border2 и routerN, между ними ospf. Бриджи прозрачны и занимаются только фильтрацией и шейпингом. Если nexthop - border2, трафик попадает в bridge0, если border1 - трафик попадает в bridge1.у самого похожая схема, только бридж из 3-ёх сетевых (ещё из 1 Гигабита не выросли). по bgp, если я правильно понимаю, только дефолт получаете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirius_black Опубликовано 28 октября, 2009 · Жалоба по bgp, если я правильно понимаю, только дефолт получаете? Куда получаю ? На рутера дефолт+MSK-IX. На бордерах full-view. Но вообще если поагрегировать плотненько, то можно все лить в ospf. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 28 октября, 2009 · Жалоба как это дефолт, а как же многоногость, я так понимаю у вас у одного бордера 1 аплинк, у другого другой. по идее пакеты должны распределяться в соотвествиии best-path, ну или что вы накрутите, но все равно чтобы был горячий резерв. а так отваливается 1 аплинк и часть клиентов сосет болт что ли? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirius_black Опубликовано 28 октября, 2009 · Жалоба как это дефолт, а как же многоногость, я так понимаю у вас у одного бордера 1 аплинк, у другого другой. по идее пакеты должны распределяться в соотвествиии best-path, ну или что вы накрутите, но все равно чтобы был горячий резерв. а так отваливается 1 аплинк и часть клиентов сосет болт что ли? :-) Я же написал - там BGP. Если отваливается любой из аплинков, все продолжает работать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 28 октября, 2009 · Жалоба по bgp, если я правильно понимаю, только дефолт получаете? Куда получаю ? На рутера дефолт+MSK-IX. На бордерах full-view. Но вообще если поагрегировать плотненько, то можно все лить в ospf. я про бордеры спрашивал. у Вас у всех абонентов белые IP? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 28 октября, 2009 · Жалоба как это дефолт, а как же многоногость, я так понимаю у вас у одного бордера 1 аплинк, у другого другой. по идее пакеты должны распределяться в соотвествиии best-path, ну или что вы накрутите, но все равно чтобы был горячий резерв. а так отваливается 1 аплинк и часть клиентов сосет болт что ли? :-) Я же написал - там BGP. Если отваливается любой из аплинков, все продолжает работать. так они только в режиме резервирования работают, или в режиме балансинга? дефолт роут только же на один из бордеров может быть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirius_black Опубликовано 29 октября, 2009 · Жалоба так они только в режиме резервирования работают, или в режиме балансинга? дефолт роут только же на один из бордеров может быть. В режиме резервирования. Балансинг там получается автоматически. Пока. При необходимости ничто не мешает лить в ospf агрегированный full-view. я про бордеры спрашивал. у Вас у всех абонентов белые IP? Нет конечно, большинство за NAT'ом. Без NAT'а можно было бы вообще обойтись одним бордером. Но RIPE не поймет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 29 октября, 2009 · Жалоба я про бордеры спрашивал. у Вас у всех абонентов белые IP? Нет конечно, большинство за NAT'ом. Без NAT'а можно было бы вообще обойтись одним бордером. Но RIPE не поймет. А как тогда пакеты, выйдя через один бордер возвращаются через другой? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 29 октября, 2009 (изменено) · Жалоба Можно конечно и два бриджа поставить рядом, но тогда необходимо распихивать юзеров по бриджам и синхронизировать таблички файерволла, что усложняет систему.Из картинки я думал, что у вас именно так и реализовано, почему и заинтересовался.А чтобы на каждый бридж по своему BGP бордеру приходилось, не так неинтересно. "Синхронизировать таблички файерволла" кстати, очень удобно с помощью pfsync. Я так carp'овский fail-over "кластер" сделал. Можно было бы сделать и раскидывание нагрузки на оба, через carp ARP balance, но неизбежно возникнут проблемы с определением ширины шейпинга(т.е. если, скажем, 30% трафика клиента пойдёт через carp1, а 70% через carp2, то какую ширину канала в ipfw dummynet на каждом из них выставлять, непонятно). :( А как тогда пакеты, выйдя через один бордер возвращаются через другой?Это как раз довольно тривиальная задача, классический PBR. Изменено 29 октября, 2009 пользователем Dyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 29 октября, 2009 · Жалоба А как тогда пакеты, выйдя через один бордер возвращаются через другой?Это как раз довольно тривиальная задача, классический 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 узнает кому послать ответ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 29 октября, 2009 · Жалоба Ну может второй бордер не натит в 1.1.1.1, а пакеты пришедшие на этот адрес отправит на первый бордер? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 29 октября, 2009 · Жалоба Не понимаю.Через бордер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 узнает кому послать ответ? Форвардить пакеты на целевой нат... всего делов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 29 октября, 2009 · Жалоба Форвардить пакеты на целевой нат... всего делов.и балансировать входящий трафик не по провайдерам, а по гигабитным линкам от свичей к бордерам? на пальцах: есть 2 гигабитных линка между бордерами и свичём. есть 2 гигабитных линка от свича к аплинкам. есть 2 входящих потока по 1 гигабиту от аплинков 200 мегабит приходящих на бордер2 форвардятся на бордер1 итого на бордер1 по гигабиту пытается пролезть 1,2 настраиваем бгп так, чтоб бордер1 был дальше - получаем 800 на ИСП1 и 1200 на ИСП2. уже больше гигабита. выход 10-гигабитные линки поднимать? никак у меня картинка не нарисуется... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 29 октября, 2009 · Жалоба Форвардить пакеты на целевой нат... всего делов.и балансировать входящий трафик не по провайдерам, а по гигабитным линкам от свичей к бордерам? на пальцах: есть 2 гигабитных линка между бордерами и свичём. есть 2 гигабитных линка от свича к аплинкам. есть 2 входящих потока по 1 гигабиту от аплинков 200 мегабит приходящих на бордер2 форвардятся на бордер1 итого на бордер1 по гигабиту пытается пролезть 1,2 настраиваем бгп так, чтоб бордер1 был дальше - получаем 800 на ИСП1 и 1200 на ИСП2. уже больше гигабита. выход 10-гигабитные линки поднимать? никак у меня картинка не нарисуется... Ну так поднимите еще гигабит напрямую между бордерами и форвардите на здоровье. Либо натьте на разных бордерах разные блоки с разными префиксами. Тогда как ушло, так и возвращаться будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 29 октября, 2009 · Жалоба Ну так поднимите еще гигабит напрямую между бордерами и форвардите на здоровье.Не подумал, что можно вернуть через третью сетевуху. Либо натьте на разных бордерах разные блоки с разными префиксами. Тогда как ушло, так и возвращаться будет.Сейчас так и делаю. Разделяю локалку pbr-ами на роутерах на 2 бордера - с каждого из них анонсирую свой кусок AS и всю AS целиком на случай падения одного из аплинков. Пинговалкой тестирую провайдеров и, при отвале одного из них, меняю pbr-ы. Но хочу прийти к full-view, поэтому интересуюсь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 24 ноября, 2009 · Жалоба Как бордер2 узнает кому послать ответ? Я же говорю, синхронизируйте (pf) NAT states. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kkadd Опубликовано 19 декабря, 2009 · Жалоба есть в 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..... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kkadd Опубликовано 20 декабря, 2009 · Жалоба после применения патча система падает после нескольких десятков монипуляций с пайпами Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 20 декабря, 2009 · Жалоба после применения патча система падает после нескольких десятков монипуляций с пайпами kern/113548 уже 2 года как закрыт, все нужные патчи были еще в 6.3. Там еще после этого несколько раз проблемы с каунтерами было по-моему :) Здесь какой-то другой баг. Возможно, вот этот: http://svn.freebsd.org/viewvc/base?view=re...revision=193859 Обновитесь хотя-бы до RELENG_7. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vxb Опубликовано 24 декабря, 2009 · Жалоба имеем 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имеем аналогичное как решили проблему ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
LuckySB Опубликовано 24 декабря, 2009 · Жалоба И как оказалось, СИСТЕМА ПАДАЕТ КОГДА УДАЛЯЕТСЯ ПРАВИЛО КОТОРОЕОТПРАВЛЯЕТ ПАКЕТЫ НА DUMMYNET, причем без разницы, есть ли в данный момент пакеты на обработке dummynet. Не делайте так. Если вам действительно нужен дамминет - используйте таблицы. Примеров на форуме масса. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 27 декабря, 2009 · Жалоба Возвращаясь к теме, указанной в заголовке :) Есть 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...