Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Форум
    RouterOS
    Лучшие практики обнаружения недоступного узла в IPsec

    Лучшие практики обнаружения недоступного узла в IPsec

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Лучшие практики обнаружения недоступного узла в IPsec, RouterOS
     
    Deantwo
    Guest
    #1
    0
    30.05.2016 11:34:00
    У меня в сети много IPsec-туннелей, которые состоят только из роутеров MikroTik. Обычно это построено по схеме «центральный роутер», к которому подключаются «спутниковые» роутеры. Существуют разные способы настройки IPsec — например, динамические политики и прочее. Я несколько времени назад решил настроить всё с помощью статических политик и пиров, управляя этим с помощью нескольких скриптов и DNS-сервера. Всё работает нормально, но есть вопросы по оптимальному управлению.

    Главный вопрос — как лучше настроить DPD (Dead Peer Detection). По умолчанию стоит 120 секунд с 5 неудачами. Кажется, это слишком долго, и, в теории, я не хочу, чтобы центральный роутер поддерживал туннели живыми, я хочу, чтобы это делали «спутниковые» роутеры. Сейчас у меня DPD на центральном роутере отключён, а на «спутниковых» настроен интервал 20 секунд и максимум 1 неудача. Цель — быстро обнаруживать проблемы в IPsec-туннеле и быстро восстанавливать соединение.

    dpd-interval=disable-dpd  
    dpd-maximum-failures=1  
    dpd-interval=20s  
    dpd-maximum-failures=1  

    Итак, каков же лучший подход для настройки DPD? Почему в настройках по умолчанию такой большой интервал? Не слишком ли мало 1 максимальное число неудач? Должны ли настройки быть одинаковыми на обеих сторонах? Или допустим односторонний DPD? В мануале об этом мало информации, возможно, я просто недостаточно знаю. Всё, что я там вижу:
     
     
     
    kujo
    Guest
    #2
    0
    19.06.2016 09:49:00
    Как у вас обстоят дела с производительностью на канале Ipsec? Какую модель центрального роутера используете? Отправлено с моего iPhone через Tapatalk
     
     
     
    Deantwo
    Guest
    #3
    0
    23.06.2016 12:54:00
    Не совсем понимаю, какое это имеет значение в вопросе о лучшей практике. Но ладно, центральный маршрут такой: RB1100AHx2. Спутниковые роутеры в основном состоят из: RB750, RB2011iL.
     
     
     
    wispmikrotik
    Guest
    #4
    0
    08.11.2023 08:17:00
    Привет! Извини, что «воскресил» эту старую тему. В RFC я не увидел, что обязательным условием является одинаковый DPD с обеих сторон. Согласно пункту 5 RFC 3706 про протокол DPD: каждый пир может иметь разные требования к определению живости соединения. Например, пир A может требовать быстрого переключения при сбое, а пир B – более спокойного подхода к освобождению ресурсов. В DPD каждый пир задаёт свой собственный «порог тревоги» — интервал, определяющий срочность обмена DPD. Продолжая пример: пир A задаёт интервал DPD в 10 секунд. Если пир A отправляет IPSec трафик, но не получает входящий трафик в течение 10 секунд, он может инициировать обмен DPD.

    Пир B, наоборот, задаёт менее срочный интервал DPD — 5 минут. Если сессия IPSec простаивает 5 минут, пир B может инициировать обмен DPD при следующей отправке пакетов IPSec к A. Более того, на стороне macOS при DeadPeerDetectionRate = Disabled и на стороне Mikrotik с включённым DPD (60 сек., 3 попытки) DPD-сообщения доходят до macOS-клиента, и он отвечает на них корректно. RFC действительно указывает, что на эти сообщения нужно отвечать. @pe1chl, ты сталкивался с проблемами из-за разных способов настройки DPD? С уважением,
     
     
     
    pe1chl
    Guest
    #5
    0
    08.11.2023 09:17:00
    Извини, но моя память уже не та, что раньше…
     
     
     
    wispmikrotik
    Guest
    #6
    0
    08.11.2023 10:01:00
    Нормально. С тех пор уже много дождей было. Спасибо, что ответил!
     
     
     
    Deantwo
    Guest
    #7
    0
    09.11.2023 18:17:00
    О, это очень интересно. Спасибо, что поделились!
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры