none
Netscreen VPN - проблема с mapi RRS feed

  • Общие обсуждения

  •  

    Доброе время суток, проблема вот в чем:
    Есть сеть состоящая из ЛВС центрального офиса и дополнительных объединенных по средством site2site vpn. В сети ЦО находятся контроллеры домена win2k3 и Exchange2k3. Все пользователи ДО находятся в домене ЦО, только разнесены по разным сайтам. Так же они по mapi подключаются к exchange аутлуками, что бы работать с почтой.
    Пока в ЦО стоял pix515 в качестве VPN конценратора, все было ок. Волевым решением пикса была заменена на netscreen ssg 140 и все vpn переведены на нее (в ДО преимущественно установлены pix501 ).
    После этого начались проблемы с аутлуками, т.е. через некоторое время после начала работы с аутлуком он выдавал ошибку что подключения к серверу exchange ограничено … или отсутствует. В логах сервера я нашел ошибку
    Mapi session "/o=ORG/ou=First Administrative Group/cn=Recipients/cn=user" exceeded the maximum of 32 objects of type "session".

    TCPview на сервере exch показывает вот что: 

    http://manaenkov.net/downloads/tcpview.jpg


    julia - сервер exch
    west-1 - машинка из допа

    Т.е. получается что нетскрин обрубает сессии в туннеле и они не корректно закрываются, т.е. НЕ закрываются, пока не отвалятся по таймауту. По настройкам VPN все идентично с пиксой, т.е. esp-aes-sha1 + правило allow center.net dop.net ip.
    Может быть кто-нибудь сталкивался с такой засадой? Можно ли как нибудь ограничить таймаут mapi сессии и если да, то поможет ли это?? С нетскрином боролся долго и к сожалению безрезультатно Sad.

    Да, pop3 smtp и owa работают нормально, но хочется именно mapi.

    4 сентября 2007 г. 7:49

