Павел, зависит от того, сколько задача требует. В большинстве случаев достаточно 1-2 ядра (1 сокет, N ядер), если нужно больше, то обычно это явно указано в требованиях разворачиваемого образа виртуалки или софта, который будет в ней работать. Больше 8 ядер нужно каким-то специфическим высоконагруженным сервисам.
Я думаю, проблема в том, что когда прилетает обратный трафик от промаркированного соединения, микротик не понимает, что это соединение уже промаркировано, и переназначает метку в соответствии с правилом, которому соответствует пакет. Т.е. на исходящий трафик срабатывает то правило, которое ожидалось, на ответный - маркирующее трафик по умолчанию. Чтобы этого не было, должно быть либо условие connection-state=new на всех правилах, маркирущих соединения, либо как вариант, должно быть добавлено условие connection-mark=no-mark ко всем таким правилам. Первый вариант конечно лучше. Соединение должно маркироваться в момент его создания, а не при получении каждого относящегося к нему пакета.
У меня была мысль подобные сложные временные условия записывать как SQL-выражения, с использованием операторов сравнения и функций для работы с датой. Например, для SQLite нет необходимости подклчать реальную базу для выполнения SQL-выражений, можно создать пустую базу в памяти с помощью конструкции $pdo = new PDO('sqlite::memory:');
И дальше выполнять SQL-запросы в её контексте, которые будут проверять, попадает время в нужный диапазон или нет. https://www.sqlite.org/lang_datefunc.html
Похожий эффект может быть из-за присутствия NAT или межсетевого экрана, который пропускает трафик только в одну сторону (обратный проходит, если в таблице соединений файрвола есть GRE-туннель). Как только запись об установленном соединении самоудаляется по неактивности, восстановить работу туннеля можно только с одной стороны.
iptables + ipset
Примера, к сожалению, под рукой нет, делал на прошлой работе правила фильтрафции по десяткам тысяч ip-адресов (списки Роскомнадзора), но он без проблем гуглится.
Списки ipset можно перезагружать независимо от правил iptables
fsfsfs32, в протоколе IP таких флагов нет. А в TCP и глубже транзитное маршрутизирующее оборудование в общем случае не смотрит. Впрочем их нет и в TCP. И при чем здесь вообще source routing?
Если контейнер видео - какой-то из семейства mpeg, и параметры видеофрагментов (кодек, размер) идентичны, то их можно просто склеивать в один файл или отдавать последовательно в сокет без дополнительной обработки. С точки зрения декодера это будет валидный видеопоток.
Но вообще это скорее задача, которую нужно решать на стороне браузера (как воспроизвести цельное видео из фрагментов). По крайней мере видеохостинги работают именно так.