отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

Прошу помощи - периодическое пропадание траффика между ASA ми и разрушение VPN

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

Столкнулся с проблемой при работе L2L VPN. Если кратко - иногда непроходит фаза 1 IKE, пиры подвисают в состоянии STATE: MM_WAIT_MSG2 or MM_WAIT_MSG3

Изначально есть работающая схема

ASA5505 ---- ISPs---- ASA5505

(hub)v8.3(1) (spoke) v8.3(1)

В центральном HUB настроено порядка 20 L2L туннелей в удаленные офисы, которые стабильно работают и пересоздаются при необходимости. На одном одном из туннелей

было замечено, иногда, подвисание в фазе 1 IKE. Выглядело это так sh crypto isakmp sa - STATE: MM_WAIT_MSG2 (у инициатора обмена) | MM_WAIT_MSG3 ( у ответчика обмена).

clear crypto isakmp sa не помогала

Заглянув в логи нашел:

In HUB

%ASA-4-713906: IP = SPOK, IKE SA MM:62e7e60f terminating: flags 0x01000022, refcnt 0, tuncnt 0

%ASA-4-713906: IP = SPOK, sending delete/delete with reason message

In Spoke

%ASA-4-713906: IP = HUB, sending delete/delete with reason message

%ASA-4-713906: IP = HUB Oakley proposal is acceptable

%ASA-4-713906: IP = HUB, IKE SA MM:eb11ddce terminating: flags 0x01000002, refcnt 0, tuncnt 0

( как расшифровать SA MM:62e7e60f так и не разобрался, может кто подскажет )

и такая ситуация повторялась с интервалом в минуту (т.е. попытки есть- они неудачные - пишем в лог ).

Следующим шагом было посмотреть пакеты непосредственно на внешних интерфейсах ASA ( capture .... ). здесь то все и прояснилось - если верить дампу пакетов то со стороны Spoke пакеты IKE ( UDP 500 ) уходили, но не приходили на HUB - поэтому и сессия зависала в MM_WAIT, также надо отметить что таким образом себя вели и другие пакеты ( в том числе ICMP ).

Сразу подумал на провайдера или какие то устройства между асами которые по каким то причинам блокируют трафик в одну из сторон,НО ЧТО САМОЕ ИНТЕРЕСНОЕ - после удаления и создания вновь конфигурации для туннеля на стороне HUB все пришло в норму. Пакеты ходят в обе стороны и туннель устанавливается. В одном из инцидентов проблемы были на стороне  spoke ( подвисли все 2 туннеля один в сторону HUB) при этом SSH и HTTPS на spoke работали. помогла перезагрузка устройства, после которой все туннели поднялись.

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

   Если я правильно понимаю asp drop в моем случае непоказателен тк capture  отрабатывает непосредственно на интерфейсах до обработки пакета последущими правилами.

Буду благодарен Экспертам за подсказку в какую сторону копать.

9 ОТВЕТ.

Прошу помощи - периодическое пропа

"если верить дампу пакетов то со стороны Spoke пакеты IKE ( UDP 500 ) уходили, но не приходили на HUB"

Я один раз сталкивался с чем-то очень похожим (правда, не было возможности собрать дамп, но по всем симптомам дело было именно в этом). Если клирануть - обмен ISAKMP начинался, но потом снова стопорился, пакеты явно переставали проходить (или обмен заканчивался, но спустя минуту обрывался? Уже точно не помню). Я запросил местного провайдера. Спустя несколько часов туннель вдруг поднялся и больше не падал. На вопрос "что было?" сказали (цитирую почти дословно) "партнер [то ли апстрим, то ли ОПМ] сделал нечто очень нехорошее", но деталей не дали. Видать, кто-то начал шибко глубоко забираться в пакеты... В общем, попробуйте, вдруг получится.

Ну и на всякий случай. Версия софта какая с обеих сторон? У спока есть значимые отличия в конфигурации от других споков?

New Member

Прошу помощи - периодическое пропа

С обоих сторон была версия 8.3(1), на споке заменили на 9.0(1) но похоже это непомогло.

Значимых отличий в конфигурации туннеля у спока нет. Собственно я так и несмог понять где именно проблема.

     в одном случае помогло перенастройка туннеля на HUB, в другом ( когда подвисли 2 туннеля на Spok ) перезагрузка Spoke.  Если предположить что дело в провайдере, то что меняется в пакетах после переконфигурирования туннеля.

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

     Собственно один из вопросов к специалистам - насколько можно доверять данным программы capture ?  есть ли после нее какие либо обработки пакетов или сразу буфер интерфейса.

Cisco Employee

Прошу помощи - периодическое пропа

На моей памяти случаев неправильной работы capture не было.

Такие ситуации с необъяснимыми потерями трафика на стороне ISP бывают. Если еще и ping теряется, то ASA тут конечно не при чем. Были случаи, когда ping ходил, а ISAKMP - не очень. Если бы он иногда стопорился в MM5/MM6, то я бы спросил, используются ли сертификаты. Хотя на ASA, в отличие от роутеров, IKE fragmentation по-моему включена по умолчанию. В MM2/MM3 ему нет никакой причины зависать, хотя для очистки совести можно собрать syslog ур. 7 или debug для IKEv1 (debug crypto ikev1 7, что в сл. v1 почти тоже самое, что syslog).

New Member

Re: Прошу помощи - периодическое про

Спасибо за советы, буду копать проблему дальше.

алгоритм такой:

                        1) на обоих сторонах запустить capture в котором попытатся синхронизировать обмен IKE  и выяснить  что откуда уходит и куда                                 приходит/неприходит

                         2) выполнить sh crypto isakmp sa на обоих концах туннеля и сравнить статусы с обменом  пакетами  в capture

                         3) выполнить  debug crypto ike-common    debug crypto isakmp sa 255   debug crypto ikev1 255

     Главная цель  - определить генерацию и обработку пакетов IKE phase 1

                           + уточнить направление в котором наблюдается частичное прохождение пакетов

     На текущий момент опытным путем удалось установить:

                        1) проблема появляется после обрывово связи у провайдера ( что ведет к переформированию туннеля), но не повторяется                                         регулярно
                        2) проблема уходит после переконфигурирования  туннеля на проблемной стороне или  перезагрузке оборудования, что косвено                               указывает на проблемы в  оборудовании + доступ по ssh и https к устройствам есть )

                        3) конфигурация постоянна - поэтому к ней вопросов нет

Дилема вобщем то в чем - провайдер или ASA, если провайдер тогда почему помогает перезагрузка устройства или переконфигурирование туннеля, если ASA тогда почему capture показывает нужные( правильные) пакеты которые не доходят к партнеру.Может есть еще какие либо средства для мониторинга о которых я невкурсе, буду признателен за совет.

Re: Прошу помощи - периодическое про

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

Я ведь написал выше, что уже сталкивался с очень похожей ситуацией. В моем случае помогал clear crypto isakmp&ipsec, это с точки зрения передаваемых пакетов примерно идентично вашему переконфигурированию crypto. Меня тоже безмерно удивляла эта ситуация. И проблема была совершенно точно на стороне провайдера, он подтвердил. Возможное объяснение: какое-то транзитное устройство анализирует обмен ISAKMP на L7, и начиная с определенного момента в обмене начинает блокировать трафик, пока не увидит переинициализацию соединения. Причины блокировки могут быть разные, от политики до бага.

Конечно, такое поведение невозможно объяснить, если исходить из "провайдер передает пакеты только на основании IP заголовка и не лезет глубже", как должно быть в идеальном для клиента мире.

Да и Олег подтвердил, что такое бывает, и capture вряд ли вас обманывает.

New Member

Re: Прошу помощи - периодическое про

Обязательно оставлю заявку провайдеру ( Ростелеком ), но к сожалению зная их поддержку надежда слабая.

2Dmitriy - чисто академический вопрос, если Вам помогло  clear crypto isakmp&ipsec и провайдер отлавливал и анализировал пакеты на уровне L7 - что в них могло менятся кроме  Initiatot/responder cookie ( как я заметил данный параметр меняется при начале очередной попытки )

Re: Прошу помощи - периодическое про

Есть надежда на готовые инструкции на этот счет.

По причинам - понятия не имею. Я не стал копать глубже, все равно вряд ли узнаю правильный ответ. Наверное, если бы решение затянулось, я бы поигрался с группами DH и вообще конфигурацией ISAKMP... А может, какая-то гадость следит за тем, чтобы не согласовали не-ГОСТовые алгоритмы

Если мне склероз не изменяет, в ISAKMP почти всё шлется открытым текстом. Придраться можно к чему угодно.

Cisco Employee

Re: Прошу помощи - периодическое про

Ну вот, только что пришло:

Did anyone have any VPN cases yesterday where Sprint was the ISP and caused a network outage? We have a few cases where they are corrupting packet checksums in transit, and thus, the remote peers are not processing the ISAKMP packets, despite receiving them(confirmed by packet captures). The common point seems to be Sprint ISP. This can be send in a debug message as an "Invalid Packet" and packet captures on local and remote peers confirm the invalid checksum.

Вообще, это 100% проблема ISP. MM2 означает, что мы посылаем ISAKMP, но ответа не получаем. MM3 означает, что мы посылаем и получаем, но дальше процесс не идет. Однонаправленная связь.

New Member

Re: Прошу помощи - периодическое про

Вот ссылочка с рисунком по фазам IKE обмена в cisco, думаю многим будет полезна.

http://www.tunnelsup.com/isakmp-ike-phase-1-status-messages

Незнаю насколько это влияет на процесс- в моем случае Spoke подключен к интернету через ADSL модем c использованием PPPoE, которое настроено на нем самом (модем просто пробрасывает между ADSL и Ethernet). Capture Захватывает пакеты Ethernet c MAC dst = Broadcast (ff:ff:ff:ff:ff:ff). т.е. сама упаковка в PPPoE  идет уже после capture.

517
Просмотры
0
Полезный материал
9
Ответы