Я пытаюсь использовать старый Fujitsi RX300S2 с четырехъядерным процессором Intel Xeon @ 2,80 ГГц в качестве маршрутизатора Gitabit NAT, у него есть двухгигабитный сетевой адаптер на борту через PCI-X.
Маршрутизатор также будет пересылать многоадресный трафик с внешнего интерфейса во внутреннюю сеть. Маршрутизация многоадресной рассылки обрабатывается вышестоящим маршрутизатором Cisco, поэтому маршрутизатор NAT должен только «утечь» многоадресный трафик между eth1 (исходящий) и eth0 (внутренний).
Это было правильно настроено с использованием igmpproxy, что в основном заставляет маршрутизатор L3 действовать как мост L2 в соответствии с многоадресным трафиком.
При тестировании пропускной способности у меня нет проблем с получением ~ 850-900 Мбит многоадресного трафика на 200 групп / потоков (примерно 80 000 p / s) в локальный процесс в пользовательском пространстве, который также анализирует 200 потоков в реальном времени без потери пакетов. Локальный процесс загружает одно ядро на 100%.
Потоки состоят из транспортных потоков IPTV mpeg, инкапсулированных в пакеты IP UDP. 7x188 = 1316 байт полезной нагрузки.
Но при тестировании пропускной способности в режиме пересылки, например, многоадресный трафик входит в eth1 и маршрутизируется на уровне ядра на eth0 и отправляется в локальную сеть, NAT-маршрутизатор не может пересылать весь полученный трафик.
Внешний интерфейс eth1 принимает весь многоадресный трафик ~ 900 Мбит, но исходящий интерфейс передает только ~ 600 Мбит, и все потоки страдают от потери пакетов в соответствии с принимающей тестовой машиной, подключенной к eth0.
При анализе нагрузки ksoftirqd / 3 достигает максимума при 100% ЦП, но остальные 3 ядра ниже 10%, поэтому кажется, что не все 4 ядра участвуют в нагрузке.
/ Proc / interrupts также показывает, что eth0 и eth1 совместно используют irq16:
CPU0 CPU1 CPU2 CPU3
16: 0 0 92155 208280892 IO-APIC 16-fasteoi uhci_hcd:usb2, uhci_hcd:usb5, eth1, eth0
Как видно, CPU3 обрабатывает непропорционально большое количество прерываний.
Я прочитал различные тексты, касающиеся cpu_affinity и попытки привязать ядра процессора к сетевым очередям. К сожалению, этот сетевой адаптер tg3 от Broadcom не поддерживает несколько очередей, но, тем не менее, в этой четырехъядерной системе должна быть возможность распределять нагрузку между большим количеством ядер.
Или это шина PCI-X, которая является узким местом, но если это так, то пропускная способность должна быть уменьшена как на входящем eth1, так и на исходящем eth0, а пакеты должны быть отброшены eth1, но кажется, что пакеты теряются между eth1 и eth0. Неправда, поскольку когда пакеты теряются в маршрутизаторе, / sys / class / net / eth1 / statistics / rx_missed_errors значительно увеличивается (около 1000 p / s).
Когда пересылаются только 100 каналов и около 500 Мбит, потери пакетов не происходит, а ksoftirqd / 3 потребляет всего 5-6% ЦП. Но когда перенаправляется 600 Мбит, ksoftirqd / 3 потребляет 100%, поэтому кажется, что возникло узкое место за пределами ЦП.
Разве не может быть и речи о том, что такой старый сервер может пересылать 1 Гбит UDP-трафика в одном направлении только между двумя встроенными сетевыми адаптерами? Несмотря на то, что пакеты большие, полезная нагрузка 1316 байт, что дает умеренные 80..90kp / s на 1 Гбит?
Мы отказались от сервера, поскольку по спецификации два встроенных сетевых интерфейса не должны были обеспечивать полный гигабитный трафик. Второй интерфейс был предназначен для управления.
Стандартный настольный процессор Core i5 с PCIe и двумя гигабитными адаптерами Intel i210 мог без проблем пересылать 1 Гбит многоадресный UDP-трафик.
Хотя для этого потребовалась настройка буферов RX и TX (ethtool -G) из-за скачкообразного трафика. PCIe 2x или 4x, вероятно, поможет снизить риск пропущенных пакетов из-за перегрузки шины PCIe.