Несколько локалок, связанных IPSEC VPN, в локалке A DFL-860E, в локалке B - DFL-260E, в остальных (их 6 штук) DFL-260E или PIX.
Локалки A и B связаны каждая с каждой (в том числе между собой)
На DFL прошивки 2.40.04.08-21460 Jun 4 2013. Пиксы упомянуты для полноты картины, они в этих проблемах не участвуют.

Проблема заключается в том, что в некоторых туннелях сильно различаются времена пингов через туннель и вне туннеля - на внешний адрес того же DFL. При этом в других направлениях той же DFL все нормально, например в одном направлении времена 4 и 3мс, в то же время в другом - 35 и 3-4. Вообще-то пинги в туннеле возрастали и до 60-70 и даже выше.

При этом:
- трафик на обоих концах туннеля незначителен по ВСЕМ интерфейсам и VPN
- это не задержки в локалке
- во всех туннелях политики одинаковые и минимальные (MD5, DES)
- ситуация нестабильная, вдруг все нормализуется.
- процессор и память DFL не перегружены, процессор занят на 6%, память примерно на 20%
- проблема обнаружена у DFL B (в том числе тормозит связь с A).

Все, что знаю, обшарил - ничего не нашел. Куда вообще смотреть?

PS. Может, проблему создает туча очень мелких пакетов? (Я не проверял, есть ли они) Но трудно объяснить тогда, почему это происходит только на некоторых направлениях. Потому что характер трафика шлюза на B довольно однородный - во всех направлениях, кроме A, это Voip, причем совершенно не перегруженный.

PPS. Посмотрел повнимательнее. На wan валится frame align error:


Это оно? Это же, что, проходит один пакет из 5-6?

Ваша "проблема" как-то мешает жить организации? Связь пропадает, трафик искажется, и т.п.

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

До жути.
Народ жалуется на периодически возникающие сильные тормоза в работе 1С, причем, и тогда, когда в офисе народу осталось всего ничего.
Именно разбираясь с этими тормозами, я обнаружил пинги в 60-70 мс.

что именно Вы уже проверяли, чтобы нам не перечислять уже сделанное?

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

Да, собственно, в этом плане я не так уж и много знаю. И выше написал практически все, что смотрел.

В логах ничего подозрительного не заметил.
Трафик проверил и на интерфейсах, и в IPSEC, трафик незначительный
Шейпинг трафика не делался
Загрузка процессора и памяти на DFL незначительная
Проблема как бы локализуется в конкретных туннелях: "точно такие же" туннели на обоих DFL работают в то же самое время отлично.
В локальных сетях все тихо, зафлуживания нет, пинги от DFL до внутренних узлов - нормальные.
Ошибки на wan интерфейсе вот обнаружились: много Frame Align Error, причем сыплются они тоже сильно неравномерно. Но я не знаю, что они значат. И не понимаю, почему это мешает только некоторым туннелям.
Число VPN, число IP правил и другие ограничиваемые по количеству ресурсы - незначительная часть от лимита, все меньше 10%
Сами туннели и связанные с ними правила делались клонированием и отличаются только там, где не могут не отличаться.

Больше не знаю, куда смотреть.

А что в такой сети , и нет системы мониторинга? Даже простой cacti?
Я удивлён...

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

Два вопроса:
1. Кто в DRL-260E занимается шифрованием-дешифрованием? В смысле выход на предельную загрузку по трафику VPN должен приводить к 100% загрузке CPU?
2. Есть ли возможность смотреть данные по загрузке CPU и нагрузке на интерфейс с бОльшим разрешением, чем на суточных графиках?

что бы ловить такие тормоза, надо иметь хоть минимальную систему мониторинга . хоть по интерфесам .....
в идеале если еще L2 свичи ... там тоже не плохо посмотреть .
ну и самое - NetFlow все остальное , гадание на кофейной гуще .

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

В качестве тыка пальцем в небо, но полезного тыка:

1. Сделайте на всех IPsec MTU=2000.

2. И лучше актуализировать прошивки до самой свежей стабильной на всех DFL - 11.10.01.06 for WW.
Может проблема исчезнет сама собой.

3. Т.е. проблема возникает эпизодически и на конкретных участках? Или вообще на одном?

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Конечно, лучше быть богатым и здоровым, чем бедным и больным.

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

Кое-что для анализа трафика у нас есть, и пользоваться этим мы умеем. Но как это может помочь понять процессы внутре DFL или ответить на вопрос, какая железяка в ней занимается шифрованием трафика?

К последней прошивке я пока не готов (( поставил ее на тестовую DFL, потом снес, потом опять поставил, потом опять снес...

Немного погодя вернусь к ней.

MTU увеличить? попробую вечерком.

Впрочем, собираются дополнительные сведения и картина потихоньку уточняется. На первое место выходит все-таки нестабильный канал в инет (офис расположен в жилом доме и оборудование там соответствующее), на второе - перегруз DFL именно по шифрованию.

На DFL, по моему опыту, установка более слабого шифрования ничего не улучшает.

Или я все таки не прав?

Не ясно, как такое возможно при низкой загрузке.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Боюсь, в прошлый раз, когда я собирал статистику, в одну кучу попало сразу несколько разных дефектов. То есть, из двух тормозящих каналов в одном была низкая загрузка, в другом... фиг ее разберет, ведь DFL показывает статистику, усредненную за час в своих графиках. Но там, где была низкая загрузка, там и инет притормаживал, не у меня, а где-то посреди.

Это было вечером, когда работал 1-2 человека, и не очень усердно.

Такая мысль появилась: если, при торможении канала, пинг не в туннеле дает задержку t >> нормальной задержки пинга, то пинг в туннеле (за счет того, что он передается через tcp), должен давать задержку в 2-3 раза большую.

Сегодня в этом несчастном шлюзе B я видел в разгар рабочего дня несколько другую картину: на фоне нормальных пингов периодически появлялись задержки до 60 мс, причем похоже, что синхронно поднимались задержки в разных туннелях и вне туннелей. При этом средняя загрузка туннеля была порядка 350 кбит (а что в пике - фиг его вообще знает...)

Будем для пробы подключаться к другому провайдеру. Если не поможет, возможно, постараемся купить DFL-870. Буду юзеров уговаривать переходить на работу в терминальном режиме, чтобы снизить загрузку в туннеле.

Учитывая, что 3DES - это трижды примененный DES, вроде, должна улучшать. Но это опять же вопрос к тому, кто именно делает шифрование. Если спецмикросхема, то может и не улучшать.

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