352-001 · Question #99
A network administrator is in charge of multiple IPsec VPN headend devices that service thousands of remote connectivity, point-to-point, IPsec/GRE tunnels. During a recent power outage, in which it…
The correct answer is B. Implement Call Admission Control. When an IPsec VPN headend recovers from a full shutdown, thousands of tunnels attempt to re-establish simultaneously - Call Admission Control prevents CPU overload by rate-limiting new IKE/IPsec negotiations.
Question
A network administrator is in charge of multiple IPsec VPN headend devices that service thousands of remote connectivity, point-to-point, IPsec/GRE tunnels. During a recent power outage, in which it was found that a backup power supply in one of those headend devices was faulty, one of the headend routers suffered a complete shutdown event. When the router was successfully recovered, remote users found intermittent connectivity issues that went away after several hours. Network operations staff accessed the headend devices and found that the recently recovered unit was near 100% CPU for a long period of time. How would you redesign the network VPN headend devices to prevent this from happening again in the future?
Options
- AMove the tunnels more evenly across the headend devices.
- BImplement Call Admission Control.
- CUse the scheduler allocate command to curb CPU usage.
- DChange the tunnels to DMVPN.
How the community answered
(43 responses)- A23% (10)
- B58% (25)
- C7% (3)
- D12% (5)
Why each option
When an IPsec VPN headend recovers from a full shutdown, thousands of tunnels attempt to re-establish simultaneously - Call Admission Control prevents CPU overload by rate-limiting new IKE/IPsec negotiations.
Distributing tunnels more evenly across headend devices balances steady-state load but does not prevent all tunnels on one device from reconnecting simultaneously after that device restarts.
Call Admission Control for IPsec limits the rate at which new IKE phase-1 and phase-2 security association negotiations are accepted and processed, preventing the burst of simultaneous tunnel re-establishments from exhausting the headend CPU after a restart event and allowing recovery to proceed in a controlled manner.
The scheduler allocate command adjusts how CPU time is divided among Cisco IOS processes but does not throttle the volume of incoming IKE negotiation requests that cause the overload.
Migrating to DMVPN changes the hub-and-spoke topology model but does not inherently rate-limit spoke reconnection attempts when a hub recovers from a complete power failure.
Concept tested: IPsec Call Admission Control for headend CPU overload prevention
Source: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_vpnips/configuration/xe-16/sec-sec-for-vpns-w-ipsec-xe-16-book/sec-call-admit-control-ipsec.html
Topics
Community Discussion
No community discussion yet for this question.