Сергей: Сергей, если у вас цель подкрутить что-то в настройках ядра, то боюсь, тут никто помочь не сможет. А если есть цель всё-таки разобраться с разрывами, то стоит начать с каких-то более простых проверок.
У нас в конторе фря на generic-ядре прокачивает трафик от 800-1000 клиентов практически без какого-либо тюнинга, через NAT на базе pf. В пике трафик доходит до 1.2 гигабита. Ни в какие лимиты не упирается, и не требуется крутить никакие настройки ядра. Вы правда считаете, что у вас в корпоративной сети будут проблемы с лимитами ядра или сетевой подсистемы?
Если фря упирается в какие-то лимиты, то она обычно на это жалуется в логах. Вы же утверждаете, что в логах ничего нет. Значит, вероятнее всего, ни в какие лимиты фря не упирается, и ядро тут ни при чём. Равно как и тюнинг сетевых параметров.
Я бы начал дебажить такую проблему с выноса проблемной подсети на другой роутер. Если проблема там исчезнет -- тогда можно вернуться к версии, что проблема на фре.
Что касается добротности сети... Любое оборудование может создавать проблемы. И циски и джуниперы ценой больше чем в пол-миллиона тоже иногда глючат.
Сергей: Я не очень понимаю вашей боязни tcpdump-a :-) Если у вас есть примерное время, IP источника, IP и порт назначения -- там пакетов будет не настолько много, чтобы в них утонуть. Я сомневаюсь, что банк-клиент или аська генерит огромное количество пакетов ;-)
Тут ещё есть такой момент. То, что "раньше работало, а после переустановки системы перестало" -- это не факт. Я как-то после апгрейда Squid с 3.2 до 3.3 полтора часа сношался с отсутствием интернета. Оказалось, что пока шёл апгрейд, у провайдера упал канал, и интернет отвалился как класс. Пока я не запустил пинг на какой-то внешний сервер, я об этом не знал, и продолжал с выпученными глазами ковырять конфиги прокси :-)
А, так у вас там ещё и wi-fi. Тут всё ещё хуже. Может, ваши соседи через стенку поставили микроволновку с плохой экранировкой, и разогревают себе завтраки с утра. Микроволновка фонит и ломает вам wifi-канал.
Короче, есть предложение поставить wifi-сеть на отдельный маршрутизатор. Какой-нибудь самый простой бытовой. И посмотреть, будут косяки продолжаться, или нет.
Сергей: Насчёт выдёргивания информации из лога файрвола -- у вас есть IP источника, IP и порт назначения и примерное время обнаружения проблем. По-grep-айте по логу на предмет соответствующих изменений.
Также можно tcpdump в фоне повесить, задав ему один из бухгалтерских IP как source и IP асечного сервера или клиент-банковского как DST. И потом смотреть логи сессии.
Кроме того, если я правильно понимаю логи вашего named, то вот это: "client 192.168.113.177#55062 (www.google.com): error sending response: host unreachable" означает, что DNS-сервер не смог отправить ОТВЕТ клиенту по причине того, что клиент (192.168.113.177) недоступен. У вас там флаппинга по маршрутизации какого-нибудь нет, чисто случайно?
HiMem-74: Да, неправильно вас понял. Я подумал, что вы скриншоты со 100% загрузкой ЦПУ приводите с физической машины, чтобы показать, как выглядит 100%-ая загрузка :-)
Сколько физических ядер на хосте есть? У вас хост показывает общую нагрузку суммарно по всем наличным физическим процессорам. Тогда как виртуалка мапится своими vCPU на конкретные процессорные ядра. Вполне может быть так, что у вас 32 физических проца, из них 4 замаплены на виртуалку с SQL-сервером, и пашут как папа Карло. А остальные 28 стоят в сторонке и неторопливо курят. Соответственно, хост покажет небольшую загрузку (большинство ядер ведь стоят), а в конкретной виртуалке будет под завязку. Кроме того, в настройках VM выставляются CPU limits различные, которые ограничивают использование конкретной виртуалкой процессора. Посмотрите, что у вас там в них прописано. Ну и для верности -- откройте perfmon и постройте график загрузки по всем физическим ядрам. Я думаю, вы увидите, что всего несколько ядер загружены под завязку, а остальные работают куда менее интенсивно.
Konstantin18ko: Н-да, действительно, пишут, что G3 не умеет грузиться с USB. Это печально. Похоже, это довольно старый сервер. Он точно понимает DVD-болванки? Насколько я помню, Win2008 на CD не влезает по размеру.
Если понимает, но не грузится -- возможно, привод действительно битый. Или отключён -- в BIOS или аппаратно от порта на материнке. Привод виден в BIOS?
balkan: "Как я понял, при попытке отправить мой почтовый сервер связывается с IP.36, который перенаправляет его на IP.24." Нет. ПРосто ваш сервер пытается сначала доставить письмо на .36, так как это более приоритетный MX-сервер для домена получателя. В ответ получает ошибку. Потом пробует доставить письмо на второй по приоритету MX -- relay2 (он же .24). И тоже получает ошибку. Согласно логу -- в обоих случаях ошибка происходит из-за того, что reverse check не проходит. В логе tcpdump я вижу обмен в обе стороны -- и от вашего сервера на 25 порт получателя, и от получателя на ваш 25-ый порт. Конечно, это может быть из-за того, что в тот же момент кто-то ОТТУДА слал письмо на один из ваших ящиков. Но может быть и свидетельством попытки reverse check со стороны получателя, которая обламывается.
Есть какой-нибудь полный почтовый лог обмена между вашими серверами? А то я так понимаю, что у вас exim настроен так, что раскладывает информацию по разным файлами журналов. Как-то не хватает полной картины.
Ну я так понимаю, у вас все подключения сходятся в одну точку -- туда, где DHCP-сервер стоит. Что будет, если эта точка отвалится? Полагаю, что развалится вообще вся сеть, и филиалы также потеряют связь друг с другом.
Ну то есть, вы в комментарии говорите, что "не нужно настраивать кучу DHCP-серверов на роутерах для раздачи нужной пачки параметров клиентам", а в посте спрашиваете, как сделать так, чтобы при отвале канала связи Микротик сам начинал работать как DHCP-сервер. А для этого вам всё равно придётся его настроить и прописывать там всю эту пачку параметров :-)
По теме: насколько я вижу, такого функционала в микротиках нет. Но теоретически, можно нарисовать скрипт, который будет периодически проверять доступность DHCP-сервера и если он недоступен -- отключать DHCP relay и включать DHCP-сервер. Но на мой взгляд -- гонять DHCP-трафик через WAN -- идея не самая светлая. И поскольку вам всё равно придётся DHCP-сервера настраивать на каждом микротике -- я бы заморочился делением всей сети на IP-подсет и последующую сборку их с нормальной маршрутизацией воедино.
Судя по всему, удалённый сервер пытается сделать reverse check адреса отправителя. У вас это только отправляющий сервер, или он же отвечает за приём почты на тот домен, с ящика которого вы пытаетесь отправлять письма?
