Ответ к задаче №7.6
0
16912
8
Пример процесса поиска неисправностей:
Проверяем доступность loopback’а хаба:
brno-gw1#ping 172.16.255.1 source 172.16.255.136
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.255.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.255.136
…
Success rate is 0 percent (0/5)
Ситуация со стороны филиалов:
— isakmp sa установлены
— существующие туннели между филиалами напрямую, также существуют
— трафик между филиалами не ходит
После перезагрузки хаба:
— туннели не поднимаются
— на хабе нет isakmp sa
На хабе появляются ошибки такого вида:
*Feb 25 13:07:58.323: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec’d IPSEC packet has invalid spi for destaddr=198.51.100.2, prot=50, spi=0xED9935DC(3986240988), srcaddr=198.51.101.2
То есть, проблема в том, что филиалы считают, что туннель есть и присылают пакеты в этих туннелях.
Однако, на хабе они удалились после перезагрузки и, соответственно, он не может найти туннель с SPI, который приходит в пакете от филиала.
Чтобы решить проблему, можно удалить существующие туннели на филиалах:
clear crypto isakmpИли, более грубо: выключить и включить внешний интерфейс филиалов.
Однако, это решает проблему только на этот раз. Если ситуация повторится, то проблема возникнет снова.
Решение:Чтобы сеть восстанавливалась автоматически, после того как хаб снова появится, надо сделать так, чтобы при исчезновении хаба, филиалы могли это обнаружить и удалить существующие sa.
Для этого используется функционал DPD (dead peer detection).
Пример настройки (синтаксис команды оставляем на самостоятельное изучение):
crypto isakmp keepalive 10 2 periodicСоответственно, если на всех филиалах настроить DPD, то они будут удалять старые sa и создавать новые, когда хаб вернется.
0
16912
8
Ещё статьи
8 коментариев
Полагаю, при применении команды crypto isakmp keepalive 10 2 periodic в режиме глобальной конфигурации, необходимо shut\no shut туннельный интерфейс, для того чтобы настройки вступили в силу.
Работает на Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version 15.5(2)T, DEVELOPMENT TEST SOFTWARE.
У меня в EVE, сработала только команда crypto ipsec security-association idle-time 60
пару раз проверил перезагружая хаб.
Эта почему то не работает crypto isakmp keepalive 10 2 periodic интересно бы проверить на живом оборудовании.
В EVE такой «роутер» Cisco IOS Software, Linux Software (I86BI_LINUX-ADVENTERPRISEK9-M), Version 15.4(2)T4, DEVELOPMENT TEST SOFTWARE
У меня работает crypto isakmp keepalive 10 2 periodic но только после того как опустить и поднять именно туннельный интерфейс, работает в GNS3 с Cisco IOS Software, 7200 Software (C7200-JK9S-M), Version 12.4(13b), RELEASE SOFTWARE (fc3)
Доброго времени суток.
В моем случае для создания новых SA после перезапуска хаба, я пробовал менять значения isakmp keepalive xx и isakmp policy x >> lifetime xx — не помогло. Но сработал такой вариант для этого задания (на филиалах): #crypto ipsec security-association idle-time 60 — устанавливаются новые SA. Но корректны ли такие фривольности? Ибо в хелпе для команды выдается:
nsk-obsea-gw1(config)#crypto ipsec security-association
idle-time Automatically delete IPSec SAs after a given idle period.
и как я понимаю, он должен после какой-то процедуры через 60 сек (в моём случае) пересогласовать параметры SA! При чем опять же — после процедуры, т.к глядя в sh crypto ipsec sa обнаруживается следующее:
inbound esp sas:
spi: 0xFCD218B9(4241627321)
transform: esp-aes esp-sha-hmac,
in use settings ={Transport, }
conn id: 9, flow_id: SW:9, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4477099/2950)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xCC610C9C(3428912284)
transform: esp-aes esp-sha-hmac,
in use settings ={Transport, }
conn id: 10, flow_id: SW:10, crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4477099/2947)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
т.е. SA сохраняется
Здравствуйте, Александр.
Предлагаю вам снимать дампы до и после коммутатора и смотреть, какие IGMP пакеты пролетают — возможно, он начинает по умолчанию фильтровать их.
Если он изучает не все клиентские порты или порт к маршрутизатору — это вопрос к производителю.
В моём случае clear crypto isakmp и crypto isakmp keepalive 10 2 periodic не помогали восстановить работоспособность. Тут либо вкл-выкл филиалы, либо clear crypto session (или более радикально clear crypto sa). До конца не понимаю почему так происходит, может кто-нибудь сталкивался или в курсе из-за чего возникает такая ситуация?
А можно ли это как-то еще реализовать, если у меня просто dmvpn без ipsec?
у меня аналогично с isakmp keepalive 10 2 periodic )походу глюк gns3
а проблему одноразовости clear crypto …я решил по-зверски(вроде работает):
R1(config-isakmp)#lifetime 60