No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

CLI-based Configuration Guide - VPN

AR650, AR1600, and AR6100 V300R003

This document describes VPN features on the device and provides configuration procedures and configuration examples.
Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
(Optional) Configuring IKE Peer Status Detection

(Optional) Configuring IKE Peer Status Detection

Context

IKE does not provide peer status detection. In IPSec communication, if one end becomes faulty, the other end may not detect the fault because of system failures and continues to send IPSec packets to the faulty end. The problem can be solved only when the SA lifetime ends. Before the SA lifetime ends, the SA between IKE peers exists, causing traffic loss. Unreachability of an IKE peer can result in black holes where traffic is discarded. IPSec communication can be restored rapidly only when black holes are identified and detected in a timely manner.

The device provides heartbeat detection and dead peer detection (DPD) to detect the IKE peer status. Configure heartbeat detection or DPD as needed.

(Optional) Configuring Heartbeat Detection

Context

Heartbeat detection enables the local end to periodically send heartbeat packets to the remote end. If the local end does not receive heartbeat packets within the timeout interval, the local end considers the remote end as unreachable and deletes the IKE SA or IPSec SA between IKE peers.

There are limitations on heartbeat detection:
  • Enabling heartbeat detection will consume CPU resources used to process IKE keepalive messages, so the number of established IPSec sessions is limited.
  • There are no uniform standards, so devices from different vendors may fail to interwork.

The interval at which heartbeat packets are sent at the local end must be used with the timeout interval of heartbeat packets at the remote end. If the remote end does not receive any heartbeat packet within the timeout interval and the IKE SA carries a timeout tag, the IKE SA and its corresponding IPSec SA are deleted. If the IKE SA does not carry a timeout tag, it is marked as timeout.

NOTE:

If IKE peers use IKEv1 during negotiation, the device supports heartbeat detection. If IKE peers use IKEv2 during negotiation, the device does not support heartbeat detection.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run ike heartbeat { seq-num { new | old } | spi-list }

    Parameters of heartbeat packets are set.

    By default, a heartbeat packet uses old type sequence number mechanism and does not carry the SPI list.

  3. Run ike heartbeat-timer interval interval

    The interval at which heartbeat packets are sent by an IKE SA is set.

    By default, an IKE SA does not send heartbeat packets.

  4. Run ike heartbeat-timer timeout seconds

    The timeout interval of heartbeat packets is set.

    By default, the timeout interval during which an IKE SA waits for a heartbeat packet is not configured.

    When ike heartbeat-timer interval is configured at one end, the ike heartbeat-timer timeout command must be used at the other end.

    The timeout interval of heartbeat packets must be longer than the interval at which heartbeat packets are sent. Generally, packet loss does not occur for more than three consecutive times on a network. Therefore, it is recommended that the timeout interval of heartbeat packets be three times the interval at which heartbeat packets are sent.

(Optional) Configuring DPD

Context

In IPSec communication, heartbeat detection technology detects faults at the remote end and prevents packet loss. However, periodically sending heartbeat messages consumes CPU resources at both ends and limits the number of established IPSec sessions.

Dead Peer Detection (DPD) technology sends DPD packets based on IPSec packets between IKE peers, and does not periodically send heartbeat packets. When the local end can receive IPSec traffic from the remote end, the local end considers the remote end as active. The local end sends DPD packets to detect the status of the remote end when the local end does not receive IPSec traffic from the remote end within a given period of time. If the local end does not receive response packets after sending DPD packets several times, the local end considers the remote end as unreachable and deletes the IKE SA or IPSec SA between IKE peers.

If heartbeat detection is used, the two ends periodically send heartbeat packets and settings at the two ends must match. If DPD is used, settings except the payload sequence in DPD packets at the two ends do not need to match. When IPSec packets are exchanged between IKE peers, DPD packets are not sent. DPD packets are sent only when one end does not receive IPSec packets from the other end in a period of time. This saves resources.

NOTE:

When both heartbeat detection and DPD are used, DPD takes effect.

When the configured DPD detection parameters do not match the end, the device restarts IKE negotiation after the DPD probe fails, which affects the performance of the end device.

The detection mode and DPD are configured based on the dpd type or ike dpd type command. Two DPD modes are available:
  • On-demand DPD

    When the local end needs to send IPSec packets to the remote end, the local end determines that the DPD idle time is reached and sends a DPD request packet to the remote end.

  • Periodic DPD

    The local end determines that the DPD idle time is reached, and periodically sends a DPD request packet to the remote end based on the DPD idle time.

If the local end does not receive a DPD response packet from the remote end within the DPD packet retransmission interval, the local end retransmits the DPD request packet. If the local end still does not receive a DPD response packet after the DPD packet retransmission count is reached, the local end considers that the remote end goes offline, and deletes the IKE SA and IPSec SA.

Procedure
  1. Run system-view

    The system view is displayed.

  2. Run ike peer peer-name

    The IKE peer view is displayed.

  3. (Optional) Run dpd msg { seq-hash-notify | seq-notify-hash }

    The sequence of the payload in DPD packets is configured.

    By default, the sequence of the payload in DPD packets is seq-notify-hash.

    The two ends must use the same sequence of the payload in DPD packets; otherwise, DPD does not take effect.

  4. (Optional) Run dpd msg notify-hash-sequence learning

    Automatic learning of the payload sequence of DPD packets is enabled.

    By default, automatic learning of the payload sequence of DPD packets is enabled.

    After this command is configured, when the local end receives a DPD packet from the remote end, the local end learns the payload sequence of the DPD packet and sends a DPD packet in the same payload sequence.

    NOTE:
    Only V300R003C10 and later versions support.
  5. Run dpd { idle-time interval | retransmit-interval interval | retry-limit times }

    The DPD idle time, DPD packet retransmission interval, and maximum number of DPD packet retransmissions are set.

    By default, the DPD idle time is 30s, the DPD packet retransmission interval is 15s, and the maximum number of DPD packet retransmissions is 3.

  6. Run dpd type { on-demand | periodic }

    The on-demand or periodic DPD mode is configured.

    By default, the DPD mode is not configured on an IKE peer.

  7. Run dpd packet receive if-related enable

    The function that checks whether the interface that receives DPD packets is the interface that establishes an IPSec SA is enabled.

    By default, the function that checks whether the interface that receives DPD packets is the interface that establishes an IPSec SA is disabled.

    When IPSec policies with different names and the same parameters have been applied to multiple interfaces of the device, the interface that receives encrypted traffic is not the interface that establishes an IPSec SA during an interface switchover. If you want the two interfaces to be the same, run the dpd packet receive if-related enable command to enable the function that checks whether the interface that receives DPD packets is the interface that establishes an IPSec SA. If the two interfaces are different, DPD packets are discarded and the DPD detection result becomes abnormal. This causes the IPSec SA to be deleted and triggers IKE re-negotiation.

    This function applies only to the scenario where IPSec policies have been applied to physical interfaces.

    NOTE:
    Only V300R003C10 and later versions support.
Download
Updated: 2019-04-12

Document ID: EDOC1100041799

Views: 31548

Downloads: 45

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next