> Нагрузка на процессор есть, это да, но если бы это влияло - то и резервный бы тоже аналогично тормозил, а он и не думает.
Тормоза в туннеле могут быть по множеству причин, а не только из-за загрузки CPU шлюза IPSEC. И почему не указано, что именно работает IPSEC-шлюзами?
800мс внутри туннеля и в это время нормальная задержка вне туннеля на пингах какого размера? И какая конкретно задержка на пингах?
Это к тому, что необходимо исключить глюки собственных IPSEC-шлюзов. "На резерве всё ok" не значит почти ничего. Статическая маршрутизация означает, что используется ручное вмешательство для переключения, а любое ручное вмешательство может иметь неограниченный набор побочных эффектов, о которых можно даже не задумываться, а эти эффекты могут иметь решающее влияние на нормализацию задержек (рестарт чего-нибудь при изменении настроек etc.)
Гарантированно можно исключить глюки собственных IPSEC-шлюзов, например, записав сниффером в pcap-файлы параллельно шифрованный и нешифрованный трафик с обоих сторон, убедившись предварительно в том, что часы на обоих сторонах синхронизированы. Затем проанализировать pcap-файлы, в которых таймстампы пакетов пишутся с высокой точностью и сравнить время прохождения одного и того же пакета на разных этапах - на входе в IPSEC-шлюз до шифрования, на выходе из IPSEC-шлюза в провайдерскую сеть уже в зашифрованном виде, на входе в удаленный принимающий IPSEC-шлюз до расшифрования и на выходе из него после расшифрования. Вот это будет правильная проверка.
И, разумеется, тесты нужно проводить в тот момент, когда проблема в наличии, а не когда всё хорошо.
Dlink DFL-260E с одной стороны и DFL-860E с другой.
Пакетом по 1400, без фрагментации, и туда, и туда. Между концами может и до 80мс иногда подниматься, но в среднем - 30мс. Задержки в туннеле не всегда увязаны по времени с задержками между концами - может быть 600-700 в IPSec`е и 40-50 между WAN`ами. А может быть 70-80 снаружи и 80-90 внутри. Бред какой-то.
"Маршрутизация статическая" - в смысле, без OSPF и BGP, но вполне автоматизировано. Мониторинг маршрута каждую минуту шлёт в этот маршрут ping, если нет ответа или latency слишком высокий - маршрут помечается как failed. Но к вопросу это отношения не имеет.
Тормоза в туннеле могут быть по множеству причин, а не только из-за загрузки CPU шлюза IPSEC. И почему не указано, что именно работает IPSEC-шлюзами?
800мс внутри туннеля и в это время нормальная задержка вне туннеля на пингах какого размера? И какая конкретно задержка на пингах?
Это к тому, что необходимо исключить глюки собственных IPSEC-шлюзов. "На резерве всё ok" не значит почти ничего. Статическая маршрутизация означает, что используется ручное вмешательство для переключения, а любое ручное вмешательство может иметь неограниченный набор побочных эффектов, о которых можно даже не задумываться, а эти эффекты могут иметь решающее влияние на нормализацию задержек (рестарт чего-нибудь при изменении настроек etc.)
Гарантированно можно исключить глюки собственных IPSEC-шлюзов, например, записав сниффером в pcap-файлы параллельно шифрованный и нешифрованный трафик с обоих сторон, убедившись предварительно в том, что часы на обоих сторонах синхронизированы. Затем проанализировать pcap-файлы, в которых таймстампы пакетов пишутся с высокой точностью и сравнить время прохождения одного и того же пакета на разных этапах - на входе в IPSEC-шлюз до шифрования, на выходе из IPSEC-шлюза в провайдерскую сеть уже в зашифрованном виде, на входе в удаленный принимающий IPSEC-шлюз до расшифрования и на выходе из него после расшифрования. Вот это будет правильная проверка.
И, разумеется, тесты нужно проводить в тот момент, когда проблема в наличии, а не когда всё хорошо.
Reply
Пакетом по 1400, без фрагментации, и туда, и туда. Между концами может и до 80мс иногда подниматься, но в среднем - 30мс. Задержки в туннеле не всегда увязаны по времени с задержками между концами - может быть 600-700 в IPSec`е и 40-50 между WAN`ами. А может быть 70-80 снаружи и 80-90 внутри. Бред какой-то.
"Маршрутизация статическая" - в смысле, без OSPF и BGP, но вполне автоматизировано.
Мониторинг маршрута каждую минуту шлёт в этот маршрут ping, если нет ответа или latency слишком высокий - маршрут помечается как failed. Но к вопросу это отношения не имеет.
Попробую сравнить PCAP`ы.
Reply
Leave a comment