DPD, Dead Peer Detection.

crypto isakmp keepalive

Итак, DPD или Dead Peer Detection, что же это такое? Как видно из названия, это механизм обнаружения неработающего пира в рамках IKE и IPSec. Но механизм признаться чудной.

DPD был призван решить проблему периодических keepalive, которые при значительном числе spoke роутеров могут вызвать проблемы на центральных VPN-хабах. Да и вообще, это как-то не комильфо и требует внимания к интервалам keepalive запросов.

Стандартизированный в RFC 3706 протокол обнаружения "залипших" пиров, избавлен от этого недостатка и в сути своей непериодичен и асинхронен. А всё потому, что главным критерием определения нерабочего пира является собственно простой установленной IPSec сессии.

Но как это работает?


Всё очень просто:

• Каждый из DPD пиров должен проверять наличие регулярного обмена шифрованными пакетами.
• Каждый их них же должен использовать наличие этого трафика как доказательство работоспособности соседа.
• При наличие этого самого трафика - пир не должен начинает процесс обмена DPD сообщениями.

Довольно логично, что если простой появился, обнаруживший его пир запускает DPD exchange. Началом служит отправка R-U-THERE запроса, на который должен прийти R-U-THERE-ACK. В случае, если этого не происходит, инициатор должен повторить отправку R-U-THERE запросов ещё несколько раз.

В Cisco IOS это управляется командой из заголовка: crypro isakmp keepalive <threshold> <retry-interval> {[on-demand] | periodic}. В качестве аргументов используется два временных интервала. Первый задает промежуток простоя обмена пакетами (threshold), а второй - время между отправкой последующий R-U-THERE запросов (retry-interval), количество которых в cisco неизменно и равно 5. 

Следует принять во внимание, что достижение threshold интервала не является необходимым для старта DPD процесса. В RFC по этому поводу сказано следующее: "an entity can initiate a DPD exchange if it has sent outbound IPSec traffic, but not received any inbound IPSec packets in respons". Или, в переводе на русский язык: "процесс обнаружение "залипшего" соседа может начаться если один из участников отправляет пакеты, но не получает ничего в ответ, т.е. до достижения threshold интервала".

Это имеет довольно большое значение для работы в условиях нестабильных каналов. Если мы хотим ослабить реакцию на кратковременные падения линка, улучшив таким образом сходимость, то нам следует не увеличивать threshold интервал, а поднять значение retry-interval. Ведь в случае большой сетевой активности DPD процесс может начаться раньше.

Так-же стоит обращать внимание на данные настройки при организации site-to-site vpn между организациями. Т.к. поведение DPD меняется от вендора к вендору и от платформы к платформе. Например, в Cisco IOS нельзя полностью выключить DPD, лишь перевести в односторонний режим, в котором роутер будет только отвечать на внешние R-U-THERE запросы. А вот Cisco ASA данные keepalive можно отключать совсем.