Все ответы

  •  

    Я так понимаю ошибка у вас такая вылезла

    Event ID 9646 is logged in the application event log of your Exchange Server 2003 computer when a client opens many MAPI sessions

    http://support.microsoft.com/kb/842022

    Посмотрите.

    4 сентября 2007 г. 8:13
  • To change the value of the maximum permitted MAPI sessions per user from the default, you can configure the Maximum Allowed Sessions Per User registry entry. To do this, follow these steps.

    Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

    1. Click Start, click Run, type regedit in the Open box, and then click OK.
    2. Locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
    3. If the Maximum Allowed Sessions Per User entry does not exist, do the following:
    a. On the Edit menu, point to New, and then click DWORD Value.
    b. Type Maximum Allowed Sessions Per User as the entry name, and then press ENTER.
    4. Right-click the Maximum Allowed Sessions Per User entry, and then click Modify.
    5. Click Decimal, type the value that you want to set in the Value data box, and then click OK.
    6. Exit Registry Editor.

    4 сентября 2007 г. 8:15
  • Да, я видел это, но

    If you raise the limit too high, the client program might affect the performance of the Exchange Server computer.

     

    А количество сессий mapi из допа с одного компьютера может достигать 200, т.е. считаем 200* на примерно 100 человек в допах (не считая 100 человек в центре). Умрет мне кажется exchange .. или стОит по пробовать?

    Сложность еще в том что протестировать можно только во время рабочего дня, а простой почты (в случае неудачного теста) - довольно критичен.

     

    4 сентября 2007 г. 8:36
  •  

    Увеличение числа сессий может оттянуть время наступления блокировки, но не решает проблему.

     

    Попробуйте лучше продолжить борьбу с netscreen+pix. Именно эта связка у вас не работает как надо. Измените параметры VPN, протокол шифрования, длину ключа, тип соединения наконец. Посмотрите сообщения о совместимости этих продуктов: возможно существуют конкретные рекомендации, как их подружить.

    4 сентября 2007 г. 9:45
    Модератор
  •  

    Я понимаю что не решение .. , но с нетскрином как только не изголялся испробовал все трасформсеты, выключал скрининг (фильтрацию на уровнях 4 -7 osi). Менял таймауты на 1ой и 2ой фазах VPN ... 0 эммоций Sad

    Даже запускал к себе на нетскрин инженеров джунипера, они лишь разводят руками...

     

    Причем такое поведение наблюдается только с mapi,  но ведь и клиентские машины работающие в общем (в одном) домене из допов должны создавать больше количество подкючений к dc, dns etc (опять же работа с подмапленными сетевыми дисками на сервере ЦО). но  тут проблем нет ..все ок ..

    4 сентября 2007 г. 10:00
  •  

    С помощью снифера можно записать входящий/исходящий трафик pix и netscreen, проанализировать tcp/ip сессии, и таким образом найти "слабое звено"

     

    Возможно, кстати, сессии других протоколов тоже подвисают, но это не так заметно?

     

    Еще одно предположение: посмотреть звено netscreen и сетевой карты Exchange. Возможно именно здесь идет сбой. Например, второй сервис пак Windows 2003 может оказывать негативное влияние на работу сети.

    4 сентября 2007 г. 11:30
    Модератор
  • Ну насчет снифера, мне кажется Вы погорячились. Во-первых - объем ... это ж не на одну неделю .. во-вторых сейчас центральный ВПН концентратор нетскрин и я не могу перевести даже один доп обратно на 515ую пиксу ... хотя бы из-за роутинга (дефаул гейтвеев .. и пр..)

     

    Про сессий других протоколов (сервисов) ... возможно и так .. но они ни как себя не проявляют ...

     

    У меня на всех серверах sp2 (т.е. и когда пикса была VPN концетратором exch стоял на win2k3 sp2)... но проверить стОит .. спасибо за идею ..

    4 сентября 2007 г. 12:37
  • Вы так же проверьте rcpping'ом

    4 сентября 2007 г. 13:49
  •  Sergei Manaenkov написано:

    Ну насчет снифера, мне кажется Вы погорячились. Во-первых - объем ... это ж не на одну неделю .. во-

     

    Вам нужно лишь писать заголовки пакетов SYN/ACK для VPN соединений, а их как раз не так много.

     

    Вот про отключение RSS http://support.microsoft.com/kb/927695

    5 сентября 2007 г. 5:14
    Модератор
  • А зачем их писать? Часом не с тем же смыслом что и предложение "сменить длину ключа"? "протокол шифрования"? "тип соединения наконец"? Корабль тонет, а мотросы спасают его тем, что переставляют стулья на палубе.
    -------
    Рост колличества MAPI сессий на сервере Exchange связан с кратковременными разрывами связи. Сервер не в сотоянии отследить аварийное отключение Outlook и сохраняет мертвые сессии в списке активных. Для эксперимента достаточно просто вынуть сетевой кабель из ПК и снова воткнуть. Cброс таких сессий (например по таймауту или программами) не предусмотрен Microsoft и осуществляется перезагрузкой сервера. Решение предлагаемое Microsoft http://support.microsoft.com/kb/842022 -- грубое. Предлагается только увеличить "потолок" колличества MAPI сессий после которого сервер производит отказ в обслуживании клиетна. Тем не менее это не останавливает сам прирост колличества MAPI сессий, который рано или поздно достигает потолка.
    Путем длительного исследования проблемы была выявлена связь мертвых MAPI сессий с сессийми протокола TCP, который представляет собой транспорт для протокола MAPI. Аварийное отключение Outlook вызывает в том числе зависание в состоянии "established" TCP соединения на сервере Exchange, которое по сути также являясь мертвым, продолжает висеть на сервере в списке активных. "netstat -ano" дает список всех ТСР соединений. Принудительное завершение TCP соединения имеет полезный эффект -- происходит завершение связанной с ним MAPI сессии. В этой связи на сервере Exchange необходимо внести изменения в настройки TCP\IP. Добавить в реестр параметры включающие таймер проверки существования живых TCP соединений:
    "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime"
    "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval"

    22 октября 2007 г. 7:06
  • По поводу первого абзаца ... просто смысл в том, что когда VPN был поднят на Пиксах ... такого не было ... при том что и пиксы и нетскрин ... в общем и целом сконфигурированы одинаково ..ну не суть ...

     

    Ключики реестра попробую, по результатам отпишусь ... 

     

    Пока принято решение переводить пользователей в доп офисах на pop3/smtp или owa по желанию ... 

    23 октября 2007 г. 9:24