Оптимизация работы NW Client'а по WAN каналам

[Dimerson]

Встала у меня данная задачка. Буду я поднимать каналы с филиалами на VPN линках (везде CISO с аппаратными криптомодулями - в центре 3825 а в офисах от 1824 до 1720, и соответственно 3des или aes direct incapsulation). В общем-то я не собираюсь гонять файлораздачу через WAN, в данный момент взял 2 шт 1841 (HSEC-K9 - то есть куплено сразу с криптователем и IOS с AdvSecurity), воткнул FastEth<->FastEth,сделал туннельчег aes256 и мучаю макет филиальского SBS 6.6 (IP Only). SPL егоный мне не нужен - вбил в клиента IP сервера и вперед. Гоняю файлик гигабитный туда-сюда в пике вижу до 50% от 100 baseT - при этом проц на кошке в 80% то есть в норме - она отвечает на SSH итд. Проблема в том что иногда происходит дисконнект. в этот момент ошибок на циске = 0, пинг с сервером не прекращается и через 1-2 сек связь сама восстанавливается.

на сервере Oplock Lev 1 = off, Lev 2 = off.
Пока на станции я пришел к выводу о необходимости выставлять только лишь:

FileCaching = off
TrueCommit = ON
MaxTime to net = 1 sec

наблюдаю дальше.

Нет ли у АЛЛ опыта в этом направлении ?

P.S. тк господа кошководы уже год+ не разглашают детали о установленных CPU внутри железок - причем так яростно охраняют данные секреты что аж страшно (интересно как это соотносится с закогом о защите прав поребителей ?) понимаю что лучше поднимать туннели на PIX или AES каких-нибудь ибо в кошках проц стоит с производительностью тютелька в тутельку и навесив немного ACL + какойнить NAT видим что оно уже тормОзит. ну или брать кошку с запасом по бандвишу / криптобандвишу в 2 раза минимум.

P.P.S. Клиент на этой стороне 4.92 Sp2 + pkc + postfixes.
там SBS6.6 + All SP + all postfixes

P.P.P.S - от нормального режима тут еще и отличие в том, что нет SLP .. то есть мультикасты не ходят (ибо direct IPSEC encap), а удаленный сервер я не регистрирую на своем SLP DA (хотя проблем в том чтобы разрешить нет). Если на станции совсем исключить SLP из списка протоколов - хватит ли только DNS (с прописыванием в хостах) , или на предмет дисконнктов (потери map drives периодически) влияет наличие именно SLP ?

В общем буду пробовать - но гугленье и поиски на support.novell.com больше ничего не дают.

[Timur Kazimirov]

Может с фрагментацией пакетов с заголовками IPSEC связано? Причем может и со стороны раб.станции (если это W2K, то там надо EnableMTUDiscovery=1 в реестре прописывать), ну или запрещать фрагментацию для WAN-линка, что тоже не есть гуд, вообще-то.

[Charles Kludge]

http://www.ithowto.com/

[Dimerson]

Может с фрагментацией пакетов с заголовками IPSEC связано? Причем может и со стороны раб.станции (если это W2K, то там надо EnableMTUDiscovery=1 в реестре прописывать), ну или запрещать фрагментацию для WAN-линка, что тоже не есть гуд, вообще-то.

скорее всего нет. я пробовал поднимать ipsec vpn в режиме gre туннеля - там для устранения падения производительности на Tunnel Interface необходимо сказать чтонить вроде "ip mtu 1300".

Тут же direct encapsulation - то есть установлен криптомап на интерфейсе и то что попадает в ACL подвергается криптованию а ответы декриптованию.
Курение mtu в данном случае вроде как не требуется.

Сделано так для уменьшения overhead (1841 имеет не особо быстрый проц (( и хоть тресни заявленные 95мб криптобандвиша на туннеле и так не получаются а еще есть минимальные acl и NAT ) хотя есть и минусы - не ходит mcast . Посему попробую забить в клиента статически адрес SLPDA и понаблюдать.

Тимур, а случайно не знаком вам такой Борисов Эрнест Борисович из Южного ? Вроде админит в BP тамошнем ;O)

http://www.ithowto.com/

Намек понял курил ничего не нашел тчк перехожу на прием.
P.S. что с кейгеном для портлока ? )


Блин пока оказалось все прозаичнее.
В макете был 3COM Switch 16 портовый. Глючил сцукко. После N часов работы просто пинг все ок, а ping -l 1600 половина пакетов lost. Заменил на другой все ок.
Изучаем далее.