severegor, попробуйте с флешки загрузить любой дистрибутив Linux, работающий без установки, и поработать в нем какое-то время. Если там тоже будут проблемы с интернетом, то дело не в компьютере и операционной системе.
И как пропадание сети выглядит? Теряется линк на сетевом адаптере, или нет? Нулевые ли счетчики ошибок и отброшенных пакетов на сетевом адаптере (можно посмотреть в Windows с помощью команды "netstat -e" в командной строке. Возможно, что-то содержательное можно увидеть в логах модема, к которому подключен компьютер? Может быть, это вообще проблемы в зоне ответственности провайдера (в случае потерь пакетов это можно выявить, запустив одновременно бесконечный ping до локального ip-адреса, например, роутера и какого-то ресурса в интернете, или с помощью команды pathping в Windows и mtr в Linux), которые не заметны на других устройствах?
На первый взгляд, все должно быть хорошо. Возможно какая-то специфика GNS3 влияет. Очень давно уже не имел с ней дела.
Попробуйте на forum.nag.ru спросить, там сетевики сидят, если грамотно сформулируете вопрос, могут помочь.
А еще теоретически проблемы могут возникать из-за КриптоПро (сообщения об ошибках с источником ssp могут быть от него). По крайней мере, сообщения об этом есть - https://www.cryptopro.ru/forum2/default.aspx?g=pos...
Причин может быть множество, начиная с некачественного патчкорда, окислившихся или грязных контактов в коммутаторе, блока питания в коммутаторе, в котором конденсаторы на "последнем издыхании" и т.д. Это в случае, если сетевой адаптер теряет линк.
Совет из разряда "пальцем в небо". Попробуйте в настройка сетевого адаптера отключить все, что похоже на "Green Ethernet", "Energy efficient ethernet", в общем все технологии энергосбережения, а также заодно и "Flow Contol" (или по русски - управление потоком). Зачастую помогает от подобных проблем.
Циска почему-то не видит ответов от Radius-сервера, или не понимает, что они ей приходят. Сетевая связность между циской и радиусом нормальная? Настройки файрвола не могут что-нибудь блокировать?
Судя по логу, FreeRadius отрабатывает и отсылает в ответ на циску ответ с Access-Accept
Конфиг и логи на циске посмотреть бы.
Еще можно включить на ней Radius Debugging - https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/...
mikrotadmin, а знакомый хотя бы будет в курсе о такой "проверке"? Если на его серверах живет не только ваш сайт, то может получиться неудобно.
Проверку пропускной способности канала описали выше - это команда /tool traffic-generator
А насчет проверки по http - конечно запустить N копий скриптов с командой /tool fetch в бесконечном цикле. Но во первых, у микротика ресурсы CPU могут закончиться раньше, чем у сайта, во вторых - лучше все же использовать более подходящий инструмент. Способов масса, начать можно хотя бы с поиска по фразе "http benchmark tool". Есть даже сайты для этого. И выше ответ тоже дали.
Общего ответа тут вряд ли получится дать. Конкретно здесь я посмотрел html-код страницы, увидел, что движок - Drupal, и нагуглил дефолтный URL для RSS у этого движка. Это сработало.
Павел, количество ядер, которые фактически будут выделены виртуалке, определяется как произведение указанных в настройках виртуалки количества ядер на количество сокетов.
Павел, зависит от того, сколько задача требует. В большинстве случаев достаточно 1-2 ядра (1 сокет, N ядер), если нужно больше, то обычно это явно указано в требованиях разворачиваемого образа виртуалки или софта, который будет в ней работать. Больше 8 ядер нужно каким-то специфическим высоконагруженным сервисам.
Я думаю, проблема в том, что когда прилетает обратный трафик от промаркированного соединения, микротик не понимает, что это соединение уже промаркировано, и переназначает метку в соответствии с правилом, которому соответствует пакет. Т.е. на исходящий трафик срабатывает то правило, которое ожидалось, на ответный - маркирующее трафик по умолчанию. Чтобы этого не было, должно быть либо условие connection-state=new на всех правилах, маркирущих соединения, либо как вариант, должно быть добавлено условие connection-mark=no-mark ко всем таким правилам. Первый вариант конечно лучше. Соединение должно маркироваться в момент его создания, а не при получении каждого относящегося к нему пакета.