непонятные лимиты
 

такая ситуация:
есть сервер PDC на нём крутиться Centos c почтой
и есть клинты на винде с почтовиком мазила сандерберд
проблема заключается в том что если попытаться проверить почту два раза подряд с маленьким интервалом времени
то появляется ошибка "заданный сервер не доступен"
тоже самое при отправке письма, одно отправить получается, а если второе следом то так же сервер не доступен.

помогает fix от ms для сброса TCP стека
хотелось бы всё же разобраться, что является проблемой.
может твик реестра какой или ещё что. или защита centos срабатывает ?

Похоже, фаер на центосе настроен лимитировать количество соединений с хоста. Это легко проверить, сделав листинг правил iptables -nvL -t filter.

это может быть причиной если на ПК пропатчен TCP на 100 соединений?

проблема в том, что на части ПК всё работает и почту можно хоть каждую секунду запрашивать, а на части нет.

проверил на проблемных ПК полуоткрытые соединения, всё стандартно 10 соединений

Что вы имеете ввиду под этим? Установлен максимум в 100 одновременных соединений на данном конкретном хосте? Да, может, если из-за лимита на хосте соединения принудительно преждевременно закрываются, а новые открывать сервер своими правилами запрещает. Но зачем гадать, если можно проверить. Включить в фаере логирование (если ещё не включено) правил DROP, попытаться воспроизвести ситуацию, одновременно смотря лог.

vadblm,
проблема в том что доступа к серверу не имею
а патч проверил, нет его, т.е. кол-во соединений 10.

для эксперимента накатил данный патч на рабочей системе, почта так же продолжает работать,
т.е. дело не в этом.
может кеш какой сидит в реестре? и его сброс помогает.

Обратитесь к тому, кто имеет. Если между вами и сервером есть ещё какой-нибудь фаервол, обратитесь также и к его администратору. Словом, обращайтесь с проблемой к админу, а не на форум, админ вам сразу даст инфу — есть ли ограничения и какие, а мы тут можем до второго пришествия гадать.

не тот случай, проблемы мои так как часть ПК почту получают, значит косяк локальный.

Как вы можете быть в этом уверены, не видя логов с сервера/фаервола? Чтобы такое заключение сделать, нужно сначала убедиться, что действительно пакеты не доходят до сервера, а не дропаются им (или фаером по пути) по какой-то причине.
Вовсе не обязательно, на "везучей" части ПК м.б. меньше соединений устанавливается, что позволяет не превышать лимит.

Во всяком случае, проблему надо рассматривать со всех сторон, хотя бы для того, чтобы исключить часть возможных причин. У вас что-то личное, раз вы не хотите привлечь к решению проблемы админа почтовика? Это ж его работа.

Ну можно пойти и сложным путём, поднять в локалке сниффер (WireShark например) и смотреть, что происходит с пакетами.

я то не уверен, это как говорится проблемы индейцев.

нет не личное, просто сложно в большой компании кого то убедить когда проблема из тысячи ПК только у меня.
ни кто этим заниматься не будет. проще попросить переустановит систему на всех ПК или применить тот самый фикс.
кстати возможно зря я его предложил применить, может тогда докопались до истины.

мне бы хотя бы подсказать где может крытся такая проблема на стороне пК, есть полный реестр до фикса и после, но изменений столько что всё перепроверять не реально.

возможно таких параметров реестра отвечающих за какой нибудь кеш или что то подобное не так много, и я бы сравнил их на разный ПК.

вот нарезал из полного реестра ветку TCP до и после фикса
может какие изменённые параметры покажутся подозрительными ?

Не надо себя позволять опускать до уровня "индейца". Подход "я человек маленький, потому буду терпеть" никуда не годится. Раз вы работаете в крупной компании с тысячами сотрудников, у вас должен быть issue tracker, заведите тикет с описанием проблемы на админов почты, если нет прав — на своего непосредственного начальника. С полным описанием и предположениями, вроде того что я дал. Тикет уйдёт по назначению — будут решать, вернут с резолюцией "проблемы индейцев" — умываете руки и сидите на попе ровно, подыскивая новое рабочее место с адекватным отношением к работе.

vadblm,
это всё понятно. вчера чуть ли не директор депортамента сидел со мной всю ночь, причина найдена не была.
посмотрите пожалуйста приложенные мною файлы, может что то отберете а я методом деления по полам определю виновника.

Не умею в винду, увы. Но не думаю, что проблема в каких-то хитрых настройках хоста. Сервер, как я теперь понимаю, удалённый? Между ним и вами куча хопов, из которых каждый может теоретически резать/терять? Пока могу предложить поиграться на хосте с MTU в сторону уменьшения.

нет, сервер находиться не далеко, но доступ ограничен.

Тогда расчехлям сниффер. Слушаем сеть, потом фильтруем пакеты сначала у "везучего" хоста, потом у "невезучего" и сравниваем, в чём разница.

проблема в параметре реестра Tcp1323Opts

НАШЁЛ!!!!
выгрузил и сравнил два реестра
потом все изменённые параметры делил на два и применял, ребутал, проверял


всему виной параметр в реестре
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
"Tcp1323Opts"=dword:00000003
> Параметр Tcp1323Opts определяет поддержку увеличенного окна TCP в соответствии с RFC1323.
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
> Tcp1323Opts="1" (DWORD, рекомендуемое значение - 1 окно TCP масштабируется без временных меток (timestamps), 0 - выключить RFC1323 опцию, 3 - окно TCP масштабируется с временными метками). Значение параметра - 3 может помочь в некоторых случаях, когда растут потери пакетов.
по умолчанию в системе идет значение ключа 3
http://technet.microsoft.com/en-us/libr ... 38205.aspx

хотя не понятно, рекомендуют 1 а по умолчанию идет 3

да и везде на форумах пишут, что значение 3 ускоряет работу сети, папки сетевые быстрее открываются и прочее.
но в данном случае приводит к таким проблемам.
выставил значение ключа в 1 и почта заработала, вероятно с 0 тоже будет работать.


вывод - на Centos из новой заливки собирая фаервол пытались защитится от DDOS и внесли параметр
# Запрещаем TCP timestamps, RFC1323
echo 0 > /proc/sys/net/ipv4/tcp_timestamps