+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Отслеживание соединений — значения тайм-аутов

Отслеживание соединений — значения тайм-аутов, RouterOS

TikUser

Guest

15.05.2014 11:03:00

Я изучил таймауты в Connection Tracking. ROS: tcp-syn-sent-timeout (время; по умолчанию: 5с) tcp-syn-received-timeout (время; по умолчанию: 5с) tcp-established-timeout (время; по умолчанию: 1 день) tcp-fin-wait-timeout (время; по умолчанию: 10с) tcp-close-wait-timeout (время; по умолчанию: 10с) tcp-last-ack-timeout (время; по умолчанию: 10с) tcp-time-wait-timeout (время; по умолчанию: 10с) tcp-close-timeout (время; по умолчанию: 10с) Linux (iptables, Vyatta, …): close timeout = 10с close-wait timeout = 60с established timeout = 5 дней fin-wait timeout = 120с last-ack timeout = 30с syn-received timeout = 60с syn-sent timeout = 120с time-wait timeout = 120с Как видите, значения Mikrotik довольно агрессивные. Так в чём подвох? Что Mikrotik знает, а остальные нет?

davidnvega

Guest

17.02.2015 23:16:00

Спасибо за всю эту информацию, она очень полезна. У меня проблемы с настройкой аварийного переключения. У меня настроен баланс нагрузки PCC с рекурсивной маршрутизацией. Когда один из провайдеров падает, соединения всё равно устанавливаются через него. Мне нужно уменьшить таймауты, но я не знаю, какие именно значения нужно изменить и какие риски при этом могут возникнуть. Можешь помочь? Спасибо!

Feklar

Guest

18.02.2015 15:54:00

Спасибо за всю эту информацию, она действительно полезная. У меня возникли проблемы с настройкой отказоустойчивости. У меня есть PCC load balance с рекурсивной маршрутизацией. Когда один из ISP отключается, соединения все равно устанавливаются через упавшего провайдера. Мне нужно установить более короткие таймауты, но я не знаю, какие именно значения менять и какие риски это может повлечь. Можете помочь? Спасибо!

Проблема в том, что роутер запоминает, куда он отправлял пакет раньше, и какую NAT-правило к нему применял. Лучшее решение — очистить таблицу отслеживания соединений для этих конкретных пакетов, чтобы к сессии применилось правильное NAT-правило и связь могла продолжиться. Что-то вроде этого сработает в скрипте при переключении:
/ip firewall connection remove [find reply-dst-address~"^<PUBLIC IP OF WAN>"]

PeterFreeman

Guest

24.10.2018 18:38:00

Всем привет, у меня проблема с подключениями, особенно с SIP 5060, которые не прерываются по таймауту. Порты SIP-сервиса отключены. Моя АТС сбрасывает SIP-транк, но в таблице подключений соединение всё ещё отображается как активное. Как только я удаляю, казалось бы, «зависшее» соединение, SIP-транк восстанавливается, и всё работает нормально. Соединение похоже никогда не прерывается по таймауту, но при этом трафик идёт в одну сторону, двунаправленного потока нет. Есть идеи, как «сбросить» такое соединение, когда оно попадает в такое состояние? Спасибо, Пит.

msatter Guest	#5 0 24.10.2018 18:44:00 Это SIP-соединение по TCP или UDP? TCP поддерживает функцию «keep alive».

PeterFreeman

Guest

24.10.2018 19:17:00

Соединение, которое я вижу — udp:5060. Если я его отключаю, SIP-транки снова начинают работать. Сейчас они запущены, и, похоже, соединение перезапускается примерно через минуту, поэтому таймер соединения доходит до примерно 02:00 и затем начинается заново. Пит.

PeterFreeman Guest	#7 0 24.10.2018 19:18:00 Когда данные устарели, показатель «Orig./Repl. Bytes» односторонний. Пит.

PeterFreeman

Guest

24.10.2018 19:56:00

Я сократил время отслеживания UDP-потока до 30 секунд, и, судя по всему, это работает, то есть соединения теперь покидают трекер. Буду следить в течение следующей недели, чтобы понять, будут ли у PBX ещё какие-то проблемы. Кто-нибудь знает, к чему обычно приводит установка времени отслеживания стрима на 00:00:30 вместо 00:03:00? Ах да, если кто спросит — у меня стоит версия 6.42.9. Спасибо, Пит.

msatter Guest	#9 0 25.10.2018 11:14:00 Когда у тебя есть VoIP, ты можешь звонить, и соединение устанавливается. Если тебе звонят, соединение должно быть активным, и твой VoIP-сервер обновляет его каждую минуту. Оно не устаревшее, а просто ждёт звонка. Теперь ты выставляешь таймаут на 30 секунд, что означает, что в течение этих 30 секунд ты становишься недоступен, потому что соединение не слушает. У меня так же: мой VoIP переподключается каждые 5 минут, а стандартный таймаут — 3 минуты. Чтобы не быть недоступным в течение 2 минут, я настроил резервное подключение NAT, которое принимает звонки на UDP 5060 и перенаправляет их на VoIP-сервер. Мой совет — вернуть стандартные настройки, и тебе нужен минимум 1 минута таймаута, чтобы покрыть 1 минуту обновления.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры