[DVM-Avgoor]

Остаётся вопрос - будет ли поиск по хэш-таблице быстрее, чем исходные поиск IP в таблице и взятие tablearg

 

Попробовать конечно стоит, ради интереса. Но сам по себе поиск по radix tree (который используется в ipfw) очень эффективен.

Оценочно я делал в свое время проверялочку на бсдшный radix.c, получалось примерно 15-25 циклов поиска в случае удачи и 50-60 в случае неудачи, на 100 000 ip-адресов.

Речь конечно идет о микросекундах на каждый поиск. + Судя по коду ip_fw_dynamic.c там нехилое такое кол-во локов, даже на лукап лок есть, боюсь быстрее не выйдет... Но попробовать было бы интересно :)

[Dyr]

Итак, докладываю по результатам однодневного теста под нагрузкой сервера, переведённого на Linux (NAT + tc shaping + ipt_netflow), c младшим из семейства наших серверов процессором E3-1220 против E3-1270 на остальных.

 

Нагрузка - 1200 Мбит/сек транзита, 120 кппс, 260 000 conntrack-записей. Показатели загрузки: LA 0.04, CPU interrupts менее 30% на каждое из ядер, context switching менее 7000. Сказать, что я доволен, значит ничего не сказать.

 

Безусловно, я ещё буду пробовать ipfw nat и ветвление правил во FreeBSD, но Linux о-о-чень впечатлил работой, в сущности, из коробки (ну да, пришлось посидеть над пониманием хеширования tc filter, но оно того стоило).

 

perf top

 

Samples: 1M of event 'cycles', Event count (approx.): 60222861933                                                                                         
 5,23%  [kernel]                           [k] _raw_spin_unlock
 4,13%  [kernel]                           [k] _raw_spin_lock
 3,67%  [kernel]                           [k] igb_clean_rx_irq
 3,37%  [kernel]                           [k] netflow_target
 3,17%  [kernel]                           [k] igb_poll
 2,89%  [kernel]                           [k] irq_entries_start
 2,88%  [kernel]                           [k] ipt_do_table
 2,73%  [kernel]                           [k] native_write_msr_safe
 2,61%  [kernel]                           [k] fib_table_lookup
 2,02%  [kernel]                           [k] ____nf_conntrack_find
 1,83%  [kernel]                           [k] htb_dequeue
 1,70%  [kernel]                           [k] nf_iterate
 1,32%  [kernel]                           [k] apic_timer_interrupt
 1,20%  [kernel]                           [k] igb_xmit_frame_ring
 1,17%  [kernel]                           [k] check_leaf.isra.8
 1,15%  [kernel]                           [k] __netif_receive_skb_core
 1,11%  [kernel]                           [k] __dev_queue_xmit
 1,08%  [kernel]                           [k] native_read_tsc
 1,05%  [kernel]                           [k] qdisc_dequeue_head

 

Из плохого: примерно каждые 10 минут отваливается bonding интерфейсы между сервером и Juniper MX240, причём сразу оба интерфейса по два линка в каждом:

 

dyr@rj39> show log messages | match "Apr 23" | match "bundle"

 

