CCR2004-1G-12S+2XS медленная маршрутизация между VLAN [Исправлено]

У меня те же скорости. Конфигурация: CCR2004 в дата-центре, работает на версии 6.47.10 с 10Gbps интернетом на одном порту и VLAN-фильтрованным бриджем, который подключен к PTP-ссылке вниз к магазину — это радиоканал на 6Gbps с задержкой меньше 500 мкс. В магазине CCR2004 с версией 7.1.1, тоже с VLAN-фильтрованным бриджем. На сервере в дата-центре запущен Speedtest.net, а мой ноутбук в магазине с 10GbE адаптером. Тесты скорости между ноутбуком и сервером показывают максимум около 1.2Gbps, загрузка CPU — 70–80%. Встроенные тесты скорости между CCR2004 (по выделенному VLAN) дают максимум 6Gbps, как для TCP, так и UDP в одном направлении. CPU загружен на 80–90%. Счётчики Fasttrack вообще не растут, и меня это заставляет задуматься, сколько именно CPU уходит на меж-VLAN маршрутизацию на CCR2004. В обсуждении по серии CRS300 и аппаратному разгрузке упоминалось, что fasttrack между VLAN на VLAN-фильтрованных бриджах пока не работает в версии 7.x, но над этим работают. В то же время я бы ожидал, что в RouterOS 6 это должно работать. Один из комментаторов на Reddit заметил, что ROS 6 на CCR2004 запускается виртуализировано (или эмулируется, 32-битная ОС на 64-битной платформе), отсюда и плохая производительность железа.

Судя по схеме, существует два полнодуплексных канала по 25 Гбит/с, соединяющих CPU с портовым расширителем. Если трафик проходит через CPU, максимальная теоретическая скорость маршрутизации между VLAN ограничена 25 Гбит/с. Это также говорит о том, что CCR2004 — не подходящее оборудование для управления межвлановой маршрутизацией, так как у него нет коммутаторного чипа. Маршрутизация между VLAN всегда должна выполняться на самом коммутаторе, а не на CCR2004. Исправьте меня, если я ошибаюсь.

SFP обычно являются интерфейсами с полной дуплексной связью, что теоретически означает возможность передачи на полной скорости в обоих направлениях одновременно. Для маршрутизации между VLAN это значит, что можно одновременно принимать трафик со скоростью 10 Гбит/с из исходного VLAN и отдавать трафик со скоростью 10 Гбит/с в целевой VLAN. То, что вы пишете насчёт обратного трафика для TCP-потоков, правда: ACK-пакеты из VLAN назначения конкурируют с прямым трафиком из исходного VLAN по одному физическому каналу в одном и том же направлении, а задержка ACK-пакетов снижает общий сквозной throughput больше, чем того требует “сырая” пропускная способность для этих ACK. Этот эффект можно обойти, используя UDP для тестирования реальной скорости маршрутизации/связи, а применение (большого количества) параллельных TCP-потоков тоже помогает в некоторой степени. Что касается использования объединённых (bonding) интерфейсов: большинство стратегий передачи в bonding предполагает использование одного и того же физического интерфейса для всего трафика между двумя хостами. Теоретически может быть разный физический интерфейс для разных направлений и/или VLAN, но это вопрос удачи. Единственный способ разделить трафик двух VLAN — использовать два канала, настроенные по одному на VLAN. При росте количества VLAN такая стратегия становится неудобной. Значит, bonding — это оптимальный выбор, но он может не увеличить скорость (по крайней мере для некоторых соединений… даже с L3+L4 Tx hash параллельные соединения не всегда равномерно распределяются между всеми участниками bond). Однако, с определённой удачей использование агрегации каналов может позволить тестеру обнаружить узкие места на устройстве-партнёре.

Общая проблема с использованием bonding на устройствах без коммутатора, поддерживающего bonding, в том, что добавляется ещё один уровень абстракции, который обрабатывается и так загруженным процессором… через который должны проходить все пакеты. Иногда использование bonding даже снижает производительность, и тогда единственное преимущество — избыточность соединения. При этом общая производительность маршрутизации большинства MT-устройств не впечатляет при тестировании одной высокой пропускной способности соединения. Особенно на устройствах с несколькими ядрами процессора (то есть на всех современных) настоятельно рекомендуется запускать несколько параллельных потоков тестирования (например, использовать «-P 8» при запуске iperf3 в режиме TCP). Так пакеты разных соединений будут обрабатываться разными ядрами процессора, и пропускная способность возрастёт. Кстати, в реальных условиях, когда роутер обслуживает многих клиентов, каждый из которых общается с множеством серверов, роутер обрабатывает гораздо большее количество одновременных TCP-соединений и фактически работает именно так, как в предложенном тесте (iperf3 с несколькими параллельными TCP-потоками).