Проблема Работы С Туннелями.

[demda]

Здравствуйте! Есть такая проблема: имеется координатор HW 1000 за которым стоит большинство клиентов все клиенты в основном расположены за динамическим НАТ. Есть координатор HW2000 за которым есть некоторые туннелируемые ресурсы все клиенты и координаторы между собой связаны по ТК. Проблема состоит в следующим: после долгого простоя клиент не может пробится к туннелируемому ресурсу пока в клиенте не проверишь доступность координатора за которым туннели. Пробовали: на клиентах уменьшать период опроса координатора (допустимый таймаут....) - не помогло. . Частично помогает только перестановка у клиента сервера адресов и маршрутизирующего координатора на тот сервер на котором туннели, частично потому, что есть еще много координаторов с туннелями (сеть очень большая) соответственно эта трабла начинает творится с другими координаторами. Не пробовали только на координаторе (который для клиента является маршрутизатором и сервером адресов) менять параметр client_pool interval по той причине, что не верим в то что это поможет. Поможет ли если координатору в собственной секции ID поставить параметр force real? Кто с этим сталкивался помогите, а то дело пахнет уже крупным скандалом основная жалоба на это.... я понимаю, конечно, что нет проблемы доступность проверить... но клиенты привередливые очень. Заранее благодарен.

[intellegent]

А много клиентов у Вас?

Клиенты стоят за DNAT, а включена ли галочка "Весь трафик с внешними сетевыми узлами направлять через координатор"?

[AnTonN(c)]

Вот как раз параметр client_pool interval вам и поможет. Только меняйте на том координаторе, на который выбран в качестве сервера ip-адресов.

Какой порядок количества клиентов? какая прошивка (version) на координаторах?

еще пришлите вывод команды top.

[demda]

А много клиентов у Вас?

Клиенты стоят за DNAT, а включена ли галочка "Весь трафик с внешними сетевыми узлами направлять через координатор"?

Нет такая галочка не включена поскольку клиентов очень много больше 300 и боюсь, что если весь трафик к СУ начать гонять через координатор то координатор или канал просто на колени станет.

[demda]

Вот как раз параметр client_pool interval вам и поможет. Только меняйте на том координаторе, на который выбран в качестве сервера ip-адресов.

Какой порядок количества клиентов? какая прошивка (version) на координаторах?

еще пришлите вывод команды top.

Спасибо за участие!

Клиентов больше 300.

По версиям:

ViPNet Coordinator version: 3.7.1-(3029)

ViPNet iplir daemon version: 3.0-670

ViPNet mftp daemon version: 3.53-60

ViPNet failover daemon version: 1.5-1

ViPNet drivers versions:

Iplir:

3.3.3

Watchdog:

1.0.5

вывод top из admin escape

2826 root 40 0 49432 17m 7328 S 2 0.4 1035:14 mftpd

2750 root 40 0 54260 13m 4700 S 1 0.3 20:01.31 iplircfg

4571 root 40 0 2460 1252 900 R 0 0.0 0:00.08 top

1 root 40 0 1620 320 284 S 0 0.0 0:02.70 init

2 root 40 0 0 0 0 S 0 0.0 0:00.00 kthreadd

3 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/0

4 root 20 0 0 0 0 S 0 0.0 0:00.04 ksoftirqd/0

5 root RT 0 0 0 0 S 0 0.0 0:00.01 migration/1

6 root 20 0 0 0 0 S 0 0.0 0:00.24 ksoftirqd/1

7 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/2

8 root 20 0 0 0 0 S 0 0.0 0:00.00 ksoftirqd/2

9 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/3

10 root 20 0 0 0 0 S 0 0.0 0:00.00 ksoftirqd/3

11 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/4

12 root 20 0 0 0 0 S 0 0.0 0:00.00 ksoftirqd/4

13 root RT 0 0 0 0 S 0 0.0 0:00.00 migration/5

14 root 20 0 0 0 0 S 0 0.0 0:00.00 ksoftirqd/5

Насчет client_pool interval - играться этим параметром фанатично не стоит так как я думаю, что это лишняя нагрузка на канал. Там по дефолту 5 минут куда же меньше? Но это только догадки....

[demda]

Есть еще мысли?

[AnTonN(c)]

В поддержку с логами iplircfg на пятом уровне, с id клиента, примерным временем пропадания связи,выводом команды version, top, примерной нагрузкой с количеством клиентов и номером сети ViPNet.

Ребята быстро разберутся.