Apr 23 17:29:23  rj39 /kernel: bundle ae2.1: bundle IFL state changed to DOWN
Apr 23 17:29:23  rj39 /kernel: bundle ae2.32767: bundle IFL state changed to DOWN
Apr 23 17:29:24  rj39 /kernel: ae_bundlestate_ifd_change: bundle ae0: bundle IFD minimum links not met 0 < 1
Apr 23 17:29:24  rj39 /kernel: ae_bundlestate_ifd_change: bundle ae0: bundle IFD state changed to DOWN
Apr 23 17:29:24  rj39 /kernel: bundle ae0.3919: bundle IFL state changed to DOWN
Apr 23 17:29:24  rj39 /kernel: bundle ae0.32767: bundle IFL state changed to DOWN
Apr 23 17:29:24  rj39 /kernel: ae_bundlestate_ifd_change: bundle ae0: bundle IFD state changed to UP
Apr 23 17:29:24  rj39 /kernel: bundle ae0.3919: bundle IFL state changed to UP
Apr 23 17:29:24  rj39 /kernel: bundle ae0.32767: bundle IFL state changed to UP
Apr 23 17:29:24  rj39 /kernel: ae_bundlestate_ifd_change: bundle ae2: bundle IFD state changed to UP
Apr 23 17:29:24  rj39 /kernel: bundle ae2.1: bundle IFL state changed to UP
Apr 23 17:29:24  rj39 /kernel: bundle ae2.32767: bundle IFL state changed to UP
Apr 23 17:29:24  rj39 /kernel: bundle ae2.1: bundle IFL state changed to UP
Apr 23 17:29:24  rj39 /kernel: bundle ae2.32767: bundle IFL state changed to UP
Apr 23 17:29:24  rj39 /kernel: bundle ae0.3919: bundle IFL state changed to UP
Apr 23 17:29:24  rj39 /kernel: bundle ae0.32767: bundle IFL state changed to UP
Apr 23 17:32:18  rj39 /kernel: bundle ae2.1: bundle IFL state changed to UP
Apr 23 17:32:18  rj39 /kernel: bundle ae2.32767: bundle IFL state changed to UP
Apr 23 17:32:18  rj39 /kernel: ae_bundlestate_ifd_change: bundle ae2: bundle IFD minimum links not met 0 < 1
Apr 23 17:32:18  rj39 /kernel: ae_bundlestate_ifd_change: bundle ae2: bundle IFD state changed to DOWN
Apr 23 17:32:18  rj39 /kernel: bundle ae2.1: bundle IFL state changed to DOWN
Apr 23 17:32:18  rj39 /kernel: bundle ae2.32767: bundle IFL state changed to DOWN
Apr 23 17:32:18  rj39 /kernel: bundle ae0.3919: bundle IFL state changed to UP
Apr 23 17:32:18  rj39 /kernel: bundle ae0.32767: bundle IFL state changed to UP
Apr 23 17:32:19  rj39 /kernel: ae_bundlestate_ifd_change: bundle ae0: bundle IFD minimum links not met 0 < 1
Apr 23 17:32:19  rj39 /kernel: ae_bundlestate_ifd_change: bundle ae0: bundle IFD state changed to DOWN
Apr 23 17:32:19  rj39 /kernel: bundle ae0.3919: bundle IFL state changed to DOWN
Apr 23 17:32:19  rj39 /kernel: bundle ae0.32767: bundle IFL state changed to DOWN
Apr 23 17:32:34  rj39 /kernel: ae_bundlestate_ifd_change: bundle ae2: bundle IFD state changed to UP
Apr 23 17:32:34  rj39 /kernel: bundle ae2.1: bundle IFL state changed to UP
Apr 23 17:32:34  rj39 /kernel: bundle ae2.32767: bundle IFL state changed to UP
Apr 23 17:32:34  rj39 /kernel: bundle ae2.1: bundle IFL state changed to UP
Apr 23 17:32:34  rj39 /kernel: bundle ae2.32767: bundle IFL state changed to UP
Apr 23 17:32:34  rj39 /kernel: ae_bundlestate_ifd_change: bundle ae0: bundle IFD state changed to UP
Apr 23 17:32:34  rj39 /kernel: bundle ae0.3919: bundle IFL state changed to UP
Apr 23 17:32:34  rj39 /kernel: bundle ae0.32767: bundle IFL state changed to UP
Apr 23 17:32:34  rj39 /kernel: bundle ae0.3919: bundle IFL state changed to UP
Apr 23 17:32:34  rj39 /kernel: bundle ae0.32767: bundle IFL state changed to UP
Apr 23 17:36:40  rj39 /kernel: bundle ae0.3919: bundle IFL state changed to UP
Apr 23 17:36:40  rj39 /kernel: bundle ae0.32767: bundle IFL state changed to UP

 

 

