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>

Reminder

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

upgrade

Tunnels Cannot Be Re-set Up Automatically After the Restart of Central Devices Because of the Configuration of IPSec VPN in the HUB–Spoke Networking

Publication Date:  2012-07-27 Views:  37 Downloads:  0
Issue Description
Five AR18 routers, a platform of version VRP3.4, and an AR central node establish IPSec tunnels with other four ARs (For the networking, refers to the attachment).When the AR of the central node is restarted, the IPSec service is interrupted. Restart the four peer ARs manually, the fault is rectified. 
 
Alarm Information
Large traps appear on the central node.
%Jan 1 00:02:04:960 2000 RBT-Global IPSEC/4/DROP:
IPsec Packet discarded--Src IP:10.155.9.2 ||Dest IP:217.11.184.251 || SPI:2719213136 || SN:278 || Cause:can’t find SA
*0.123118 RBT-Global IPSEC/8/DBG:ESP input: could not find SA for packet from 10.155.9.2 to 217.11.184.251, spi a213e650
%Jan 1 00:02:05:938 2000 RBT-Global IPSEC/4/DROP:
IPsec Packet discarded--Src IP:10.155.9.2 ||Dest IP:217.11.184.251 || SPI:2719213136 || SN:279 || Cause:can’t find SA
*0.124106 RBT-Global IPSEC/8/DBG:ESP input: could not find SA for packet from 10.155.9.2 to 217.11.184.251, spi a213e650
%Jan 1 00:02:06:908 2000 RBT-Global IPSEC/4/DROP:
IPsec Packet discarded--Src IP:10.155.9.2 ||Dest IP:217.11.184.251 || SPI:2719213136 || SN:280 || Cause:can’t find SA
*0.125096 RBT-Global IPSEC/8/DBG:ESP input: could not find SA for packet from 10.155.9.2 to 217.11.184.251, spi a213e650
%Jan 1 00:02:07:862 2000 RBT-Global IKE/4/DROP:
IKE packet dropped: (src addr: 10.155.3.44, dst addr: 217.11.184.251) with I_Cookie b7ccd478b9457fef and R_Cookie 83e08540d62de1c5, because of ’ Invalid cook 
 
Handling Process
The VRP3.4 platform has the function of Dead Peer Detection (DPD) and can detect whether the IPSec peer is normal in several seconds. If the IPSec peer is abnormal, the VRP3.4 platform originates the IPSec negotiation actively.
Modify and configure all the nodes as follows:
#
ike dpd 1
time-out 3 ------By default, the value is 5
#
ike peer brt_global
pre-shared-key BC2585117308927072006
local-address 217.11.184.251
dpd 1--------Applicate dpd. 
 
Root Cause
According to the trap messages, packets sent by the peer are discarded because no matching SA is found on the local. After the central AR is restarted, SAs are cleared. But the SA is not aged on the peer, so the peer still sends the packet.
Why restarting the central AR cannot trigger the renegotiation of the IPSec? Check and find that the IKE peer of the central node is configured as follows:
#
ike peer brt_global
pre-shared-key BC2585117308927072006
local-address 217.11.184.251
To realize the one-to-multiple IPSec tunnel, the central node responds the establishment of the IPSec passively and cannot originate the request for IPSec negotiation actively. To restore the service, the peer must detect the situation on the local and re-originate the negotiation. 
 
Suggestions
Null 

END