Имеется несколько офисов, соединенных по схеме "звезда". Везде стоят DFL-260E, соединение от Офиса1 к ОфисуN всегда делается через 2 канала (обычно основной выделенный и резервный через Интернет) по Инструкции "IPSec VPN failover" http://www.dlink.ru/ru/faq/85/575.html

Наблюдается такая проблема: если долго не работает основной канал, то работа по резервному происходит с короткими разрывами 1 раз в 55 мин. (примерно), т.е. интервал разрывов немного меньше чем 1 час. После разрыва связь восстанавливается через 1-3 мин (иногда немного дольше).
Проблема наблюдается не только на каком-то конкретном ОфисN, а на нескольких (замечено по статистике за последний год, сбои основного канала происходят не слишком часто и не одновременно на разных направлениях).
Спасает в таких ситуациях программная блокировка основного маршрута (включая все сопутствующие несколько объектов - IPsec и т.п.) на DFL, но этот способ довольно сложный и весьма не удобен.

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

Параметры IPsec Lifetime = 3600 sec, IKE Lifetime = 28800 (т.е. как рекомендовано в Инструкции). При этом если оба канала исправно работают - никаких разрывов не наблюдается

Что сможете посоветовать, на какие параметры обратить внимание?

1. Замечание, не имеющее прямого отношения к теме: У вас на всех каналах IPsec сделано MTU=2000, как рекомендуется?

2. Надо смотреть и анализировать логи в моменты разрывов.

3. Можно поставить на мониторинг и, следовательно, автоматическое отключение маршруты, через которые работают IPsec. Это скорее как костыль для вспоможения, т.к. Вами замечено, что это помогает стабилизировать связь. Однако, это и само по себе не нанесёт вреда, т.к. отключение неработающего маршрута никому не вредит.

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

С какой периодичность синхронизируется время и с чем?
Как версия - синхронизация от разных источников и на 55 минуте резкий скачок времени друг относительно друга.

у нас этот параметр поменьше, возможно по умолчанию стоит:
Interfaces->Ethernet MTU=1500 (для wan (основной канал), dmz (резервный канал), lan)
Interfaces->IPSec MTU=1500 (для основного) и MTU=1420 (для резервного)

Если честно, в доках не встречал такую рекомендацию и пока не очень она понятная. Обычно, в доках указывают значения <=1500).
По идее, MTU для Ipsec должен быть меньше физического интерфейса. Или Вы имеете в виду, что тогда и для Interfaces->Ethernet надо будет поставить MTU больше 2000?

Если не затруднит, просьба немного подробнее пояснить эту Вашу мысль по поводу MTU - почему такой большой требуется?

Логи, конечно, смотрели в момент разрывов, но в данный момент точно воспроизвести ошибку не смогу, надо дождаться повтора проблемы
Пока увеличили IPsec Lifetime до 10800 sec, чтобы посмотреть не оно ли влияет

как оказалось, время не очень то и синхрится. До сих пор были уверены, что оно только на логи влияет. Сегодня по письмам от системы мониторинга каналов еще раз посмотрел - время 55 мин до след. разрыва конечно не всегда именно такое - скорее оно в диапазоне 52-56 мин, т.е. это не какая-то точно повторяющаяся цифра от сбоя к сбою.
На всякий случай выровнял везде время.

Интересное замечание. Начал изучать вопрос, в том числе и с поиска новых версий прошивок. Вот тут нашел упоминание про последнюю версию v10.22.01.04. А до 10-й - выходили 2.60, 2.40, 2.30 (как я понимаю, это тоже WW версии) - на указанном выше сайте есть перечень всех версий и даже список доработок

инфа взята с сайта http://dlink.ua/dfl#settings на который ведет одна из рекомендованных к первичному изучению ссылок поста форума viewtopic.php?f=3&t=159384

Вы действительно не рекомендуете использовать прошивки позднее 2.27 (это 2011 год)? Почему, если не секрет?

Речь о Plain text MTU в настройках IPsec. Её значение равное 2000 исключает лишнее дробление пакетов и способствует более стабильной связи. Здесь, на форуме много тем об этом, если постараться, то можно найти здесь ссылку на статью-первоисточник на английском. Если интересуют подробности, поищите на форуме "ipsec MTU 2000".

Хорошая мысль. Надо менять на обоих устройствах, которые держат канал Ipsec.

Мало выровнять. Настройте синхронизацию времени на всех устройствах. Хорошо работает как от D-Link (pre-configured timesync server), так и от внешних источников (типа ru.pool.ntp.org).

Приятно, что вы обращаете внимание на подпись. Однако, там речь о предыдущей линейке устройств DFL. Для текущей линейки, включая ваш DFL-260E, лучше использовать самую последнюю (меньше глюков, больше фич) WW (сильнее шифрование) версию.

И кстати, да! Прошейте на всех устройствах одинаковую, желательно самую свежую WW версию прошивки. На данный момент это
Firmware: DFL-260E A1/A2 FW v10.22.01.04 (for WW)

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

Идея примерно в следующем: mtu для IPsec теоретически должен быть меньше MTU на физическом интерфейсе на размер обертки IPsec. То есть некий пакет при необходимости "обертывается" IPsec заголовками и уже эта упаковка должна пролезть через физинтерфейс... либо ее придется рубить и передавать частями.
В ситуации MTUipsec < MTUинтерфейса получается что пакет длиной 3000 вначале порубтся на два, потом каждая половинка завернется в заголовки IPsec и потом уже они полетят через физику, а вот в ситуации MTUipsec > MTUинтерфейса - пакет большего размера вначале будет завернут в IPsec, а уже потом порубится на части. Итого накладных расходов на оборачивание будет меньше.






У меня в свое время была такая шняга с E1 забыли прописать источник синхронизации... все ничего но через недели-месяцы начинались проблемы с факсами...

Во первых, хотел бы поблагодарить всех принимающих участие в обсуждении, ваши оперативные (!) советы очень полезны и очень надеюсь, помогут нам побороть нестабильность связи!

ipsec MTU поставил 2000, по рекомендации. Поиском по форуму удалось вычислить исходный ссылаемый документ - вероятно это "Cisco.Press.Comparing.Designing.and.Deploying.VPNs.Apr.2006" (прочесть его правда было нелегко, он в CHM-формате, который теперь MS не очень жалует, открыть удалось почему-то только под WinXP, пришлось конвертить в PDF). Там действительно есть кое-что по вариантам дробления пакетов, хотя найти варианты по размеру MTU порядка 2000 там, увы, не удалось. Видимо, это действительно "эмпирическое" значение, не совсем пока понятным образом как влияющее именно на стабильность соединения. По поводу лишнего оверхеда при оборачивании - понятно, спасибо за пояснения, но ведь это может только влиять на эффективность использования канала. Думаю, надо подождать сбоев (или найти время для его имитации) и посмотреть, насколько это будет работать в плане стабильности.
Синхронизацию времени также настроил. Конечно, все изменения с обеих сторон канала делаем.
Новую прошивку будем ставить последовательно.
Конечно, будет потом трудновато выяснить, какое конкретно изменение повлияло (если поможет), было еще увеличение IPsec Lifetime до 10800 sec. Но это уже мелочи жизни.

Отпишусь, когда будет какой-то результат

пока результат такой (попробовал на одном из направлений) - пока было значение MTU 2000 периодические разрывы соединения продолжались. После изменения IPsec Lifetime до 14400 (это 4 часа) разрывов не было (к сожалению, эксперимент длился немногим менее 4 час.). Наблюдаем дальше

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