[s.lobanov]

таймеры бонда. и вообще сделайте трейс на jun, думаю быстро причины найдёте. http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/interfaces-configuring-aggregated-ethernet-lacp.html#id-12140766

[Dyr]

Таймеры стоят такие:

 

	bond-lacp-rate fast
bond-miimon 100
bond_downdelay 200
bond-updelay 200

 

cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

802.3ad info
LACP rate: fast
Min links: 0
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 2
Actor Key: 17
Partner Key: 1
Partner Mac Address: 80:71:1f:11:87:c0

Slave Interface: p1p2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 1
Permanent HW addr: 00:1b:21:91:de:1d
Aggregator ID: 1
Slave queue ID: 0

Slave Interface: p1p1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 1
Permanent HW addr: 00:1b:21:91:de:1c
Aggregator ID: 1
Slave queue ID: 0

 

Аналогично для bond1

 

За ссылку на трейс спасибо, поставлю.

 

 

[DVM-Avgoor]

Нагрузка - 1200 Мбит/сек транзита, 120 кппс, 260 000 conntrack-записей. Показатели загрузки: LA 0.04, CPU interrupts менее 30% на каждое из ядер, context switching менее 7000. Сказать, что я доволен, значит ничего не сказать.

 

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

А интеррапты примерно и есть показатель нагрузки, только не рассчитывайте что при 30% interrupts у вас есть 2/3 запаса. Это не так, они не линейны.

 

Бондинг на линуксе уныл чуть более чем полностью, можно выкрутить таймеры но кардинально решается только переходом на 10G адаптеры.

 

OFFTOP. Ну как вкус победы? :))

[DVM-Avgoor]

PS. я только один не понимаю зачем имея mx240 под рукой шейпить на писюке? o_O

[Dyr]

На 10 Гб переведу сегодня-завтра.

 

MX240 без DPC-карты, будет печально.

Вкус победа о да, велик :)

 

 

 

Изменено 24 апреля, 2014 пользователем Dyr

[kayot]

Бондинг на линуксе уныл чуть более чем полностью, можно выкрутить таймеры но кардинально решается только переходом на 10G адаптеры.

Да ну вас. Лет 5 уже все наши машины работают с бондингами, разные дистрибутивы с разными ядрами, включены в разные железки. "Ни единого разрыва".

Тут явно что-то не так со стороны ждуна.

[DVM-Avgoor]

Да ну вас. Лет 5 уже все наши машины работают с бондингами, разные дистрибутивы с разными ядрами, включены в разные железки. "Ни единого разрыва".

Тут явно что-то не так со стороны ждуна.

 

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

[s.lobanov]

ну так что показал трейс на jun относительно развала lag?

[vitalyb]

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

откройте для себя /sys/class/net/bond0/bonding/ :)

[DVM-Avgoor]

откройте для себя /sys/class/net/bond0/bonding/ :)

 

И? Это не передача опций к модулю?

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

2ая в разных дистрибах все делается по-разному, и всякие ifenslave еще доставлять надо, и ренеймить/алиасить модули.

Ну взрослые люди, уже три миллиона принципиально новых обоев запилили а не ifconfig не ip не умеют поднимать лагг.

[s.lobanov]

откройте для себя /sys/class/net/bond0/bonding/ :)

 

И? Это не передача опций к модулю?

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

2ая в разных дистрибах все делается по-разному, и всякие ifenslave еще доставлять надо, и ренеймить/алиасить модули.

Ну взрослые люди, уже три миллиона принципиально новых обоев запилили а не ifconfig не ip не умеют поднимать лагг.

 

это у вас общая претензия к linux-дистрибутивам, а не к bond-у. после фряхи непривычно будет, потом привыкните или останитесь на фряхе.

 

