crank

Разбивает ещё как. Если у интерфейса EoIP будет MTU 1500, а по факту у вас физический интерфейс не примет весь пакет целиком + заголовок EoIP, то пакет разбивается и собирается с другой стороны. При этом подрастает RTT и в зависимости от используемого каналы может ещё и джиттер вырасти. Можете тест и убедиться в этом сами.

7201 загнётся еще раньше при pptp/pppoe

Режим access не некоторых коммутаторах не примет у вас тегированный трафик.

Другой вариант делать как вы пробовали ранее. На входящих портах трафик заворачивать в dot1q-tunnel к примеру. На исходящем сделать trunk и добавить туда vlan'ы входящих портов. Плюс к этому всему выключить mac learning в этих вланах. Из плюсов этой схемы то, что можно передавать трафик в port-channel. Из минусов - отсутствие маков на свиче, которые иногда нужно посмотреть при траблшутинге.

@TRIada , а вы их просили, чтобы они пропускали комьюнити дальше? Я бы в первую очередь попросил. Возможно дадут вам такую возможность. Вот если не дадут, то спросите почему.

Точно не могу сказать, но думаю, что вполне возможно. Задайте ему вопрос.

Facebook туда же запишите. Их кэши FNA тоже стоят у некоторых операторов. Правда в РФ их нет и судя по всему не будет.

HP DL160 G6 CPU: 2 x Intel(R) Xeon(R) CPU E5520 @ 2.27GHz RAM: 16GB

Так это сделано в целях поддержки ASN32 на железках умеющих только ASN16. Если один из пиров имеет поддержку ASN32, а второй только ASN16, то первый будет все ASN32 заменять на специально зарезервированную в этих целях AS23456 - оно же AS_TRANS.

@Ivan_83 , разобрался с проблемой. Сам виноват. Причина рассыпаний была в том, что в процессах висел irqbalance, который раскидал прерывания таким образом по ядрам, что в ЧНН одно ядро в 100% улетало в soft irq. Вырубил irqbalance. Раскидал прерывания скриптом.

Собрал новый сервер. Система Ubuntu 18.04. По началу текли дрова сетевой ixgbe. Обновил до последней версии. Сейчас периодически в ЧНН начинает сыпаться картинка на всех каналах. Помогает перезапуск msd_lite. Сетевая карта X520-DA2. Два порты собраны в лаг. Тюнинг сетевого стека sysctl -w net.core.rmem_default=8388608 sysctl -w net.core.rmem_max=16777216 sysctl -w net.core.wmem_default=8388608 sysctl -w net.core.wmem_max=16777216 sysctl -w net.ipv4.tcp_rmem="8192 87380 8388608" sysctl -w net.ipv4.tcp_wmem="8192 87380 8388608" sysctl -w net.ipv4.tcp_mem="8388608 12582912 16777216" sysctl -w net.ipv4.udp_mem="8388608 12582912 16777216" sysctl -w net.ipv4.udp_rmem_min=16384 sysctl -w net.ipv4.udp_wmem_min=16384 ethtool -G enp7s0f0 rx 4096 tx 4096 ethtool -A enp7s0f0 autoneg off rx off tx off ethtool -G enp7s0f1 rx 4096 tx 4096 ethtool -A enp7s0f1 autoneg off rx off tx off msd_lite запускаю с помощью systemd. Юнит запуска [Unit] Description=MSD Lite After=network.target [Service] LimitNOFILE=262144 WorkingDirectory=/opt/msd ExecStart=/opt/msd/msd_lite -c msd_lite.conf ExecStop=/bin/kill -9 $MAINPID Restart=always RestartSec=10 [Install] WantedBy=multi-user.target Все потоки пишутся в /tmp, которая является tmpfs. Пока замечено, что проблема появляется когда кол-во клиентов приближается к 2 тыс. Трафика при этом 6-7 Гбит. На этом же серваке выжимали из msd_lite 15 Гбит, но система крякнулась в один прекрасный момент и потребовалась переустановка. PS На всякий случай включил запись логов, чтобы можно было посмотреть в момент проблемы.

Спасибо за инфу. Сейчас жду на тест. Если нужно, могу сдампить snmpwalk как получу железку.

Слышал, что эти железки сейчас больше не выпускаются. Им на замену идут 6330. Сейчас ждём на тест S6330-h24x6c

Можно и так иметь больше 512 vlan'ов. Такое число является предельным при использовании rapid-pvst в качестве spanning tree протокола. Переключитесь в режим mst и сможете создавать все 4096 влана.

Какая версия из 9-ой ветки нужна?