Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
In large scale IKEv2 deployments, IKEv2 clients might not be able to connect. Issue would most likely occur after the router is reloaded or after some kind of failure in the path between the IKEv2 router and the clients.
1) High rate of incoming IKEv2 INIT packets. (normally after a reboot of router or path failure between router and it's peers) 2) Seeing build up of packets in LOW queue (this is where IKEv2 INIT packets are queued) SIZE=current count of packets in the queue PEAK=high water mark of the queue size Router#show crypto ikev2 stats priority-queue ---------------------------------------------------- IKEV2 PRIORITY QUEUE SIZE PEAK ---------------------------------------------------- HIGHEST 0 11 HIGHER 0 5 HIGH 0 91 NORMAL 0 7 LOW 0 211680 <<<<This is abnormally large LOWER 0 0 LOWEST 0 26 3) There will likely be high CPU in IKEv2 process during this time while the router is processing packets from the queue
1) Use an ACL or control plane policing to limit the rate of incoming IKE INIT packets such that the LOW queue does not continue to grow/climb.
This bug adds a CLI command to limit the queue size for IKEv2 INIT packets. The problem is that the RP in IOS-XE (IKEv2 process) can only service this queue at a given rate (the CPU speed and other process burdens determines this). If the rate of incoming IKEv2 INIT packets is faster than the rate at which the IKEv2 process can service the queue, we reach a tipping point where the queue will become hopelessly large. By the time the router gets to respond to a particular IKEv2 INIT from the queue, so much time has passed that the response is dropped by the initiating client (due to timeout). This issue starts to compound because the clients are likely continuing to send INIT packets to attempt to establish the tunnel. IKEv2 CAC does not solve this problem.