вообще, конечно придираться к таким мелочам(надо доставить userspace-утилиту и т.п.) это просто придирки. не нравится "стандартные" linux-утилиты и их разнообразие - пользуйтесь vyatta, там cli привычный для сетевых админов

[DVM-Avgoor]

это у вас общая претензия к linux-дистрибутивам, а не к bond-у. после фряхи непривычно будет, потом привыкните или останитесь на фряхе.

 

 

Да мне, спасибо, уже поздно.

Я уже 1.4Мппс выжимал со слезами из линукса и 8 сетевых карт, больше не хочется.

Суть претензий не в привычке, суть претензий в том, что логично было бы эти мелочи уже воткнуть в базу и сделать стандартом. systemd впихивают изо всех сил, а вланы и бондинг нормально сделать вот сложность и "никому не надо".

 

Пс, судя по всему модуль бондинга с 2006 не менялся особо. Раньше была у меня большая проблема, что при ребуте коробки 1 из 3 бондов рандомно (чаще второй по очереди) не поднимался, и на месте него вставал другой, с другими настройками. Это бесило капец как.

[Alex/AT]

Итак, докладываю по результатам однодневного теста под нагрузкой сервера, переведённого на Linux (NAT + tc shaping + ipt_netflow), c младшим из семейства наших серверов процессором E3-1220 против E3-1270 на остальных.

А теперь сделайте следующее:

echo 16 > /proc/sys/net/core/dev_weight
echo 256 > /proc/sys/net/core/netdev_budget
echo 16000 > /proc/sys/net/core/netdev_max_backlog
echo 0 > /proc/sys/net/core/netdev_tstamp_prequeue

Посмотрите, есть ли улучшения. Это не панацея, всё зависит от характера обработки (сколько правил, что в tc, ...) - но может улучшить.

Наверняка большую часть времени, кстати, жрёт ipt_netflow, там есть параметр размера хеша (если память не изменяет) - вот его можно покрутить.

 

Я уже 1.4Мппс выжимал со слезами из линукса и 8 сетевых карт, больше не хочется.

Чем вы его так изнасиловали? Я 800Kpps спокойно из двух трёх e1000 (да-да, в бондинге) с софтварным RPS, декапсуляцией PPPoE и приличным числом правил tc/iptables +pbr получал, нагрузка по SI/HI никогда не превышала 50% старенького 4-ядерного Xeon'а.

[DVM-Avgoor]

Чем вы его так изнасиловали? Я 800Kpps спокойно из двух карт получал, нагрузка по SI/HI не превышала 50% старенького 4-ядерного Xeon'а.

 

Это был бордер в городские IX небольшой сети, у которой была гора трафика и пустые карманы. (4G внутрь, 2G + 2G в разные IX, PBR с некоторых ип, iptables-nat) Там стоял на то время самый современный Core 2Quad QX6800.

Ксеонов вроде с таким новым ядром еще не было, или они были заоблачно не доступны, я уже плохо помню... Оно прожило чуть больше года, и было заменено на 65ую. Сон стал крепче, определенно.

Изменено 24 апреля, 2014 пользователем DVM-Avgoor

[Alex/AT]

Это был бордер в городские IX небольшой сети, у которой была гора трафика и пустые карманы. (4G внутрь, 2G + 2G в разные IX, PBR с некоторых ип, iptables-nat) Там стоял на то время самый современный Core 2Quad QX6800. Ксеонов вроде с таким новым ядром еще не было, или они были заоблачно не доступны, я уже плохо помню... Оно прожило чуть больше года, и было заменено на 65ую. Сон стал крепче, определенно.

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

Хотя я и на Core2 Quad Q6600 тоже спокойно 2 гига насквозь в обе стороны (т.е. 4 в сумме) с запасом еще на 1.5 дуплекса насквозь протаскивал, правда, в чистом роутинге (2xBGP FV), с PBR, но без NAT, фильтров и шейпера.

Но да - с NAT скорее всего, столько не протащишь никак. С ipt_netflow - вообще смерть. И 1.4Mpps у меня там не было, с двух гигов дуплексом получалось ~350Kpps*2 (т.е. где-то до 1Mpps с такой тачки максимум можно было выжать).

 

Кстати, вопрос не в тему: а 65'я разве нормально натить умеет? На 76 с RSP720 (SUP3CXL) как-то не получилось.

[DVM-Avgoor]

Кстати, вопрос не в тему: а 65'я разве нормально натить умеет? На 76 с RSP720 (SUP3CXL) как-то не получилось.

 

Нет, на 65ой с натом все плохо, зато все хорошо с PBR для заворачивания серых в нат (чтобы белые ходили всегда прямо, а не через ненадежный писюк).

[vitalyb]

И? Это не передача опций к модулю?

э.... нет.

 

Ну взрослые люди, уже три миллиона принципиально новых обоев запилили а не ifconfig не ip не умеют поднимать лагг.

http://www.pocketnix.org/posts/Linux%20Networking:%20Bonded%20Interfaces%20and%20Vlans

 

2ая в разных дистрибах все делается по-разному

Было бы странно, если бы в разных дистрах было бы всё одинаково.

[DVM-Avgoor]

э.... нет.

 

Ок, пусть это будет передача "букв в файл".

 

 

http://www.pocketnix...s%20and%20Vlans

 

 

Эта хрень не описана ни в мане ни во встроенном хелпе ипроут, но работает.

Почему же автор не поправит описание?

# ip link add bond5 type bond
# ip link
...
6: bond5: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN mode DEFAULT group default
   link/ether 9e:1b:e9:ab:8f:ca brd ff:ff:ff:ff:ff:ff

TYPE := { vlan | veth | vcan | dummy | ifb | macvlan | macvtap |
         can | bridge | ipoib | ip6tnl | ipip | sit | vxlan |
         gre | gretap | ip6gre | ip6gretap | vti }

 

Потому что линукс такой линукс. Приличного хэндбука нету даже у убунты, они сами не знают что, где и как у них работает.

 

Было бы странно, если бы в разных дистрах было бы всё одинаково.

 

 

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

Впрочем это видимо только мне кажется логичным.

[Dyr]

Подкину в пятничный холивар ;) Меня раздражает, что линукс до сих пор не умеет description на интерфейсы вешать. Что включенный rp_filter заставляет систему всё равно возвращать ICMP unreachable на пакеты в blackhole сети. Что настройка /etc/network/interfaces в Убунту описана в мане одним способом, а в реальности происходит другим.

 

Но ведь сцуко, работает! %)

 

 

[Ivan_83]

Кто по сколько готов скинутся на новый NAT для фри и какие фичи нужны?

[s.lobanov]

зачем на него скидываться, если в линуксе нат очень хорош?

[Dyr]

Кто по сколько готов скинутся на новый NAT для фри и какие фичи нужны?

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

 

А так мне от nata нужно:

 

 

1. Скорость. Скорость, скорость, скорость. :)

 

2. Удобство управления: добавление и удаление адресов из пула, просмотр количества и качества сессий (conntrack -L или pfctl -vvss вполне достаточны), поддержка натирования "1 в 1" и "много в 1".

 

3. Поддержка работы соединений FTP и GRE через NAT.

 

4. К первому - работающая параллелизация на процессоры "из коробки".

 

 

 

 

Кстати, я посмотрел тут список заявок на Google Summer of Code'2014 от FreeBSD и вообще ничего не нашёл по сетевой части. Одно фуфло вида "а давайте портируем FreeBSD на телефоны".

 

 

[DVM-Avgoor]

Кстати, я посмотрел тут список заявок на Google Summer of Code'2014 от FreeBSD и вообще ничего не нашёл по сетевой части. Одно фуфло вида "а давайте портируем FreeBSD на телефоны".

 

 

Вы не так давно видимо с FreeBSD. "Это не надо" - ответ занимающий первое место в сообществе :)